Business-to-Business Integration(B2Bi) Architecture

Roy Abraham




1) Introduction
The B2Bi is a part of overall enterprise architecture. There are six important criteria which, fully define an enterprise architecture, they are,
a) Components: Elements or units upon which enterprise applications are built. For example, objects in Object Oriented Architecture and services in Service Oriented Architecture.
b) Message: How components communicate to each other. Describes not only the contents but also the temporal and special relationship of the messages. For example, structured and unstructured contents sent synchronously or asynchronously.
c) Topology: The general layout of the components and their messages. For example, hub and spoke or message bus.
d) Constraints: Constraints on components and messages such as multiplicity, concurrency, transient nature, sequencing etc.
e) Layers: Grouping and abstraction of components and messages according to the functionality and homogeneity. For example, presentation layer, business logic layer and persistence layer.
f) Rationale: Describe the pros and cons of selecting a particular architecture.
This paper is mostly devoted to topology and layered architecture. There are in general four types of topologies are prevalent in enterprise architecture such as hub and spoke, message bus, service bus and hybrid. However, there is considerable difference in the organization, responsibility, administration and layout of each of these topologies with respect to B2B and EAI enterprise relationship.

2) Hub and Spoke Topology

In this topology, a hub connects to one or more spokes to form a star layout. The communication among spokes is possible only through the hub. In a B2B hub and spoke topology, each node is most likely owned and managed by separate trading partners. On the other hand, all the nodes are within an enterprise environment for an EAI hub and spoke. The nodes of B2B hub and spoke are implemented across the firewalls. An EAI hub and spoke is implemented within the firewalls.

2.1) B2B Hub and Spoke: The B2B eMarketplace is a typical example of this type of topology. Each supplier and buyer trading partners connects to a hub, which itself may be another trading partner for routing the messages. In most cases, hub is managed and administered by a standard organization by that vertical industry. The spokes need to be compliant with the specifications provided by the standard organization especially messaging protocol and transport protocol. A number of vendors provide pre-packaged on-ramp applications to facilitate setting up the communication between hub and spokes. For example, suppliers and buyers may send messages such as purchase order and invoice to market place using on-ramp application interfaces. Two common message protocols used are Commerce XML (cXML) of Ariba and XML common Business Library (xCBL) of Commerce One. The HTTPS is the most commonly used application layer transport protocol.


Figure 1: B2B Hub and Spoke topology for B2B eMarketPlace.


2.2) EAI Hub and Spoke:
The Hub and Spoke integration described earlier follow this topology. Both hub and spokes servers reside inside the firewalls of an enterprise and managed and administered by the enterprise. Similar to on-ramp application used by spokes to communicate with the hub in B2B hub and spoke described earlier, an adapter is used to communicate between the hub and spokes in this topology. Since all the nodes are within the enterprise application system, the enterprise need not have to follow any specific standards for implementing message and transport protocols. B2B integration architecture of EAI hub and spoke with B2B hub and spoke are shown in figure 2 for outbound message and figure 3 for inbound message. The enterprise application system in the EAI hub and spoke shown is for a Buyer, for example.

In the figure 2, the core business of the enterprise application system (of Buyer, for example) creates a Value Object (VO) encapsulating business information for a purchase order. The VO is marshaled to an XML document and sends to on-ramp in the integration server either synchronously or asynchronously through JMS. On-ramp maps the XML message to the xCBL (for Commerce One) or cXML (for Ariba) and sends to the eMarketPlace server over HTTPS. The eMarketPlace server (for example, Commerce One’s Market Site) routes the purchase order to the appropriate supplier.


Figure 2: Architecture for an outbound message involving B2B and EAI hub and spoke.



Figure 3: Architecture for an inbound message involving B2B and EAI hub and spoke.

The supplier process the purchase order and create an invoice in xCBL format and sends back to the eMarketPlace server which in turn routes to the initiating buyer. The Buyer on-ramp receives the invoice message and maps xCBL to XML message. In general only the business data in the xCBL is mapped to the XML message and send to business processing in the application server. The meta-data such as the envelope information of xCBL is persisted directly from the integration server itself as shown in figure 3.

3) Message Bus Topology: In this topology, every server node in the enterprise connects to a message bus. If two nodes need to communicate, the source node publishes the message to the message bus and the recipient node subscribes to that message. This type event model can be asynchronous if the message bus is connected to a Message Oriented Middleware (MOM) provider. For example, if the message bus provider is built on MQSeries or JMS, it facilitates asynchronous mode of messaging. Each message published and subscribed must be unique in the message bus to avoid name conflict. In other words, message must be name space qualified. If the nodes are located and managed in different trading partners, then the configuration is a B2B message bus topology. If all the nodes are within an enterprise application system, such a configuration is EAI message topology. The nodes of the B2B message bus are implemented across the firewalls. On the other hand, all the nodes are within the firewalls in an EAI message topology.

3.1) B2B Message Bus: Individual trading partners connect to a message bus. In most cases, such a message bus is managed and administered by a standard organization by that vertical industry in which the trading partners belong. Examples of such message bus are Global Data Synchronization Network (GDSN) of UCCNet and SWIFTNet. However, each node must follow the specification standard enforced by the message bus on messaging and transport protocols. For example, the Catalogue Item (CI) messages exchanged between manufacturers and retailers in a GDSN message bus must be EAN.UCC compliant as shown in figure 4.


Figure 4: B2B Message Bus topology for UCCNet.


3.2) EAI Message Bus: The message bus integration described earlier follow this topology in its simplest form. However, an enterprise-wide message bus catering to different divisions or sections of the enterprise located in the corporate network backbone within the corporate firewall provides a better topology albeit complex. This Enterprise Message Bus (EMB) offers better monitoring, performance and security of the message. This is because many of the tools available provide a wide range of features like clustering, persistent queue, brokering (routing the message) and so on. The architecture of such a topology is shown in figure 5.


Figure 5: Enterprise Message Bus topology.

For example, the application server in the Pricing division publishes a message to the EMB, which is subsequently subscribed by the ERP server in the Management division. After completing the management decision, ERP server publish another message to the EMB, which is subscribed by the CRM server at the Marketing division.

4) Service Bus Topology: Service Bus topology is based on web services and Service Oriented Architecture. Although very similar to message bus topology, service bus is based on open standards. Each node, the service provider (WSDL producer) exposes the services it is going to provide through a WSDL. The WSDL interfaces are published and registered with a service bus connected to a UDDI server. A node, the service consumer searches and finds the right service from the service bus. Then that node binds and invokes the service based on the WSDL and creates a SOAP instance and sends to the address of the node as described in the URI of the WSDL interface. Note that the node (service consumer) which consumes the WSDL (WSDL consumer) is the one which creates the SOAP message (SOAP producer). A service bus may provide additional asynchronous based messaging, for example using a MOM provider. The same node may act as service providers for some services and service consumers for some other services.

If the nodes are located and managed in different trading partners, then the configuration is a B2B service bus topology. If all the nodes are within an enterprise application system, such a configuration is EAI service bus topology. The nodes of the B2B service bus are implemented across the firewalls. On the other hand, all the nodes are within the firewalls in an EAI service bus topology.

4.1) B2B Service Bus: Individual trading partners may connect to the service bus as service providers, service consumers or both. Although web service can compartmentalize the various vertical industries into yellow pages, a service bus mostly handle services for one or two similar vertical industries. It is less complex and easier to manage and administer for a standard organization by that vertical industry in which the trading partners belong.


Figure 6: B2B Service Bus topology.

4.2) EAI Service Bus
The service bus integration described in the section 1.5 of chapter 1 follow this topology in its simplest form. The enterprise-wide integration of applications is made possible by architecting an Enterprise Service Bus (ESB). In this topology, the service bus is located in the corporate network backbone within corporate firewalls. This topology is best suited when disparate application systems such as legacy, mainframe and J2EE are spread all over the enterprise.

For example, Marketing and Management divisions publish their CRM and ERP services the service bus through their respective WSDLs. The application server in the Pricing division uses the ERP WSDL to send a SOAP message to the ERP server. The same way, ERP server uses CRM WSDL to create and send a SOAP message to CRM server as shown in figure 7

Figure 7: Enterprise Service Bus topology.
5) Hybrid Topology
In many situations, an enterprise is forced to adapt a topology which is a combination of previously discussed topologies due to the legacy commitments. However, the most common one is a combination of hub and spoke and message bus or service bus. Since message bus and service bus provides a high level of loose coupling among the nodes, it best suited for integration of divisions (or departments) in the enterprise. The ERM servers in a division are connected to an integration server forming a hub and spoke. The integration server in each division forms the nodes of a message or service bus as shown in figure 8.


Figure 8: Hybrid topology with hub and spoke and service bus

6) Layered Architecture
A typical J2EE application environment consists of 3 tiers; presentation, business logic and persistence as shown in figure 9(a). However, in B2Bi, presentation tier is replaced by an integration tier. If an application provides both web interface and B2B interface, then both tiers has to be provided as shown in figure 9(b).



Figure 9: Layered architecture: (a) with web only and (b) web and B2Bi
Each layer contains components of similar functionality pertaining to that layer. For example, presentation layer consists of JSP and Servlet components. As the architecture become more complex, dissimilar and inappropriate components starts appearing in each layers. To prevent this, a more expanded or n-tiered architecture may be implemented. In general, the entire complex architecture can be divided into three tiers; front end tier, middle tier and back end tier. The layers contain J2EE components involved in the J2EE design patterns1. In many architectural scenarios, it might be difficult to compartmentalize the component functionalities among the layers. The integration layer and messaging layer share many common features. For example, MOM (Message Oriented Middleware) tools perform more or less same functionality of both integration layer and messaging layer.

6.1) Front end Tier: The front end tier consists of client layer, proxy layer, presentation layer, decorator layer and controller layer for web interface. For B2Bi, the presentation, decorator and controller layers are replaced with an integration layer. The layers in the front end tier communicates with the client (web and B2B), does the initial processing of the request data (or final processing of response data) and sends the information to the middle tier for a request message (or receives the information for response message). The layered architecture of front end tier is shown in figure 10.


Figure 10: Layered architecture for front end tier.

• Client Layer: Client tier provides user interface with users and actors. Usually in J2EE architecture this is implemented through a Web Client such as a web browser. However, this can be extended to different kinds of clients such as Wireless Client, CORBA client, web service client and B2B client.
• Proxy Layer: Those system components which reside in De Militarized Zone (DMZ) or semi-secured area are encapsulated in the Proxy layer. Caching, system recognition, authentication through LDAP, vendor specific credential validation, store and forward, reverse proxy are some of the services provided by the components reside in this layer. Usually proxy servers provide this functionality. Note that this proxy layer must not be confused with the functionalities provided by the classic proxy design pattern described by the Gang of Four.
• Presentation Layer: This layer provides the View part of the Model-View-Controller (MVC) design pattern. In most of the J2EE implementations, this is done using JSP. This layer logically located in a web container. Usually Client tier and Presentation layers are combined to have a single presentation layer. In most of the enterprise systems, considerable amount of resources are consumed by the presentation layer as it is the "brain" of user interaction. The recent evolution of XML as Model and XSLT as View in the presentation layer, further improved the functionalities of this layer. The need for various presentation techniques required in enterprises for multitudes of evolving client technologies such as Wireless and print servers results in a thick and fat presentation tier.
• Decorator Layer: Decorator layer encapsulates functionalities which intercept client messages to present to the system and vice versa. For example, pluggable decorating filters may be used for I18N whenever necessary. Incoming requests and outgoing responses (preprocessor for requests and post processors for response) are redirected to a filter which does necessary conversions based on the user Locale. Software filters may be used for formatting dates, currency conversion and language texts. Other functions may include checking security credentials, document format conversion, document type conversion (eg. XML to Java Bean or Form Bean) and image format conversion. In J2EE, this may be implemented through Servlet filters.
• Controller Layer: The controller layer controls the interaction between the front end and middle tiers. This is implemented through Java Servlets which act as the Controller part of MVC. The controller layer functionality includes redirection and invocation services, maintaining conversational state of clients through web sessions (HTTP Session) and handling exceptions thrown by middle tier. Note that conversational state of business logic is provided through Stateful Session beans which reside in Business Logic layer. Data transfer across this layer is provided through Form Beans which act as View Helper and through Value Objects and these constitute the Model part of MVC. This layer is logically located in a web container. Presentation layer and Controller layer together constitute the Model-2 variation of MVC design pattern.
• Integration Layer: The integration layer is the B2B counter part of the three layers described earlier. This layer provides B2B related plumbing services to the application such as mapping, transformation, XML processing etc. This layer is logically located in an integration server.
6.2) Middle Tier:
The middle tier contains service layer, interaction or access layer, façade layer and business logic layer. The layered architecture of middle tier is shown in figure 11.

Figure 11: Layered architecture for middle tier.
• Service Layer: The service layer encapsulates domain specific services to the underlying sub-systems. This includes Java Naming and Directory Interface (JNDI) look up services to EJB home interfaces, Java Message Service (JMS) components, data sources, integration adapters, and JCA connection factories in the respective subsystems. Service Locater components which are usually implemented through stateless EJBs, are located in this layer. Very often this layer is too thin such that it can be merged with the interaction or business logic layer. All the layers in the middle tier are logically located in an EJB container. Data transfer across the layer is provided through Value Objects.
• Interaction Layer: The interaction layer holds Business Delegate1 components which allows loose coupling between the front end and middle tiers. The interaction layer also contains B2B specific and web specific components. In the absence of a service layer, interaction layer performs the JNDI look up related services. The exceptions thrown and re-thrown from the underlying layers are captured in the interaction layer and converted into user friendly messages to the controller layer (for web application) and business friendly messages to the integration tier (for B2B application). In a pure web application, data validation may be achieved in the front end (preferably in Controller tier), close to the client. However, in a mixed application environment (such as web as well as B2B), validation needs to performed preferably in the first common layer to avoid unnecessary duplication of data validation. The interaction layer fits the bill for this.
• Facade Layer: The Facade layer consists of session facade1 which provides a single point of access to the underlying business components in the subsystem. This enables loose coupling of components in business logic layer and the components in the interaction layer. The client view of the business logic layer is completely hidden and is made available only through the session facade. For example, clients can not access any Entity beans directly except through the session facade. Usually session facade components are implemented as a stateless session bean. However, if non-web clients such as CORBA clients or B2B clients need to access business logic components, to maintain state a stateful session facade may be added in this layer.
• Business Logic Layer: Business Logic layer abstracts the problem domain for the application. This layer enforces the business rules, logic and process. Business logic is implemented through Session and Entity Beans. Bulk access across the tier is provided through Value Objects.
6.3) Backend Tier:The data access layer, persistence layer and messaging layer are the major layers in the backend tier. The layered architecture of back end tier is shown in figure 12.

Figure 12: Layered architecture for backend tier.
• Data Access Layer: The data access layer consists of Data Access Objects (DAO) which abstracts and encapsulates all the access to the data source. The DAO manages the connection with the data source to retrieve and store data irrespective of storage type such as relational, object-oriented, native XML etc. Thus data access layer decouples the business logic and the persistence mechanism.
• Persistence Layer: Persistence layer permanently saves the object state by providing database CRUD (Create, Retrieve, Update and Delete) services. The java business objects follow hierarchical model (Tree structure) data structure. However, the most popular mode of persisting data is through relational model (Table structure) due to its inherent advantage of storing and retrieval of data. The implementation of the persistence can be accomplished through JDBC (data centric), entity beans (application centric) or using JDO (object centric). As the popularity and performance of native XML databases improve and XML CRUD tools such as XQuery, XUpdate and XPath receive wider acceptance, afore mentioned hierarchical data may be persisted as is.
• Messaging Layer: Messaging layer encapsulates the messaging services provided by the application. Although both synchronous and asynchronous messaging components can be encapsulated in this layer, asynchronous messaging components such as JMS components and MOM components are more common. Components in this layer are used to send and receive messages from the enterprise message bus in the corporate message backbone.
7) Conclusion
The B2B architecture does not stand alone. It is part of enterprise architecture. Hence this paper discussed both B2B and EAI integration architecture together in the J2EE framework. All the important architectural topologies and architectural layers are discussed in this paper. The right architecture must be selected on a case by case basis based on technology, functional and non-functional requirements.

References:
1. Alur, D., Crupi J., and Malks, D. Core J2EE Patterns, Prentice Hall, 2001.
2. Gamma, E., Helm, R., Johnson, R., and Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994.
____________________________________________________________________________
This document is for reference only. For actual implementation, please contact the author. No part of this blog is used or reproduced without the written consent from the roychettan@gmail.com