This is the second in a two-part series of articles introducing the benefits of a hub-and-spoke architecture and IBM's WebSphere Business Integration (BI) Server. In the first article, we detailed the financial and technical benefits of using a hub-and-spoke design, such as reduction in software maintenance costs, overall simplicity compared to point-to-point programs, ease of general administration, and a more modular design allowing the business logic to be application independent.

Here, we start with the application independent business process modules contained in the hub, which work their way through the design and purpose of each of the major components of IBM's WebSphere BI Server. After an introduction to the major components, we conclude with the details of handling updated data using WebSphere BI Server cross-referencing tools to synchronize data.

WebSphere BI Server: ICS and Repository

Recall that in a hub-and-spoke architecture, all integration data flows through the ICS hub, making it a convenient location for integration business logic. As the container of business process modules, the ICS provides an opportunity to separate business logic software from the complexities of application connectivity.

WebSphere BI Server: Collaborations

Because collaborations are application independent, they can be shared and reused. IBM provides over 70 prebuilt collaborations, potentially deployed with 10 minutes of configuration. These prebuilt collaborations represent hundreds of years of experience working directly with clients - they're the common solutions to real-world problems. Examples of popular prebuilt collaborations include Sales Order Processing, Item Synchronization, and Customer Synchronization.

Given prebuilt business logic modules, as diagrammed in Figure 2, the task becomes one of understanding the logic and knowing what configuration options to set.

WebSphere BI Server: Business Objects

Each business object has a name, so it's easy to tell whether it's an SAP customer or a Siebel customer. Each business object also has a verb, such as Create, Retrieve, Update, or Delete. Finally, each business object is full of attributes, such as FirstName and LastName, and their values.

It's important to note the effect that the verb has on the data. Without the verb, the data in a business object represents an entity, nothing more. With the verb, a business object is actually an event. Instead of simply Jane Doe, a business object is actually the creation of Jane Doe, or an update of Jane Doe.

When a business object that represents the creation of Jane Doe is delivered to a collaboration, the collaboration typically needs to know specific information that the business object contains, such as Jane Doe's zip code. In order to obtain specific values, the collaboration needs to know a description of the business object. The data representations of business objects are supplied in Business Object Definitions (also referred to as BODs), stored in the Repository (see Figure 3).

Essentially, a business object is a data structure. At design time, defining a business object consists of naming a series of fields (called attributes) and their data types, and also defining a list of supported verbs. At runtime, each business object instance will have one of the verbs from its list, and will have its attributes filled with actual data. Business object attributes don't have to be primitive data types, they can be other business object types or arrays of other business object types. Because business objects can be nested, they can represent very complex data schemas.

Business Objects and Collaborations

Prebuilt collaborations are application independent, so they don't reference the specific fields of an SAP customer or a Siebel customer. Instead, this application-specific data is converted to the generic data expected by the collaboration. Business objects used by collaborations are called Generic Business Objects (also referred to as GBOs). The business objects initiating the flow of an event from an application are called Application Specific Business Objects or ASBOs (see Figure 4).

This is a one-to-many relationship where, for example, there is one Customer GBO and a potentially unlimited number of Customer ASBOs. As you can imagine, each application, from SAP to Siebel to PeopleSoft, has its own specific representation of a customer.

WebSphere BI Server: Maps

Because the application-independent collaborations expect generic business objects, and the applications themselves provide application-specific business objects, there must be a conversion between ASBOs and GBOs. In WebSphere BI Server, this conversion of data is done with maps. The mapping objects are passed an ASBO and return a GBO if the data is heading from an application into a collaboration. Or, the mapping objects are passed a GBO and return an ASBO, if the data is heading from a collaboration into an application. The maps operate within the ICS hub, not as part of the spoke connectivity, for reasons explained later in this article (see Figure 5).

More on Business Objects

Actually, a Sales Order typically consists of one of more Items, so there is also an Item GBO. Similarly, a Customer typically has an Address, and an Address typically has one or more PhoneNumbers. Each separate entity has its own business object definition. So, there is a Sale GBO, an Item GBO, a Customer GBO, an Address GBO, and a PhoneInfo GBO.

Whether or not an application entity is defined as its own BO is often a decision based on reuse. Consider, for example, a phone number. Why does a phone number need a separate business object definition as compared to simply using a String representation? Although all phone numbers in the U.S. are 10 digits in length, we often have the additional 3-, 4-, or 5-digit extensions, because phone numbers outside the U.S. frequently vary in length. Also, consider the different types of numbers we have, ranging from fax to home to office to cell. A PhoneInfo business object definition could define the type of phone number and allow it to be reused in many other business object definitions. Creating a separate business object definition allows for a list of values. The WebSphere BI Server can't handle an array of PhoneNumbers unless PhoneNumber is defined as its own Business Object. There's no limit on the depth of a business object definition hierarchy. Nesting BOs allow for the representation of complex application schemas and modularity of design.

Business Objects and Maps

The total number of maps needed for an integration effort depends on both the total number of applications involved and the total number of collaboration business logic modules.

WebSphere BI Server: Connectors

To be a spoke for the ICS, an application needs to be ICS-enabled. In other words, an application needs to be able to create ASBOs and send them into the ICS. The application also needs to be able to receive ASBOs from the ICS and take the appropriate action based on the verb. The component that connects an application to the ICS is called a Connector or an Adapter.

One task for a Connector is to determine when an application event (a change in its data) is something in which at least one of the collaborations is interested. It's the Connector's job to extract data from an application and insert data into an application. The Connector also connects the application to the ICS. Connectors can communicate with the ICS either through MQ (using the native MQ API or JMS) or IIOP.

As shown in Figure 6, the Connector is logically split into three parts:

• Connector Agent: the part that knows about the application (how to extract and insert data)
• Connector Controller: the part that knows about the ICS (specifically, about Maps and Collaborations)
• Connector Communication: the part in between, for communication between the previous two pieces: the Agent and the Controller

DATA FLOW
In this example, the desired integration business logic is Customer Synchronization from appA to appB. The prebuilt CustomerSync collaboration is used.

1. Connector Agent builds ASBO to represent Event
2. Connector Agent puts ASBO onto MQ
3. Connector Controller copies ASBO data from MQ and sends it to a Map
4. Map returns GBO to Connector Controller
5. Connector Controller calls appropriate Collaboration(s)
6. Collaborations perform business logic on GBO data
7. Business logic typically sends GBO to another application, a Connector Controller
8. Connector Controller sends the GBO to a Map
9. Map returns an ASBO to the Connector Controller
10. Connector Controller sends the ASBO to the Connector Agent (uses ORB for this)
11. Connector Agent performs the appropriate action based on ASBO

Updates to Data

Conducting an update on customer data is very similar to creating a new customer until the final step of updating the data in appB. appB needs to know which customer to update. Applications typically generate their own internal representation of a unique key for every entry into a database table. Thus, Jane Doe on appA will have a unique key that isn't relevant in appB. It's not sufficient to tell appB to update Jane Doe because appB might have many different customers named Jane Doe. It's also unacceptable to tell appB to update the customer based on the unique key stored in appA.

The theme of hub-and-spoke once again drives the design of the mechanism for storing the cross-referencing information. Because there are many more than the two applications appA and appB, their unique keys are not stored in a single table. Instead, each key is stored in a table along with a hub-key, or a generic-key. The basic idea is that you never cross-reference appA directly with appB, or appC, or any other app. You cross-reference appA with the hub. In other words, instruct the hub to represent an incoming ASBO not by an arbitrary GBO, but by a particular GBO, with a unique identifier. When that GBO needs to be converted into a different ASBO for another application, a similar look-up is performed, mapping the GBO's unique ID to the unique identifier for the ASBO for appB to which it corresponds (see Figure 8).

This clarifies an earlier claim about the mapping being done in the hub instead of in the spokes. The cross-referencing tables are stored in the repository instead of on the separate applications. Also, the cross-referencing is done as part of the mapping. So, the mapping must be handled in the hub.

Beyond the Firewall: Java to Application

A second option is to call a collaboration directly from another application, which would bypass many steps of the typical data flow outlined previously. A direct call to a collaboration would mean that there would be no Connector Controller, and therefore, no process in charge of calling a map to translate ASBOs to GBOs and GBOs to ASBOs. Given that the collaboration is expecting a GBO, there are two options:

1.  Pass a GBO directly to a collaboration. Because you're likely to be in control of the code for whatever application you're using to call a collaboration, generate data that matches the GBO definition required by the collaboration.

2.  Configure the collaboration so that it will call a map. This is the more consistent option of the two, allowing the collaboration to change the GBO data specification without affecting the call from the external application. The external application can pass ASBO data, knowing that an ASBO to GBO map will handle the specifics of preparing the data for the collaboration. Similarly, from the ICS back to the application, a GBO to ASBO map is used.

Note that the code that calls the collaboration could be a Java Servlet or an EJB. This allows Java applications, such as those running in an application server, like WebSphere Application Server, to integrate very closely with collaborations in ICS. The API used for accessing a collaboration directly is called the Access Framework. This mechanism uses IIOP to communicate with the server and is a tighter (synchronous) style of interaction with the server than connecting an application with ICS using the MQ Adapter and JMS.

Because the ICS server can act as a general gateway to all the non-Java legacy applications in a given enterprise's environment, using the Access Framework to call collaborations in the ICS is a good way to integrate a J2EE application with any number of legacy back-end systems. Each such call would be the same - amounting to sending a BO to the ICS server. As a result, the Java code in the J2EE application wouldn't have to implement different mechanisms for connecting to, say, SAP, PeopleSoft or a CICS application. In each case, it would use the Access Framework as a generic RPC mechanism, and let the ICS and its associated Connectors handle all of the details regarding which back-end systems to connect to and how.

Beyond the Firewall: Trading Partner Data to Application

Using WebSphere BI Connect, a company can easily manage and securely communicate with hundreds of trading partners. Using both WebSphere BI Connect and WebSphere BI Server, the data flowing to and from trading partners can also flow through collaborations. If a company's business processes are already being implemented by collaborations running in the ICS, the mechanism is in place and ready to handle external data as well.

WebSphere BI Connect is designed to handle receiving and sending EDI, XML, and various documents and secure transmission with digital certificates, encryption, and decryption. However, WebSphere BI Connect doesn't process the content; it's the job of WebSphere BI Server to process the content from a variety of sources and in a variety of formats.

Exposing Collaborations as Web Services

Conclusion