Portals

Digg This!

In part one (Vol.3, issue 7) of this two-part article, we discussed the "on demand" information delivery architecture based on portal technologies and WSRP. In this part, the concept of on demand will be extended beyond the information delivery layer to the information aggregation and integration layer. We'll introduce the Enterprise Information Bus (EIB) and discuss its role in building service-on-demand portals.

Emergence of Information Aggregation

Portals are never implemented as stand-alone infrastructures; they have to integrate with the larger enterprise ecosystem. Portals are the face of this ecosystem. They need to integrate with various information applications across the enterprise. Information applications include, but are not restricted to, various back-end information systems, and modern applications that are specialized applications for a specific product or process. Portals have to integrate with them to provide summarized and detailed views into these applications. Though modern applications are built on standards-based technology, back-end applications have evolved over time and are built on heterogeneous platforms. Gathering information from these disparate applications poses a major integration challenge. Without a loosely coupled, low-cost, integration infrastructure, a portal project turns into an enterprise integration project rather than an information delivery project. Portal products, as a technology, are not designed to take on this enterprise integration challenge completely.

The key to a service-on-demand enterprise is to build an infrastructure and architecture that demonstrates loose coupling and flexibility. The service-on-demand enterprise architecture should also provide a layer of abstraction between the various heterogeneous system interfaces provided by the back-end legacy applications, the business applications that consume the information, and the different business entities. A myriad of business entities and information objects from assorted information sources are required by most of the business and middleware applications.

Key to a customer-centric or business process-centric application development capability is the ability to access business entities and information from various back end-systems. The challenges an enterprise faces in accessing business entities is knowing the:

• Authoritative sources of information
• Location of these authoritative sources of information
• Access mechanisms to these sources
• Ability to collate information from them in a consistent manner

For example, in a large-scale manufacturing industry, various applications, such as a contact center application, sales force application, and customer relationship management system, depend heavily on the right business entities and information for making decisions and supporting business transactions. This information is conventionally gathered by accessing various APIs offered by legacy applications, databases, and heterogeneous systems, and applying a variety of transformations to finally extract a meaningful information entity.

Currently, in most enterprise architectures the burden of identifying the right source of information, the ability to access it and associated mechanisms, and understanding the semantics of information entities lies heavily on the consuming applications. So in a sense these applications are logically tightly coupled with the back-end information sources and require a great deal of knowledge to access and use them.

Emergence of various information aggregation and collation technologies have attempted to solve this problem, and have gone to the extent of providing Enterprise Service Bus (ESB) where all the back-end system integration is abstracted and information is available as a set of services for applications to consume. This still leaves the problem of identifying the right source(s) for business components, its schema and the ability to access the business component as entity versus service interface is still unresolved.

Below we briefly discuss the integration technology evolution followed by an introduction to the Enterprise Information Bus.

Portal Integration Evolution

Back-end application integration into the portal has evolved over time. Listed below are some popular integration styles used in the past (see Figure 1):

• Point-to-Point integration
• Message bus
• Enterprise Application Integration (EAI)
• Enterprise Service Bus (ESB)

Note: This article assumes that you are familiar with the basic concepts of the above integration styles and does not attempt to elaborate on them.

Point-to-Point Integration

In this integration style, the portal directly integrates with one or more back-end applications. The portal leverages the application server and a variety of integration standards supported by the platform. For example, a portal based on a J2EE platform could leverage integration technologies such as JCA, JMS, Web services, and HTTP over XML among others. With this integration style, the integration tier is mixed with the presentation tier (information delivery tier) and cannot be leveraged for enterprise use.

Message Bus Integration

Message Oriented Middleware (MOM) involves passing messages (in any format - XML is now becoming popular) between two applications, usually in an asynchronous fashion. MOM can be implemented as point-to-point, or as a hub-and-spoke solution. This integration style provides distributed integration technology with separation of the information delivery and integration tier (e.g., MQSeries, MSMQ). MOM allows reuse of message formats and centralized message routing and processing, but the presentation tier is largely duplicated within consuming applications. Each client application is tied to a queue and is aware of the services that are offered.

EAI Integration

Integration brokers provide another class of integration technology known as EAI. In addition to MOM, they provide adapter (though proprietary) based integration to various back-end systems. They also allow business process definition and execution separate from the integration logic. EAI implementations follow a hub-and-spoke model, which requires multiple portal applications to go through a single EAI hub. This model does not work well with cross-organizational boundaries.

ESB Integration

Enterprise service buses (ESBs) are the latest generation of middleware, and combine features from several types of middleware discussed above. Many ESBs currently support Web services protocols such as Simple Object Access Protocol (SOAP) and use Web Services Description Language (WSDL) and Universal Description, Discovery, and Integration (UDDI). In addition, some multiprotocol ESBs allow applications to communicate using a variety of protocol standards such as Web services, JCA, JMS, HTTP/XML, TCP, and messaging (MQSeries, MSMQ, etc.). It can also support custom APIs (Java/J2EE, COM, etc.). It has the advantage of being highly distributed and can cross organizational boundaries. With this integration style, the portal needs to know only one interface to communicate with the ESB.

Enterprise Information Bus (EIB)

The Enterprise Information Bus (EIB) is an architectural topology that integrates all the back-end information sources and systems seamlessly and provides business and information entities to applications, consuming them through various loosely coupled protocols.

EIB provides the following capabilities above the conventional managed data bus:

• Business registry: This component makes the information registry available for the consuming application to look into. Typically in large enterprises, identifying which business components exist within the organization and its semantics is essential. This becomes far more important in a geographically distributed enterprise. For example, in a financial organization it is important to know where and how entities such as customer, account, credit, and check information can be available. Similarly, in a manufacturing enterprise, order, account, part index, and customer information are key.
• Location management: The location of information constantly changes as various back-end systems change. For example, in a manufacturing organization the shipment management system can be the source of authority for order information and can potentially move toward the order booking system to be the source of authority due to changes in the supply chain model, or systems upgrade model. Many of the problems in an enterprise stem from the fact that consuming business applications tend to construct business entities from wrong sources of information. For consistent and reliable access, entity definitions and locations should be centralized and handled at the EIB level rather than each application having the knowledge of the information source.
• Meta model: Meta models orchestrate and define meta entities, which need to be constructed from other business entities. For example, construction of relationship entity from account, customer, and order entities is very common in customer relationship management applications.

These features and capabilities, apart from the management, routing, security, and adapter features of a regular service/message bus, are important to make information access more business entity-centric rather than interface-centric. Entitlement can be associated with each business entity based on the roles of consuming applications.

WSRP and EIB - A Great Combination

In the first article, we saw the capabilities of WSRP and its relevance to federated portals. WSRP provides the information and rendering as an extension to a conventional SOAP stack. It facilitates federation and loose coupling capability at the information delivery layer through portals.

To extend the power of federation, on demand services, and loose coupling beyond the information delivery layer to the integration layer, EIB needs to be harnessed along with the WSRP infrastructure.

EIB and WSRP are a great combination in terms of providing information aggregation, federated information access, loose coupling, and business entity-level access. A WSRP-enabled EIB can provide an on-demand portal architecture.

The EIB can plug in applications on the bus using WSRP in addition to a variety of protocols available with the enterprise bus. On the other side, a WSRP wrapper layer that leverages the EIB can allow organizations to construct presentation information once to be used everywhere.

Figure 2 represents an enterprise-scale design pattern for implementing a completely cohesive, loosely coupled, and business entity-driven service on-demand information gathering and distribution architecture.

Conclusion

These are the key concepts discussed in this series:

• WSRP is a promising, emerging technology that will benefit large organizations to draw their portal strategy.
• Federated portal architecture allows organizations to reuse existing assets, common enterprise view, and autonomy at the same time.
• While portal servers are the face of the enterprise ecosystem, the EIB serves as the glue that joins various other components (information applications).
• EIBs are the integration infrastructure to aggregate, define, and deliver information across the organization in a location-independent way