Extended Enterprise: Select Application pattern

The Exposed Direct Connection application pattern represents the simplest interaction type based on a 1-to-1 topology. It allows a pair of applications to directly communicate with each other across organization boundaries. Interactions between a source and a target application can be arbitrarily complex. Generally, complexity can be addressed by breaking down interactions into more elementary interactions.

More complex point-to-point connections will have modeled connection rules such as business rules associated with them, as shown in the figure below. Connection rules are generally used to control the mode of operation of a connector depending on external factors. Examples of connection rules are:

• Business data mapping rules (for adapter connectors)
• Autonomic rules (such as priority in a shared environment)
• Security rules
• Capacity and availability rules

The Exposed Direct Connection application pattern has two communication variations:

• Message Connection variation
• Call Connection variation

All applications of the Exposed Direct Connection application pattern will be one communication variation or the other. The communication variation required depends on whether the initiating source application needs an immediate response from the target application in order to proceed with execution.

Both communication variations may be used either with synchronous or asynchronous communication protocols. However, there are preferences for a specific protocol type depending on the variation. For example, the Call Connection variation has a more natural fit with synchronous protocols while the Message Connection variation favours asynchronous protocols.

Business and IT Drivers

The business and IT drivers for choosing the Exposed Direct Connection application pattern are to:

• Improve the organizational efficiency
• Reduce the latency of business events
• Support a structured exchange with business partners
• Support real-time one-way message flows to partner processes
• Support real-time request/reply message flows to partner processes
• Leverage existing skills
• Leverage the legacy investment
• Enable back-end application integration
• Minimize application complexity

The primary goal is to allow an application to gain direct and real-time access to another application that is outside the organization in order to reduce the latency of business events.

Solution

Select this Application pattern

For a legend, please see above.

This application pattern, as shown in the figure above, is divided into a number of logical components:

• The Exposed Application tier is responsible for implementing business logic and access to business data. Since this application is directly exposed across organizational boundaries, it must implement or exploit the necessary security features such as authentication, authorization, confidentiality, integrity, and logging for non-repudiation purposes.
• The Connection is the line between the exposed application and the partner application representing a point-to-point connection between the two applications.
• The Connection Rules represent any business rules associated with the connection, such as data mapping rules and security rules.
• The Partner Application tier represents a set of partner applications which are interested in invoking or being invoked by specific logic on the exposed application tier.

Guidelines for use

Direct integration between applications can be inflexible, in that any changes to one application may have knock-on effects on other applications. This is especially dangerous when integrating across organizational boundaries. Any changes to the exposed target application may require changes to many partner applications. Such changes can be both expensive and time consuming.

Such knock-on effects can be minimized using document-based adapters that wrapper the applications in the exposed connection. Document-based adapters are small programs that convert the mutually agreed upon messages into API calls to existing or new backend applications. This layering technique isolates the exposed applications from partner applications and increases flexibility. Any changes to these exposed applications would only impact the adapter, provided there is no need to change the mutually agreed upon messages.

Message definition should be generalized to further promote flexibility. In other words, messages should not be tightly coupled with backend application APIs. Rather the message should capture all the necessary information required for that logical interaction across business boundaries. Such generalization will help cope with changes to the backend application API without having to change the agreed upon message format.

Benefits

It typically leverages the benefits of message-oriented middleware (MOM) such as guaranteed message delivery, transactional support, encryption, high performance and high availability.

Limitations

This pattern implements a direct connection between the Exposed and Partner application. Hence, it cannot be used for intelligent routing of requests, decomposition and re-composition of requests, and for invoking complex business process workflow as a result of a request from a partner application. Under such circumstances, you should consider a more advanced application pattern, such as Exposed Broker, Exposed Router or Exposed Serial Process.

Putting the application pattern to use

The following example uses REST architectural style:

• Ideal Electronics Parts Co (fictitious) makes different kinds of electronic parts used in consumer devices such as cell phones, PDAs, iPods etc.
• Ideal Electronics Parts Co have several Electronics Parts Distribution companies as business partners.
• Ideal Electronics Parts Co provides a URL where a list of parts can be obtained. The information is returned to the requestor in an XML format. The information has links (URLs) to detailed information about each part. To get detailed information about a particular part such as price and availability, the corresponding URL is used to request the information.
• Ideal Electronic Parts Co provides a URL through which a Purchase Order can be submitted as a payload to a HTTP POST command. The payload is an XML document which is constructed by the submitter. Earlier, this XML document's schema has been provided by Ideal Electronics Parts Co through a WSDL document which has been shared with business partners.
• In the above example. Ideal Electronic Parts Co is the providing partner and the various Electronics Parts Distributors are the consuming partners.

The following example uses web services architectural style:

• Xyz Freight Quote Co is a business partner to 25 freight carriers.
• Xyz Freight Quote Co provides a portal where customers can shop for freight rates.
• Customer enters details such as 'from', 'to', 'weight', 'class' etc and is provided up to 25 quotes within a few seconds.
• Xyz Freight Quote Co performs service invocations to the 25 freight carriers to get a quote from each.
• Xyz Freight Quote portal consolidates the information and provides it to the customer.
• Xyz Freight Quote portal provides additional facility for customer to choose and finalise a quote. Again each of the 25 freight carriers expose an application / service to accept the transaction.

For a legend, please see above.

The Message Connection variation, shown above, applies to solutions where the business process does not require a response from the exposed target application within the scope of the interaction.

Business and IT Drivers

The business and IT driver for choosing the Message Connection variation of the Exposed Direct Connection application pattern is to:

• Support real-time one-way message flows

The main driver for selecting this variation is when the business process has no interest in the result of the operation. This variation also has the most natural fit when message-oriented middleware is used, such as IBM WebSphere MQ.

Putting the application pattern to use

With the successful integration of their internal retail and wholesale systems, ITSO Electronics has now decided to integrate with their external business partners. The goal is to integrate the external resellers with the internal wholesale system. As with the internal retail system, orders placed by the external resellers will need to update the wholesale inventory system. To meet these requirements ITSO Electronics chooses the Exposed Direct Connection application pattern. In our scenario, external business partners of the ITSO Electronics organization need to notify the ITSO wholesale department to update their inventory records when a part needs to be ordered. The external business partners do not require any acknowledgement of the request. ITSO Electronics chooses the Message Connection variation of the Exposed Direct Connection application pattern to meet this requirement.

For a legend, please see above.

The Call Connection variation, shown above, applies to solutions where the business process depends on the exposed target application to process a request and return an response within the scope of the interaction.

Business and IT Drivers

The business and IT driver for choosing the Call Connection variation of the Exposed Direct Connection application pattern is to:

• Support real-time request/reply message flows

The main driver for selecting this variation is when the business process requires a result message in the interaction.

Putting the application pattern to use

The final stage of the scenario is addressing any out of stock situations with the external resellers. As with the internal retail system, the external resellers require an immediate notice on any out of stock situations and a delivery date indicating when the order can be filled. To meet these requirements, ITSO Electronics chooses the Call Connection variation of the Exposed Direct Connection application pattern.

The Exposed Document variation application pattern helps to structure the batched electronic exchange of data using mutually agreed message formats. It is a variation of the Exposed Direct Connection application pattern which also uses the Message Connection variation.

Business and IT Drivers

The business and IT drivers for choosing the Exposed Document variation application pattern are to:

• Decrease Time to Market
• Automated document exchange with external entities
• Minimise complexity
• Provide exchange-based integration with external partners

The primary business driver for choosing this Application pattern is to increase the efficiency of interactions between enterprises. Instead of exchanging paper documents, this Application pattern can be used to send and receive documents electronically. This eliminates the need for error-prone manual re-entry of data. This is the ideal Application pattern to choose if your current business needs would be satisfied by the batched exchange of electronic documents. In other words, at present your business requirements don't call for direct invocation of a business partner's systems in a real-time fashion. Large organizations often require their business partners to exchange messages electronically. For example, they may mandate the use of Electronic Data Interchange (EDI) transaction sets for certain interactions such as placing an order. Use this pattern for simple document exchange given there is no need for mediation or integration with multiple back-end resources.

Solution

Select this Application pattern

For a legend, please see above.

This application pattern, as shown in the figure above, is divided into a number of logical components:

• The intermediate tier is responsible for document exchange (send/receive documents) and document storage on a transient basis.
• The Application tiers are responsible for business logic.
• The Read/Write data is the primary information holding resource (no integration with other data or application resources in this pattern).

The communication between tiers is asynchronous and status/receipt messages are optional.

The partners use a mutually-agreed message format.

Guidelines for use

If you anticipate a need to support mediation or routing in the future, it might be better to select the Exposed Broker pattern.

The pattern may include basic partner management tools to support small partner communities.

The Exposed Documents patterns may be used to support basic access to a VAN (Value Added Network).

Benefits

This pattern is the simplest to implement and delivers a basic partner integration solution for small inter-enterprise solutions. It uses a simple protocol such as HTTP/S, FTP/FTPS.

Limitations

This pattern does not provide back-end application integration (no routing or transformation) or composition and decomposition of requests. It also comes with limited non-integrated system management and monitoring (largely manual reconciliation).

Putting the application pattern to use

• Inbound Interaction
  • A Manufacturer sends a request for third party logistic scheduling e.g. FedEx.
    • Shipment request in XML document format within logistics application moved to Intermediate Document store
    • Post Shipment Request as XML document via FTP to logistics provider

• Outbound Interaction
  • An OEM manufacturer needs material inventory from supplier.
    • Manufacturer initiates batch-based FTP retrieval from supplier FTP site on weekly schedule
    • Documents are retrieved from supplier to intermediate document store and processed

The Exposed Broker application pattern shown below, is based on a M-to-N topology that separates distribution rules from the applications. It allows a single interaction from an enterprise's source application to be distributed to multiple target partner applications concurrently and vice-versa.

The Exposed Broker application pattern applies to solutions where the source application starts an interaction that is distributed to multiple target applications across organization boundaries. It separates the application logic from the distribution logic based on broker/mediation rules. The decomposition/ recomposition of the interaction is managed by the Broker Rules tier.

The Exposed Broker application pattern reuses the Exposed Direct Connection application pattern to provide connectivity between the tiers. The Broker Rules tier may support the Message variation or Call variation (or both variations) of the Exposed Direct Connection pattern.

Business and IT Drivers

The primary business driver for selecting this application pattern is to allow one application to interact with one or more of multiple partner applications or one partner application to interact with multiple exposed applications across organization boundaries. Using a hub-and-spoke architecture instead of a point-to-point architecture allows for the seamless integration of applications while minimizing the complexity. A request for information can be routed to one of many targets or simultaneously to multiple targets. The resulting request message can be decomposed into multiple request messages, and the reply messages then recomposed into a single reply message using appropriate recomposition rules.

This externalization of routing, decomposition, and recomposition (aka mediation) rules from individual source and target applications increases the maintainability and flexibility and reduces the enterprise wide integration complexity.

The primary IT driver for selecting this application pattern is to allow loose coupling of clients and services with minimum modification to each. The solution should allow for multiple transmission protocols to be used and for transformation of protocols between client and service.

Solution

Select this Application pattern

For a legend, please see above.

This application pattern, as shown in the figure above, is divided into a number of logical components:

• The Back-end Application tier represents one or more applications that are interested in interacting with the Partner applications in another organization.
• The Exposed Broker Rules tier reduces the proliferation of direct connections. In addition, it supports message routing, decomposition and recomposition, message enhancement and transformation (aka mediation). These rules are often captured as business rules that govern the behaviour of the broker tier. This tier also uses a work-in-progress data store to retain the intermediate results from the responses coming back from target applications until all the necessary responses are received.
• The Partner Application tier represents new, modified existing, or unmodified existing applications in a partner organization. These applications are responsible for implementing the necessary business services.

Guidelines for use

To increase the flexibility of the solution and responsiveness to changing business requirements, it is recommended that particular attention is paid to definition of reusable messages/services that pass through the Broker tier.

Robust transaction processing systems should be used to implement the back-end applications to ensure availability, scalability, and performance.

A decomposition implementation (one source message to multiple target messages) requires state persistence and re-composition of the response messages.

Standards should be used where possible to minimize future changes required to the source and target applications. This is particularly important in an inter-enterprise solution.

• Provides support for mediated service interactions versus Exposed Direct Connection (this represents the best practice for service invocation however it is still an emerging pattern)
• Partner management tools may be required to provision & manage partner communities and may need to be developed as a custom part of the solution
• The Broker tier should support a variety of industry standards and protocols, such as:
  • Message formats in XML, Binary or structured text. For example, SOAP, REST, EDI, vertical standards such as RosettaNet, horizontal standards such as ebXML.
  • Transport protocols. For example, SMTP, HTTP/S, FTP/FTPS, JMS.
  • Security standards. For example, SSL, 3DES or PGP.

• Guidelines for REST style:
  • For Web-Oriented Architecture (WOA), REST could be used for a simple web environment. A possibility is to put REST interfaces on existing enterprise services, with mapping from REST service to WSDL service.

• Guidelines for Web services style:
  • For this pattern, where B2B exchange are based on web services, asynchronous messaging is supported by WS-Addressing profile from WS-I. Similarly, WS-secure conversation supports secure interaction, WS-ReliableMessaging supports reliable delivery, etc.
  • In B2B integration scenarios, RAMP specification enables additional function as an extension to the WS-I profiles.

Benefits

The benefits of this application pattern are:

• It allows the integration of multiple, diverse applications between partner organizations.
• It minimizes the impact to existing applications.
• The broker provides routing services, relieving the source application from being aware of the target application.
• The broker provides transformation services that allow the source and target to use different communication protocols.
• The broker can provide decomposition/recomposition of messages, allowing one request from the source to be satisfied using multiple target applications. The fact that the response is a composite of multiple requests and responses is hidden from the source application.
• The use of a central broker minimizes the impact of changes in location of the target application.

Limitations

Logic must be implemented at the broker for routing and decomposition/ recomposition tasks.

Since the routing, transformation, etc. rules reside at (and all enterprise messages are handled at) the broker hub, the hub needs to be scalable to handle large volumes of messages. This could be managed via federated hubs.

Putting the application pattern to use

• Inbound Interaction
  • A retailer places order with the warehouse.
    • Warehouse receives order request message from the retailer as a XML document over SOAP/HTTP
    • Broker tier applies routing rules on the XML document and exchanges the order message with the back-end applications as per the rule results
    • Response message from the applications is routed and sent back to the retailer as a XML document

• Outbound Interaction
  • A manufacturer needs to source the constituent parts of an order from the vendors
    • The order XML is decomposed by the broker tier into individual orders
    • The individual orders are routed to and placed with the vendor applications as XML documents
    • The responses from the vendor applications are recomposed into order status

The Exposed Router variation of the Exposed Broker application pattern, shown below, applies to solutions where the source application initiates an interaction that is forwarded to, at most, one of multiple target applications. The selection of the target application is controlled by the distribution rules that govern the execution of the connector component.

Business and IT Drivers

The requirements and their solution are less complex than those defined by the Exposed Broker application pattern in that decomposition of messages and transmission to multiple targets simultaneously is not required.

This pattern is also applicable to the 1:1 application integration scenario where source and target do not adhere to the same message and interface formats and therefore require a transformation service in the EAI Infrastructure.

Solution

Select this Application pattern

For a legend, please see above.

This application pattern, as shown in the figure above, is divided into a number of logical components:

• The Back-end Application tier represents one or more applications that are interested in interacting with the Partner Applications, one application at a time.
• The Exposed Router Rules tier represents any business rules associated with the message handling, such as routing and transformation. It receives requests from multiple source applications and routes them intelligently to the appropriate partner applications or vice-versa. This tier implements minimal business logic.
• The Partner Application tier represents new, modified existing, or unmodified existing applications. These applications are responsible for implementing the necessary partner business services.

Guidelines for use

The guidelines for this application pattern are the same as those for the Exposed Broker application pattern.

Benefits

The benefits of this application pattern are:

• It allows the integration of multiple, diverse partner applications.
• It minimizes the impact to existing applications.
• It provides routing services, relieving the source application from being aware of the target application.
• It provides transformation services that allow the source and target to use different communication protocols.
• The use of a central router minimizes the impact of changes in location of the target application.

Limitations

With the Exposed Router variation, there is limited ability in the router to manipulate the requests. It performs intelligent routing and protocol transformation, but does not have the ability to send simultaneous requests to the target applications based on one incoming request, nor does it have decomposition / recomposition ability.

Benefits

ITSO Electronics consists of multiple Retail stores that order supplies from external Wholesale companies. The Retail stores have a need to request the delivery dates of those supplies before ordering. Currently there is no integration of the Retail and partner Wholesale applications. All interaction between the two are done over the phone or by mail. A solution must be found to allow the Retail stores to request delivery dates from the partner Wholesale companies. To eliminate the need for the Retail departments to know which Wholesale company carries which supplies, a Router is needed to take incoming requests and direct them based on part numbers to the Wholesale company that carries them.

The Exposed Serial Process application pattern, shown below, modifies the M:N topology provided by the Exposed Broker application pattern by facilitating the sequential execution of business services hosted by a number of target applications. It enables the orchestration of a serial business process across enterprise boundaries, in response to an interaction initiated by the source application.

This is one of the more complex of Extended Enterprise application patterns as well as the most frequently encountered patterns. It provides a partner management and mediation tier as part of the public process realization.

The Exposed Serial Process application pattern separates the process logic from the application logic that is distributed across organization boundaries. The process logic is governed by serial process rules that define execution rules for each target application, together with control flow and data flow rules. It may also include any necessary adapter rules.

Business and IT Drivers

The primary business driver for selecting this application pattern is to support the automated coordination of the business process flow between partners. From an IT perspective, the key driver for selecting this application pattern is to improve the flexibility and responsiveness of IT by externalizing the process flow logic from the application logic.

Business Drivers:

• Support a structured exchange with business partners
• Support real-time one-way and request-reply "message flows" to and from trading partners
• Support dynamic routing of "messages/documents" between trading partners and a specific or multiple applications
• Support automated coordination of business processes between trading partners

IT Drivers

• Enable back-end integration with external trading partners/solutions
• Minimise application complexity
• Minimise enterprise complexity
• Improve maintainability
• Improve flexibility by externalizing process logic from application logic

All the business and IT drivers listed under the Exposed Broker application pattern apply here as well.

Solution

Select this Application pattern

For a legend, please see above.

The Exposed Serial Process application pattern is broken down into three logical tiers:

• The Partner Application tier represents an application in another organization that is interested in interacting with the Exposed Serial Process.
• The Exposed Serial Process Rules tier supports most of the services provided by the broker tier in the Broker application pattern, including the routing of requests, protocol conversion, message broadcasting, and message decomposition and recomposition. In addition, it supports the separation of business process flow logic from individual application logic. The process logic is governed by serial process rules that define execution rules for each target application, together with control flow and data flow rules. It may also include any necessary adapter rules. The combination of these process execution rules are stored in read-only databases. This externalization of process flow logic is essential for the implementation of a flexible and responsive IT environment that can respond quickly to changing business needs. It also makes it possible to compose new end-to-end processes by combining different business services provided by different applications. Finally, this tier uses a work-in-progress (WIP) database to store the intermediate results from the execution of different process steps.
• The Back-end Application tier represents new, modified existing, or unmodified existing applications that are responsible for implementing the necessary enterprise business services.

Guidelines for use

The flexibility and responsiveness provided by this application pattern heavily depend on the externalization of process execution logic from individual partner applications. Applications that are designed, based on a service-oriented architecture (SOA) approach, which have well-defined and coarsegrained business services that represent a unit of work, are better suited for participation in this application pattern. You must be able to compose these business services into an end-to-end process flow. A given service may need to participate in more than one end-to-end process.

Standards should be used where possible to minimize future changes required to the source and target applications. This is particularly important in an inter-enterprise solution.

Security is a primary concern when opening business processes to external organizations. The solution should include robust security mechanisms to protect resources.

Benefits

The Exposed Serial Process application pattern improves the flexibility and responsiveness of an organization. It does this by implementing end-to-end process flows across organization boundaries and by externalizing process logic from individual applications. In addition, it provides a foundation for automated support for Business Process Management that enables the monitoring and measurement of the effectiveness of business processes.

Limitations

There is no complex back-end application integration, no (content based) routing and/or mediation.

The composition/decomposition of requests is limited to transformation/translation specific events.

The public communication process support is basically limited to industry-driven B2B document and communication protocols (RosettaNet, ebMS, EDIINT etc.).

Putting the application pattern to use

With the successful integration of their internal retail and wholesale systems, ITSO Electronics has now decided to integrate with their external business partners. The goal is to integrate the external resellers with the internal wholesale systems. As with the internal retail system, orders are typically placed with Wholesaler A. However, when the Wholesaler A is unable to guarantee delivery within seven days, Wholesaler B is contacted to check the anticipated delivery date. Then, the order is placed with departments that guarantee the shortest delivery date.

To meet these business process automation requirements, ITSO Electronics chooses the Exposed Serial Process application pattern. The primary driver for this selection is the need for externalization of process logic from the business partner's application. This promotes flexibility and responsiveness to changing business needs.

This pattern provides a partner management and mediation tier as part of the public process realization as well as a private process tier to support long-running process-oriented requirements.

Business and IT Drivers

Business Drivers

• Share processes between enterprises
• Managed state for document exchage with enterprises
• Integrate internal workflow manager with partner shared business process flows

IT Drivers

• Managed complexity
• Provide exchange-based process integration with external partners interfaces

All the business and IT drivers listed under the Exposed Serial Process application pattern apply here as well.

Solution

Select this Application pattern

For a legend, please see above.

This is one of the more complex of the Extended Enterprise patterns as well as one of the most frequently encountered patterns.

The application is divided into logical tiers, Communication, Process and Application.

• The Exposed Process Rules tier is responsible for communication logic (send/receive documents) and the subsequent exchange of information between partners (send/receive documents) within the public process
• The Private Process Rules tier provides the rule/business logic for the integration with back-end applications and orchestrates the state between internal and external processes
• The Application tiers are responsible for business logic
• The Read/Write data is the primary information holding resource (no integration with other data or application resources in this pattern)

Communication is asynchronous between tiers and status/receipt messages are optional.

Guidelines for use

The Application pattern should support a variety of industry standards and protocols including XML, EDI, ebXML, and SOAP.

Router/Broker support is required for the mediation/routing.

This pattern requires Partner management to support trading partner (physical) communications.

Benefits

The Exposed Serial & Orchestrated Processes application pattern improves the flexibility and responsiveness of an organization. It implements end-to-end process flows across organization boundaries that externalize process logic from the individual application. Further flexibility is introduced by the externalization of task resource resolution rules.

In addition, it provides a foundation for automated support for Business Process Management. This enables monitoring and measurements of the effectiveness of business processes.

Limitations

This pattern may require customization of the B2B gateway and inter-enterprise integration tools.. It also may require additional development for human work-flow components. The Back-end application integration may increase in complexity. The pattern is limited to non-integrated system management and monitoring.

Putting the application pattern to use

A producer of computer parts wants to integrate with the supply chains of several PC manufacturers. This computer parts producer may have a large number of business processes controlling production, parts inventory management, procurement, and other critical activities that need to be integrated with the supply chain. They would recognize that this B2B integration requires more than simple application mapping. Long-running inter-business workflow must be managed and mapped into private processes. In order to meet these requirements they could choose the Exposed Serial & Orchestrated Processes application pattern.