https://luminoussheep.net/mediawiki/index.php?action=history&feed=atom&title=Connectivity_Overview 2026-04-16T20:37:56Z Revision history for this page on the wiki MediaWiki 1.43.8 https://luminoussheep.net/mediawiki/index.php?title=Connectivity_Overview&diff=52&oldid=prev 2021-09-14T21:24:13Z

<p>Created page with &quot;= Integration = Ref: Enterprise Integration Patterns Typical ways to integrate: # File transfer - bulk transfer - infrequent changes # Shared DB - data sharing # RPC - functi...&quot;</p> <p><b>New page</b></p><div>= Integration =<br /> Ref: Enterprise Integration Patterns<br /> <br /> Typical ways to integrate:<br /> # File transfer - bulk transfer - infrequent changes<br /> # Shared DB - data sharing<br /> # RPC - functionality sharing<br /> # Messaging - frequent small data exchange<br /> <br /> = What to use when =<br /> * JDBC - connector for relational databases<br /> * Asynchronous messaging - loosely coupled integration - JMS or JCA<br /> ** JMS also supports quality of service, higher throughput, guaranteed delivery<br /> ** Asynchronous model more complex<br /> * Synchronous - tightly coupled integrations - JCA/RPC - SOAP/CORBA/RMI<br /> ** JCA for high quality request processing and error handling<br /> * Legacy communication - JCA<br /> <br /> == Loosely coupled requirements ==<br /> * data encapsulation/encoding<br /> * allow transformations inside channel<br /> * queue requests - don&#039;t depend on availability<br /> * location - logical address - configurable outside code<br /> <br /> == RPC ==<br /> === Advantages ===<br /> * synchronous<br /> * data encapsulated<br /> <br /> === Disadvanates ===<br /> * tight coupling - parameters, availability<br /> * latency<br /> <br /> == Shared DB ==<br /> === Advantages of a shared DB ===<br /> * data always current<br /> * no need to resolve inconsistent data from different sources<br /> * enforced data quality - DB constraints<br /> <br /> === Disadvantages of a shared DB ===<br /> * tightly coupled<br /> * difficult to define a shared schema that works for all systems<br /> * semantic dissonance<br /> * performance bottleneck - all applications fight for one resource<br /> * distribution/location<br /> <br /> == JMS ==<br /> === Advantages of JMS ===<br /> * better encapsulation than shared DB<br /> * more reliable than RPC<br /> ** automatic retries for sending and receiving messages<br /> * background processing - scalability<br /> * allows both sender and receiver to operate at maximum pace- variable timing<br /> ** control over rate of processing independent on external load<br /> * ideal for disconnected systems - PDAs and laptops<br /> * mediator pattern - messaging system can provide high availability, load balancing, QoS, performance tuning<br /> * may be asynchronous or synchronous - request-reply<br /> * asynchronous - reduces impact of latency - remote calls<br /> * supports different topologies: broadcast/point to point/routing<br /> <br /> === Disadvantages of JMS ===<br /> * Difficult programming model to understand and debug<br /> ** logic spread around event handlers<br /> ** concurrency<br /> ** may need to track context on callbacks<br /> ** Out of sequence issues<br /> * Many systems require synchronous responses<br /> * Performance - overhead of sending large messages or lots of small messages<br /> * Availability<br /> * Vendor specific<br /> <br /> <br /> === Synchronous JMS ===<br /> Typically done with a temporary queue<br /> * see QueueRequester/TopicRequester<br /> * problems<br /> ** queue deleted when context goes - lost on crash (temporary queues and messages deleted on connection closing)<br /> * consider asynchronous callback instead<br /> <br /> = Role of the Resource Manager =<br /> http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/transactions/transactions9.html<br /> <br /> Three types:<br /> == JDBC ==<br /> * Manage transactions across multiple components (possibly different tiers)<br /> * Multiple JDBC resources may not be portable<br /> <br /> == JMS ==<br /> * Manage transactions across multiple components (possibly different tiers)<br /> * Multiple JMS providers may not be portable<br /> * Messages not transmitted until transaction committed - transaction rollback = message discarded<br /> * Messages not consumed until transaction committed - transactions roll back = put back on queue<br /> * Sending and waiting for an acknowledgment can not be done within the same transcation<br /> <br /> == JCA ==<br /> * RA can choose level of transaction support<br /> # NoTransaction<br /> # LocalTransaction - only one resource can participate in transaction<br /> # XATransaction ( must also support LocalTransaction) - Two phase commit - multiple resources can participate.</div>

Martin