![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
Previous issues of the IBM DeveloperToolbox technical magazine have explored the IBM Patterns for e-business project and its best practice architectures for Web application development. The patterns solution designs were derived from successful, real world e-business application implementations and are under constant evaluation and reassessment through use in IBM customer engagements.
The same IBM architects, whose successful e-business development experience has shaped the patterns solution designs, have written a new book, Patterns for e-business, a Strategy for Reuse. The book expands on the current base of e-business development knowledge, redefining e-business terminology to simplify Web-based application development. It outlines the primary business patterns that enable fundamental e-business functionality and discusses how to integrate combinations of patterns into one seamless application. It provides an extensive case study to illustrate the use of the Patterns for e-business in a real-world business environment.
Recent analysis of successful business-to-business (B2B) methods on the Web prompted these authors and other patterns architects to reengineer the Patterns for e-business B2B solution designs. The Patterns for e-business now categorize all solution designs that enable B2B functionality on the Web under the Extended Enterprise business pattern, as these designs allow an enterprise to extend its business activities beyond its own organizational boundaries. The Extended Enterprise pattern addresses the interactions and collaborations between business processes in separate enterprises. This pattern can be observed in solutions that implement programmatic interfaces to connect inter-enterprise applications, automating the previously manual and far less efficient processes to invoke a B2B exchange.
This first of a two-article series examines the reasons a business would want to develop an Extended Enterprise Web application and demonstrates how using the newly evolved solution designs of the Patterns for e-business can take less time and developmental risk than building an application from scratch. This article discusses in detail the first two of the five available Extended Enterprise solution designs, also known as application patterns. The second article in this series will detail the remaining three Extended Enterprise application patterns.
Extended Enterprise - who needs it?
The Extended Enterprise business pattern enables internal cost savings by streamlining business interactions with external organizations. Large organizations structured into multiple business units that operate semi-autonomously also can use the Extended Enterprise pattern internally just as separate organizations would to integrate their distinct business processes. A good example of the Extended Enterprise pattern is supply-chain execution in which automated processes work across a supplier network. Any company that needs a Web-based application to integrate with core business systems and databases, both internal to that business and those of trading partners, can benefit from the Extended Enterprise pattern. A well-designed Extended Enterprise application can aggregate, organize, and present information from these various sources, combining several formerly distinct processes into a single, enhanced efficiency workflow.
Consider an online travel agency that enables customers to make travel arrangements. Customers can choose from a wide variety of accommodation options, including resorts, hotel chains, and small bed-and-breakfast establishments. The travel agency requires that all participating major business partners, such as resorts and hotel chains, provide programmatic interfaces that can be invoked in real time for checking room availability and making reservations. This is a classic example of the B2B programmatic integration enabled through the Extended Enterprise pattern.
Conversely, small bed-and-breakfast establishments usually cannot afford to provide such programmatic interfaces to their reservation systems. To accommodate such small business partners, travel agents' Web sites provide a user interface that can be accessed by the operators of the bed-and-breakfast establishment for manually entering room availability into the system. Such user interface-based interactions between trading partners often are necessary, though they do not take advantage of the automated processes available through the Extended Enterprise pattern. Instead, they can be modeled using the Self Service business pattern documented elsewhere in the Patterns for e-business.
How Extended Enterprise applications work - public and private processes
Figure 1 details the general problem that companies encounter when seeking to integrate their business processes with those of another enterprise. The Extended Enterprise business pattern addresses this problem by public and private processes.
Figure 1. The general problem addressed by the Extended Enterprise business pattern
Interactions between business partners form a public process or, potentially, multiple distinct public processes. These public processes are shared by both business entities partnering together in the given transaction. Business partners must maintain their organizational independence, however, so each of these public processes must be integrated into the private process flows implemented by each trading partner. These private processes are not shared and are fully under the control of the individual enterprise. The integration of private and public processes might be as simple as passing data to a particular application or as sophisticated as initiating or resuming a multi-step workflow involving several applications and user interactions.
An abstracted example clarifies the business partner relationships and interactions involved in an Extended Enterprise transaction. In any given exchange, business partner A and business partner B agree to share specific business processes and a process flow. Business partner A invokes a public process flow that may invoke a specific private internal process flow within business partner B's organization. Business partner A is not concerned with the details of business partner B's private process flow. Instead, business partner A cares only about the results expected in response to the invoked public process. The golden rule of the Extended Enterprise pattern is that the less known about the business partner's private processes and application implementation details, the better. This allows for loose coupling between partnering applications, which enables organizations to evolve their applications without affecting a business partner's applications.
Maintaining public processes at a level removed from enterprise private processes brings flexibility and autonomy to the trading partner community, especially as the network grows beyond simple exchanges between two business partners. Version and configuration management of public processes is important as the number of business partners and frequency of change increases. Public processes can be created specifically for a set of trading partners or they can conform to an established industry standard.
RosettaNet, a self-funded, non-profit organization, provides one such standard. RosettaNet was formed as a consortium of major information technology, electronic components, and semiconductor manufacturing companies working to create and implement industry-wide, open e-business process standards.
These standards form a common e-business language, aligning processes between supply-chain partners on a global basis. RosettaNet Partner Interface Processes (PIPs) define business processes between supply-chain partners. An open, common networked-application framework, the RosettaNet Implementation Framework (RNIF) provides common exchange protocols that enable the implementation of PIPs.
Extended Enterprise application patterns
The specific functionality supported by a public application shared by trading partners or the internal private applications that integrate with these public processes depend on the particular details of the trading partner agreements and service level agreements between the organizations involved. However, whether based on an industry standard such as RosettaNet or specifically tailored for a bilateral trading agreement, a survey of such applications in multiple industries reveals certain common approaches that have proven successful in Extended Enterprise arrangements. The Extended Enterprise application patterns that follow document two of the five currently defined approaches. The second article in this series will detail the remaining three Extended Enterprise application patterns.
The Document Exchange application pattern gives structure to the batched electronic exchange of data by using message formats agreed to by the trading partners engaged in an Extended Enterprise transaction.
Companies seeking to increase the efficiency of interactions between enterprises use this pattern to begin exchanging electronic documents instead of less efficient paper document exchange. As the primary benefit, this electronic exchange eliminates the need for error-prone manual re-entry of data.
This is the ideal application pattern for businesses whose current needs can be satisfied by the batched exchange of electronic documents, but whose business requirements do not call for direct invocation of a business partner's systems in a real-time fashion. Large organizations often require this type of electronic message exchange of their business partners. For example, they may mandate the use of Electronic Data Interchange (EDI) transaction sets over a particular Value Added Network (VAN) for certain interactions, such as order placement.
A VAN is a networking service that leases communication lines to subscribers and adds extra services or capabilities, such as security, error detection, guaranteed message delivery, and a message buffer. EDI is a standard format for exchanging business data. An EDI message contains a string of data elements, each of which represents a singular fact, such as a price, product model number, and so on, separated by a delimiter. The entire string is called a data segment. One or more data segments framed by a header and trailer form an EDI transaction set. EDI transaction sets are based on standard, established formats such as X12 or EDIFACT to enable communications between the VAN mailboxes of trading partners for sending and receiving documents.
Any sort of business-to-business interaction requires the exchange of a series of messages between trading partners. The Document Exchange application pattern uses custom built business logic to link together applications that process these mutually agreed to messages. This automates the overall business process. To facilitate this type of functionality, the Document Exchange application pattern is divided into at least three different logical tiers: Partner, Translator, and Backend application.
- Partner. Represents a set of trading partner applications whose characteristics are unspecified. In other words, the technological implementation details of these systems are not disclosed. However, trading partners mutually agree upon the message format and the means of exchanging these messages.
- Translator. Retrieves such mutually agreed upon messages from a persistent buffer and decodes them into messages that can be used by the internal business processes of the receiving organization. Decoded messages are then stored in a Work-in-Progress data store.
- Back end. Responsible for processing the decoded messages. It typically reads decoded messages directly from the Work-in-Progress data store, as shown by the direct communication link between these nodes in Figure 2. After processing decoded messages, back-end applications may generate responses that are delivered to the originating partner through a reverse flow of messages.
Figure 2. The Document Exchange application pattern
Batched exchange of electronic documents implies asynchronous communication between trading partners. There is a need for a persistent buffer that stores all the messages that are received from multiple business partners to be translated and processed at a later time. For this reason, this application pattern is best suited for implementing EDI-based integration using VAN mailboxes. However, newly emerging Web technologies might soon prove an effective alternative method to sending EDI interactions across a VAN. In both cases, the translator tier is implemented using EDI translation packages.
Use a rules-based EDI translation package when implementing the Document Exchange application pattern. This type of translation package maps EDI messages to internal messages using agreed-to rules and allows the quick definition and redefinition of messages. More sophisticated translation packages that convert EDI messages into an automatic request to a transaction monitor, such as an order processing system, also can be used to increase the efficiency and reduce the latency of business interactions through document exchange.
The Document Exchange application pattern does have some limitations. As mentioned earlier, it is best suited for implementing EDI-based integration between organizations. EDI is a well-established standard, but it is deployed only by a small number of companies. Participation in an EDI-based network requires a subscription to a particular VAN that is typically expensive. Furthermore, it mandates the use of a certain IT infrastructure by all trading partners. This loses the flexibility in connecting to business partners that might have different IT infrastructure capabilities. For these reasons, this application pattern can be both expensive and inflexible.
Further, the Document Exchange application pattern focuses on achieving batched exchange of information and cannot be used for gaining direct access to specific services provided by business partner systems. Returning to the earlier example of an online travel agency, consider the situation when this agency needs to confirm a hotel room reservation and provide a confirmation number to the customer in a real-time fashion. Here, the travel agency system may need to directly interface with the reservation system of that hotel chain and execute the required transaction instantaneously. Under such circumstances, you should consider more advanced application patterns that are discussed in the second article of this two-article series.
The Document Exchange application pattern would be more appropriate in the following situation. An auto parts manufacturer enters into an agreement to supply parts to a major car manufacturer. The car manufacturer manages its supply chain through an established EDI network and mandates that all suppliers communicate using auto industry EDI transaction sets. To meet this mandate, the auto parts manufacturer chooses the Document Exchange application pattern.
As shown in Figure 3, the Exposed Application pattern structures a system design that allows specific applications to be accessed directly by trading partner systems across organizational boundaries. It is divided into at least two logical tiers:
Figure 3. The Exposed Application pattern
- Partner tier. Represents a set of trading partner applications that are interested in invoking specific business logic on the Exposed Application tier.
- Exposed Application tier. Represents a new, a modified existing, or an unmodified existing application. This tier is responsible for implementing any necessary business logic and access to business data. Because this tier is directly exposed across organizational boundaries, it must implement or exploit security features, such as authentication, authorization, confidentiality, integrity, and logging for non-repudiation purposes.
Typically, an asynchronous communication mechanism is used for inter-enterprise integration. This minimizes the dependency of the service levels of one organization on another organization's applications that might occur using a synchronous communication mechanism. Even though companies agree on certain service levels, such as availability and response time, ensuring that these service levels always are met is difficult when implementing a solution across organizational boundaries. The use of an asynchronous communication mechanism ensures that during such a failure, requests still can be sent to trading partner systems to be processed later. Meanwhile, the application under consideration still can continue its processing without having to wait for a response from the business partner systems. Asynchronous communication also provides a degree of isolation between two businesses. The requesting application can never synchronously demand excessive resources or locks on the trading partner systems.
Note that asynchronous communication does not necessarily mean a delayed response. Fast asynchronous communication can be used in circumstances where business requirements warrant a quick response. A fast asynchronous communication mechanism enables immediate responses when business partner systems are able to process the request at the time of receipt. If unable to process the request at this time, the request is processed later. Fast asynchronous communication is becoming increasingly popular for inter-enterprise integration, because it provides the benefits of both asynchronous and synchronous communication styles under most circumstances.
Predominantly, asynchronous Message Oriented Middleware (MOM), such as IBM MQSeries, is used to implement this application pattern. The most prevalent benefit of the Exposed Application pattern comes from the strengths of the common MOM, the use of which often is enforced by dominant business partners. The key features delivered by MOM are guaranteed delivery and once-only delivery of messages.
Also, it is possible to use synchronous middleware based on standards such as Common Object Request Broker Architecture (CORBA) and Distributed Component Object Model (DCOM). Typically, Virtual Private Networks (VPNs) interconnect business partner applications and implement many of the security features at the network level. In the future, open standards, such as HyperText Transfer Protocol (HTTP), may play a more significant role in the type of guaranteed delivery of messages between organizations enabled by this application pattern.
While consistent use of MOM benefits the Exposed Application pattern in many ways, it also limits the pattern in others. Because it implies the use of common middleware by all participating business partners, this approach loses the flexibility in connecting to business partners that might have different IT infrastructure capabilities.
Two other limitations to this application pattern exist. First, direct integration between applications of any kind is typically inflexible. Any changes to one application may affect other applications unintentionally. This is especially dangerous while integrating across organizational boundaries. Any changes to the exposed application tier may require changes to many trading partner systems. Such changes can be both expensive and time consuming. Unintended effects can be minimized by using message-based adapters that wrap the applications in the exposed application tier. Message-based adapters are small programs that convert the mutually agreed upon messages into API calls to existing or new back-end applications. This layering technique isolates the back-end applications from trading partner systems and increases flexibility. Any changes to these back-end applications only impact the adapter, provided there is no need to change the mutually agreed-upon messages.
Second, this application pattern implements a point-to-point interface between trading partner systems and the exposed application tier. Because of this, it cannot be used for intelligent routing of requests, decomposition and recomposition of requests, and for invoking complex business process workflow because of a request that was received from a trading partner system. Under such circumstances, a company should consider more advanced application patterns discussed in the second article of this series.
As an example of the Exposed Application pattern in use, consider an auto insurance portal that enables customers to compare quotes from many insurance companies at a single Web site. Customers are asked to enter automobile details, driving history, and the terms and conditions of the requested insurance coverage. The portal ships this information to a group of insurance companies soliciting their best quotes. The insurance portal promises to gather more than 10 quotes in an hour's time. All participating insurance companies are asked to integrate with the portal using a common MOM. A small regional automobile insurance company wants to participate in this new sales channel. It currently has an online auto quote engine that can be integrated with the portal directly using an adapter. The Exposed Application pattern is an ideal solution for this simple integration problem because only two applications are involved, and the interactions with the portal at this time are limited to providing online quotes.
The Extended Enterprise Business pattern documented in the IBM Patterns for e-business represents the evolution of B2B functionality on the Web. Using any of the five application patterns outlined in the Extended Enterprise pattern, a business can automate and streamline its interactions with other organizations, increase enterprise efficiency, and save time and money. This article documents the first two of these five application patterns. The second article in a future issue of the IBM DeveloperToolbox Technical Magazine will document the remaining three Extended Enterprise application patterns.
-
"Patterns for e-business, architecting the Web" article
-
"Creating pervasive Web applications with Patterns for e-business" article
-
IBM Patterns for e-business
- Categories: Articles and white papers, e-business,
Redbooks
- IBM Patterns for e-business Series Redbooks
Anthony Petersen currently works as a Software Engineer in the IBM Solution Technologies division in Austin, Texas. You can contact him at anthpete@us.ibm.com.
