Section 3: Integration and Messaging
Explain possible approaches for communicating with an external system from a Java EE technology-based system given an outline description of those systems and outline the benefits and drawbacks of each approach.
Challenges in integration:
- Networks are unreliable: design failsafe/error recoverable.
- Networks are slow: aim for minimum network traffic.
- Any two applications are different: use standard communication interfaces/protocols.
- Change is inevitable: minimize dependencies between systems.
- File Transfer: save data to file and share using file system or File Transfer Protocol (FTP).
- Shared Database: save data in common database.
- Remote Procedure Invocation: expose methods/procedures for remote invocation: RMI, CORBA, SOAP, XML-RPC or REST.
- Messaging: connect to common messaging system to exchange data: JMS.
Benefits: simplest integration style, mostly available on all systems
Drawbacks: delivery depends on polls, insecure, fileformat and naming agreements (case sensitivity Windows/UNIX), file management needed (removal, locking, synchronization)
Benefits: easily exported and mounted by remote file systems
Drawbacks: must share same file system or accessible through share, not (externally) allowed by firewalls, not scalable
Benefits: reliable file transfer method
Drawbacks: FTP service needed, firewall must open port 21
Benefits: database services like locking and transactions, accessible using standard SQL
Drawbacks: must share same database (poor encapsulation), beware of single-point-of-failure
Remote Procedure Invocation
Benefits: transparant use of objects, JRMP tunneling through HTTP possible
Drawbacks: must share same classes, no support for transactions/sessions, objects must be serializable
Benefits: objects, inter-connecting heterogeneous systems, IIOP tunneling through HTTP possible
Drawbacks: slow, no support for transactions/sessions
Benefits: http protocol, allowed by firewall, no class sharing needed, XML
SOAP and JAX-WS
Benefits: HTTP protocol, allowed by firewall, Java API, no class sharing needed, XML
Benefits: faster delivery than file transfer, better encapsulation, more reliable than remote procedures, service provided by application server, loose coupling, asynchronous communication possible
Drawbacks: extra component/broker to maintain, lack of standards between heterogeneous systems, not suitable for systems that require synchronous communication
Benefits: transparant communication between heterogeneous systems, broadcasting (publish/subscribe), asynchronous/synchronous, transactional/non-transactional, knows networks are unreliable (retries until delivery), immediate delivery, disconnected operation
Drawbacks: slower than direct communication
Explain typical uses of web services and XML over HTTP as mechanisms to integrate distinct software components.
Reasons to use XML over HTTP:
- Allow applications, written in different languages, on different platforms, and in different locations to communicate
- Based on standard protocols
XML over HTTP is also called Representational State Transfer (REST). XML over HTTP and SOAP reflect the SOA approach. SOAP is not XML over HTTP, but can be tunneled over HTTP. SOAP with Attachments API for Java (SAAJ) can be used for implementation with Java. SOAP is also mentioned in this section, because of the similarities with XML over HTTP.
- Reliable rigid communication (extra messaging layer)
- The standard for web service, hence better support from other standards (WSDL, WS-*)
- Designed for distributed computing environment
- Built-in error handling (faults)
- Complex (steep learning curve)
- Generates more traffic (large envelope headers)
- More verbose
- Requires tools/frameworks
- Not cacheable by the network layer (uses POST)
- Direct communication on top of HTTP (no additional messaging layer needed)
- No other technology required than standard HTTP, XML and URI
- Not restricted by firewalls most of the time (HTTP/HTTPS)
- No extra tools/frameworks required
- Simple to develop
- Minimal traffic (no verbose message headers)
- Security functionality can be delegated to the webserver
- Cacheable by the network layer (beware for old data being cached)
- Instead of XML, other (custom) formats can be used
- URIs instead of methods and parameters
- Not as integrated as API's
- Needs interface allignment with business partners (no standard contract specification)
- Tied to HTTP transport model
- Assumes a point-to-point communication model (default not scalable)
- No built-in support for standards (security, type checking, messaging, etc.)
Explain how JCA and JMS are used to integrate distinct software components as part of an overall Java EE application.
J2EE Connector Architecture (JCA)
For integrating heterogeneous enterprise information systems (EIS). Connector provided by vendor for use in compliant application server, enabling integration by contract. Connector collaborates with application server to provide: transactions, security, and connection management.
Benefits: vendor connectors allow transparant use of their systems, component is loosely coupled, portability, standard interface, secure, transactions, pooling, interface contract
Drawbacks: not all vendors provide connectors, for Java only
Java Message Service (JMS)
JMS is a standard Java API for enterprise messaging systems. It provides asynchronous communication with one ore more other external systems. Vendors can provide JCA compliant JMS-provider connectors.
Two forms of JMS systems:
- point-to-point (named queue)
- publish-subscribe (durable/undurable topic subscription)
- Data integration (JDBC for relational databases, JCA for non-relational databases)
- Asynchronous, message-based, loosely coupled integration (JMS or Connector)
- Synchronous, tightly-coupled integration (Connector)
- Legacy connectivity (Connector)