Connectivity Overview

Integration

Ref: Enterprise Integration Patterns

Typical ways to integrate:

1. File transfer - bulk transfer - infrequent changes
2. Shared DB - data sharing
3. RPC - functionality sharing
4. Messaging - frequent small data exchange

What to use when

• JDBC - connector for relational databases
• Asynchronous messaging - loosely coupled integration - JMS or JCA
  • JMS also supports quality of service, higher throughput, guaranteed delivery
  • Asynchronous model more complex
• Synchronous - tightly coupled integrations - JCA/RPC - SOAP/CORBA/RMI
  • JCA for high quality request processing and error handling
• Legacy communication - JCA

Loosely coupled requirements

• data encapsulation/encoding
• allow transformations inside channel
• queue requests - don't depend on availability
• location - logical address - configurable outside code

RPC

Advantages

• synchronous
• data encapsulated

Disadvanates

• tight coupling - parameters, availability
• latency

Shared DB

Advantages of a shared DB

• data always current
• no need to resolve inconsistent data from different sources
• enforced data quality - DB constraints

Disadvantages of a shared DB

• tightly coupled
• difficult to define a shared schema that works for all systems
• semantic dissonance
• performance bottleneck - all applications fight for one resource
• distribution/location

JMS

Advantages of JMS

• better encapsulation than shared DB
• more reliable than RPC
  • automatic retries for sending and receiving messages
• background processing - scalability
• allows both sender and receiver to operate at maximum pace- variable timing
  • control over rate of processing independent on external load
• ideal for disconnected systems - PDAs and laptops
• mediator pattern - messaging system can provide high availability, load balancing, QoS, performance tuning
• may be asynchronous or synchronous - request-reply
• asynchronous - reduces impact of latency - remote calls
• supports different topologies: broadcast/point to point/routing

Disadvantages of JMS

• Difficult programming model to understand and debug
  • logic spread around event handlers
  • concurrency
  • may need to track context on callbacks
  • Out of sequence issues
• Many systems require synchronous responses
• Performance - overhead of sending large messages or lots of small messages
• Availability
• Vendor specific

Synchronous JMS

Typically done with a temporary queue

• see QueueRequester/TopicRequester
• problems
  • queue deleted when context goes - lost on crash (temporary queues and messages deleted on connection closing)
• consider asynchronous callback instead

Role of the Resource Manager

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/transactions/transactions9.html

Three types:

JDBC

• Manage transactions across multiple components (possibly different tiers)
• Multiple JDBC resources may not be portable

JMS

• Manage transactions across multiple components (possibly different tiers)
• Multiple JMS providers may not be portable
• Messages not transmitted until transaction committed - transaction rollback = message discarded
• Messages not consumed until transaction committed - transactions roll back = put back on queue
• Sending and waiting for an acknowledgment can not be done within the same transcation

JCA

• RA can choose level of transaction support

1. NoTransaction
2. LocalTransaction - only one resource can participate in transaction
3. XATransaction ( must also support LocalTransaction) - Two phase commit - multiple resources can participate.