| license | Apache-2.0 |
| name | bellifemine-2007-jade-fipa |
| description | JADE platform for building FIPA-compliant multi-agent systems with standardized agent communication |
| category | Research & Academic |
| tags | ["jade","fipa","agents","middleware","multi-agent-platform"] |
SKILL: Developing Multi-Agent Systems with JADE
Decision Points
Ontology-First vs Behavior-First Agent Design
IF agents built by different teams/languages need semantic interoperability
→ START with ontology definition (concepts, predicates, actions)
→ THEN implement behaviors that use ontology
→ Example: Commerce ontology with PurchaseOrder, Price concepts
ELSE IF rapid prototyping single-team system
→ START with behavior implementation (protocols, workflows)
→ ADD ontology later when integration needed
→ Example: Internal workflow automation
Protocol Selection for Task Coordination
IF task requires competitive selection among multiple candidates
→ Contract Net Protocol
→ Coordinator announces CFP, agents bid, select winner
ELSE IF task is conditional future execution
→ Request-When Protocol
→ "Execute X when condition Y becomes true"
ELSE IF task requires ongoing data subscription
→ Subscribe Protocol
→ Register for updates, receive INFORMs until unsubscribe
ELSE IF simple synchronous request-response
→ Request Protocol
→ AGREE/REFUSE followed by INFORM/FAILURE
Resource-Constrained Protocol Composition
IF mobile/edge agents with limited battery/connectivity
→ Use split-container architecture
→ Lightweight front-end + stateful back-end + mediator
ELSE IF high-throughput server environment
→ Direct peer-to-peer protocols
→ No mediation overhead needed
IF timeout budget < 5 seconds
→ Avoid nested Contract Net (too many round trips)
→ Use direct Request with pre-cached service discovery
ELSE IF timeout budget > 30 seconds
→ Safe to use Contract Net → Request composition
→ Full negotiation + execution workflow
Agent Architecture Patterns
IF agent needs standard FIPA semantics only
→ Extend SemanticAgent
→ Declare Capability (actions, beliefs)
→ Get QUERY/INFORM/SUBSCRIBE for free via SIPs
ELSE IF custom message interpretation required
→ Override specific SIPs (Semantic Interpretation Principles)
→ Keep default SIPs where possible
ELSE IF complex workflow coordination needed
→ Compose behaviors: Sequential/Parallel/FSM
→ Use protocol templates as building blocks
Failure Modes
Byzantine Agent Behavior
Symptoms: Agent accepts REQUEST (sends AGREE) but never responds with INFORM/FAILURE, or sends semantically invalid responses
Detection: if (timeoutExpired && lastReceived == AGREE) { /* Byzantine behavior detected */ }
Diagnosis: Agent implementation bug or malicious behavior - violating FIPA protocol contract
Fix: Implement timeout handling with explicit FAILURE generation, blacklist unreliable agents, add protocol validation layers
Schema Bloat in Ontology Evolution
Symptoms: Ontology grows to 500+ concepts, agents spend seconds parsing/reasoning about messages
Detection: if (ontology.getConcepts().size() > threshold || messageParsingTime > 100ms)
Diagnosis: Monolithic ontology without modular decomposition
Fix: Split into domain-specific sub-ontologies, use ontology import/composition, implement lazy concept loading
Cascade Failure in Sequential Workflows
Symptoms: Single agent failure brings down entire multi-step workflow, no partial progress recovery
Detection: if (behavior instanceof SequentialBehaviour && childFailureCount > 0)
Diagnosis: No failure isolation between workflow steps
Fix: Replace SequentialBehaviour with FSMBehaviour for explicit error states, add compensating actions for partial rollback
Message Queue Overflow Under Load
Symptoms: OutOfMemoryError in message delivery subsystem, agents stop receiving messages
Detection: Monitor containerMessageQueueSize > maxThreshold
Diagnosis: Producer/consumer rate mismatch, no backpressure mechanism
Fix: Set message TTL, implement priority queues, add flow control at protocol level
Directory Facilitator Bottleneck
Symptoms: Service discovery taking >5 seconds, DF becomes single point of failure
Detection: if (dfSearchTime > threshold || dfRequestCount > maxConcurrent)
Diagnosis: Centralized service registry pattern under high load
Fix: Implement distributed DF federation, cache service advertisements locally, use gossip-based discovery
Worked Examples
Example: Multi-Vendor Book Purchase with Failure Handling
Scenario: Agent needs to buy "JADE Programming Guide" at lowest price from multiple online sellers
Decision Point Navigation:
- Task Type: Competitive selection among vendors → Contract Net Protocol
- Architecture: Standard request-response needed → Basic Agent + Request Protocol for execution
- Failure Requirements: Timeout budget 30 seconds, need graceful degradation → Sequential workflow with timeout handling
Expert Implementation:
ContractNetInitiator bookPurchaseNegotiation = new ContractNetInitiator(this, cfpMessage) {
protected void handlePropose(ACLMessage propose, Vector acceptances) {
double score = calculateVendorScore(propose);
if (score > bestScore) {
bestScore = score;
bestProposal = propose;
}
}
protected void handleFailure(ACLMessage failure) {
addBehaviour(new FallbackBehavior(searchAmazonDirect()));
}
};
RequestInitiator purchaseExecution = new RequestInitiator(this, purchaseMessage) {
protected void handleInform(ACLMessage inform) {
if (validatePurchaseConfirmation(inform)) {
logger.info("Purchase confirmed: " + inform.getContent());
}
}
protected void handleFailure(ACLMessage failure) {
retryWithNextVendor();
}
};
Novice Would Miss:
- No timeout handling - would wait forever for responses
- No proposal evaluation logic - would accept first response
- No backup strategy when Contract Net finds no bidders
- No validation of purchase confirmation semantics
Expert Catches:
- Explicit timeout in Contract Net CFP message
- Multi-criteria vendor scoring (price + delivery + reputation)
- Fallback behavior when no proposals received
- Ontology-based validation of purchase confirmation content
- Retry mechanism with next-best vendor on payment failure
Quality Gates
NOT-FOR Boundaries
This skill should NOT be used for:
- Simple HTTP REST APIs → Use standard web service frameworks instead
- Batch processing pipelines → Use workflow engines like Apache Airflow instead
- Real-time streaming data → Use event streaming platforms like Apache Kafka instead
- Single-machine concurrency → Use standard threading/async frameworks instead
- Database transactions → Use ACID database systems instead
Delegation Guidelines:
- For message queuing without agent semantics → Use
message-queue-architecture skill instead
- For distributed system consensus → Use
distributed-consensus-algorithms skill instead
- For service mesh networking → Use
service-mesh-patterns skill instead
- For event-driven architecture → Use
event-sourcing-cqrs skill instead
- For microservices orchestration → Use
microservices-coordination skill instead
Core Trigger: Use JADE when you need semantic interoperability between autonomous components that must coordinate without central control using standardized protocols. If any of these requirements is missing, simpler alternatives will be more appropriate.
