Introduction

In the series of articles "Integrating business processes to streamline the supply chain: Item synchronization with global repositories," you learned how a product supplier can use business integration technology to synchronize product data with an external exchange directory. But how can a consumer most effectively tap into a range of options and dynamically select the services that best suit their current needs? Consider this scenario: You've decided to focus on the core business needs of your fast-food empire. To do this, you need to outsource the travel service portion of your business to a company that specializes in this field. How can you get the customized service you need without paying a small fortune for a company to code a solution from scratch, just for you?

This article gives an overview of a mediated exchange scenario in which an online travel agency negotiates services between travel industry service providers (airlines, car rental agencies, and so on) and corporate service consumers who have outsourced their travel needs to the online travel agency. You'll find out about the broad on demand features of this scenario, including a generic solution architecture that can apply to multiple industries. And you'll learn how IBM® software can help transform your organization to become an On Demand Business.

Follow-on articles in this series explore the solution components in more detail. The articles will demonstrate how aspects of this broad solution can be built using current products and technologies. This series is particularly relevant to IT architects who are evaluating how to move to an on demand solution.

Back to top

Participate in a mediated exchange

The business environment remains competitive, and companies are looking at how they can focus more on their core business proposition. Outsourcing common business services -- such as booking travel arrangements and ordering office supplies -- rather than creating and maintaining separate IT infrastructures saves time and money. However, as a consumer of these services, you want to make sure the travel solution you outsource can be easily and affordably customized to suit your specific company needs and that you aren't left with an off-the-shelf solution that inhibits the way you do business.

The mediated exchange scenario in Figures 1A and 1B show the relationship between three kinds of business entities: service consumers, mediators, and service providers. Burgers Inc., our fictional fast-food chain, is the corporate service consumer that has decided it's in the burger business, not the travel business. As a result, the company has outsourced the handling of travel reservations to a separate mediator. FriendlyDestinations.com, the mediator, is an online booking service that brokers travel services for many service consumers to specific service providers, such as hotel chains and airlines. These service providers will readily make their services available through a mediator in an effort to expand market share.

To give service consumers an extensible and customizable solution, FriendlyDestinations.com provides self-service facilities that allow them to self-manage business rules that govern the behavior of the travel application. The FriendlyDestinations.com travel application needs to support such customizations as:

• Restrict hotel bookings to a short list of preferred hotel chains.
• Always look for the lowest airline quote.
• Require that all approvals be in place before finalizing a reservation where the cost is over $5000 and the employee is not an executive.

Before discussing the solution architecture, consider what our traveler -- a Burgers Inc. employee -- sees when they book travel with the outsourced travel application. The employee logs on to his company travel portal. What he sees in the application interface is determined by the company-specific customizations provided by the Burgers Inc. business analyst. The travel portal displays as a Burgers Inc. site, although it is actually a customized version of a generic travel solution provided by FriendlyDestinations.com.

The same business model also applies to the retail industry. Figure 1B shows the same relationship of business entities: customers outsource their office supply requisitioning to ClipsAndTacks.com, who interacts with a number of providers for sticky notes, paper clips, filing cabinets, and so on.

By collaborating on cross-enterprise processes and by using technologies that enable dynamic customization, businesses (service consumers, mediators, and service providers) can reduce their total cost of ownership.

Back to top

Integrate across the value chain

In Figure 2 you can see a logical overview of the mediated exchange solution. Burgers Inc., our service consumer organization, can integrate with FriendlyDestinations.com, our mediator organization, using two types of channels:

• Human-interactive channel, which exposes the user interface of the travel application to Burgers Inc. travelers
• Process-process communication channel, which integrates processes running on the two sites

The user interface exposed by the mediator is typically a Web-based UI accessible by the traveler with a Web browser. The non-interactive, process-to-process channel of communication is implemented using a variety of technologies, ranging from Electronic Data Interchange (EDI)-based communication to Simple Object Access Protocol (SOAP) Web services to custom XML and HTTP-based protocols designed to get processes running on two different sites talking to each other.

The FriendlyDestinations.com (mediator) site connects Burgers Inc. (service consumer) to many service providers. Service providers can be subdivided into three types: airlines, car rental companies, and hotel properties. The mediator interacts with the service provider sites using a non-interactive, process-to-process channel identical to that used to integrate service consumers.

The FriendlyDestinations.com site provides a flexible infrastructure that allows for rapid integration with service consumers and service providers. Systems belonging to these different organizations can be thought of as end-point destinations on a single, cross-enterprise bus. The site will also contain a:

• Web portal that serves up the UI contribution for the hosted travel application
• Process engine that executes key portions of business logic
• Rules engine to enforce business rules specific to a specific service consumer
• Gateway used to integrate with external partners

To enable this solution, service consumers, service providers, and mediator organizations have to collaborate and address several key integration challenges:

• Implement and deploy adapters, to allow systems located in different enterprises to communicate.
• Build flexibility into applications hosted by the mediator, to allow for rapid customization to respond to service consumer demands.
• Construct a scalable, cross-enterprise security infrastructure that addresses privacy and identity-management concerns for service consumers, service providers, and mediators.
• Enable high availability and scalability for the solution.

In the following sections, you'll get an in-depth look at the architectures and technical constraints found in the service consumer, service provider, and mediator sectors. And you'll learn how these organizations are affected by the aforementioned challenges.

Integrate a third-party travel application

Burgers, Inc. is a fairly large traditional enterprise with a considerable investment in legacy systems that support key business operations. The legacy systems can include business transactions running on IBM CICS® and IBM IMS™ systems, enterprise resource planning (ERP) systems, earlier versions of messaging middleware, relational databases, and other systems.

The company operates an intranet Web portal for use by their employees. Burgers Inc. wants to integrate the travel application developed by FriendlyDestinations.com into their intranet portal. Employees could then use their Web browsers to book business-related travel through their own employee portal.

Burgers Inc. has its own security infrastructure to authenticate employees and perform authorization checks. When Burgers Inc. integrates the travel application from FriendlyDestinations.com, it is vital that critical information, such as employee intranet passwords, remain private. At the same time, Burgers Inc. employees should not have to sign on more than once when working with various applications available through their company's employee portal, including the travel application provided by FriendlyDestinations.com.

Burgers Inc. also has its own policies for corporate travel. For example, the company may have negotiated special discount agreements with certain service providers and needs to be sure that employees always book their trip with those providers. The company wants to be able to configure rules that govern when a particular trip requires approval. Travel approvers working for Burgers Inc. should be notified by e-mail whenever there is a travel request requiring their approval.

In addition, Burgers Inc. needs to be able to customize the travel application developed by FriendlyDestinations.com to suit its business needs. They want to be able to change travel rules quickly and easily, without intervention from the FriendlyDestinations.com IT staff.

Expose transactions to external partners

Fast Air Inc., an example of a service provider, is an airline that provides flight information and reservation services to FriendlyDestinations.com. A key issue for this company is figuring out how to expose transactions running on legacy systems to FriendlyDestinations.com. Fast Air Inc. architecture includes enterprise information systems (EIS) running business transactions that are critical to its line of business. The company has its own security domain and makes use of gateway technology to control access to its services.

Develop customizable on demand applications

A high-level architecture of FriendlyDestinations.com is shown in Figure 3.

The FriendlyDestinations.com site implementation is based around five key components:

• The portal
• Enterprise Service Bus (ESB)
• Process engine and rules engines
• Gateway
• Security and identity services

The ESB acts as the service-oriented architecture (SOA) infrastructure for the mediator site that provides messaging and allows for the integration of new service providers without system downtime. The ESB also lets you vary the physical architecture of the site without changing the software implementation.

The portal component provides on-the-glass integration capabilities. It provides portlets that support the primary use cases described in the high-level design document. The portal is available to other services integrated using the ESB through the travel UI service.

The process engine executes business processes that implement the business logic behind the travel application. The main travel process dispatches events raised by the travel UI service (the user interface tier) to subprocesses designed to perform specific actions -- searching, reserving, confirming, canceling, and soliciting approval for trips. The process engine interfaces with the rules engine to implement customizable application behavior.

The security service performs vital authentication and authorization decisions, while the identity service provides key information about the traveler who initiated the trip transaction. The following sections review the customization and security aspects in greater detail.

Back to top

Create a customizable solution

Travel specialists from FriendlyDestinations.com create templates for corporate travel rules. FriendlyDestinations.com provides a Web-based UI that service consumers can use to create their own travel rules based on these templates. Figure 4 shows this arrangement.

Figure 5 shows how a typical travel policy can be structured. Service consumers can manage their travelers on a group-by-group basis. Each service consumer can use a self-service facility provided by the mediator to first define their user groups, then apply rules that govern travel to each group.

The travel policy offering provided by FriendlyDestinations.com defines several different types of business rules, including:

Reservations rules

Determine reservation choices that can be made by the traveler. (For example, choices that allow travelers to book business-class seats on a flight or let them rent a car)

Preferred provider rules

Promote those service providers with which the corporate service consumer has pricing agreements. (The company may want to require that travelers book reservations with those service providers whenever possible.)

Out-of-policy rules

Determine how to handle situations when application of booking and provider rules do not produce desirable results. (For example, if no other fare is available, the corporate service consumer may allow their travelers to book business-class seats.)

Approval rules

Determine whether or not a particular trip requires approval by the travel approver.

Billing rules

Determine the discount that should be applied when booking reservations based on negotiated agreements, if these exist.

Figure 5 uses pseudo-code to show examples of the different rules types. All rule types can be applied to each user group defined by the service consumer. If some of the rules are not defined for a child group, then the corresponding rule defined for the parent group is applied. For example, the Executives group does not have booking rules associated with it, so rules from the parent category Managers are applied. Conversely, if a child group defines a rule that is also present in the parent group, the rule associated with the child group is used.

Secure the solution

Corporate service consumers such as Burgers Inc. need to synchronize their user information with the mediator. For example, when a new employee starts work at Burgers Inc. and receives authorization to book business trips, this user needs to be recognized by FriendlyDestinations.com as a traveler. Ideally, this should happen with minimal manual configuration steps required on behalf of the new employee. Conversely, when the employee leaves Burgers Inc. or permission for that person to book business trips is revoked, this user should no longer be able to book trips with FriendlyDestinations.com -- at least, not with the business-to-business (B2B) interface, using the Burgers Inc.-affiliated identity.

When a user of Burgers Inc. is granted permission to approve business trips by Burgers Inc., this user must be granted access to the approval interface and the approval process running on FriendlyDestinations.com. Conversely, if permission is revoked by Burgers Inc., FriendlyDestinations.com should not allow this user to approve trip requests.

Similar permissions have to be supported when controlling access to the travel policy. The mediator (FriendlyDestinations.com) must perform authorization checks during any access to the travel policy, and ensure that only appropriate Burgers Inc. users are allowed to change the travel policy. All access to travel policy interface has to be logged. A business analyst from Burgers Inc. should not be able to view or change the travel policy that applies to a different service consumer.

One of the key aspects of this solution is that its behavior is customized based on the identity invoking the application. Identity information has to be propagated all the way through the solution, from the service consumer to the service providers.

The mediator has to share certain aspects of identity information with the service providers. For example, airline service providers require the name and passport information of the traveler. The mediator can include this directly, as part of the SOAP request message, or indirectly, when establishing a secure communication channel. Because different providers can have different interfaces for their services, the latter approach is probably preferable. Also, travelers may want to log on to the service provider sites directly to, for example, check for any last-minute changes to flight information.

The service consumer (Burgers Inc.) will maintain key identity information for their travelers, travel approvers, and service consumer business analysts. This identity information includes the full employee name, business address, home address, employee number, level of seniority in the organization, current position, and so on. However, the service consumer will want to expose only the subset of information relevant to booking business travel to the mediator.

The FriendlyDestinations.com site will store additional travel preferences indicating preferred flight seat location, whether the traveler is a smoker or not, whether the traveler prefers vegetarian or kosher meals, and so on. The mediator defines the key security roles that all service consumer employees will map to -- traveler, travel approver, service consumer business analyst. The mediator site will also store traveler group definitions created by the service consumer business analyst using a self-service facility.

Back to top

Build the solution in stages

To enable the mediated exchange solution, FriendlyDestinations.com will need to collaborate with corporate service consumers and service providers to complete the following stages:

1. Develop customizable business processes and travel policy templates that can be exposed to service providers as value-added service.
2. Implement a flexible and dynamic SOA infrastructure that allows for rapid integration of service provider services.
3. Implement a metering capability that can be used as a basis for a pay-as-you-go billing model.
4. Develop and expose a Web-based UI that lets service consumers readily integrate the travel application into their employee intranet.
5. Enable a flexible security infrastructure that allows for seamless and secure communication across the value chain, enforces privacy concerns, and minimizes identity-management expenses for all parties.

Follow-on articles in this series will help you systematically implement the mediated exchange solution one step at a time. And you'll learn the implementation strategies and tips behind each of the previously mentioned stages.

Map solution architecture to IBM products

This series describes how the mediator architecture is designed, implemented, and managed using currently available products. This section introduces you to the product set by discussing each of the components in the generic architecture just described and specifying which IBM products are used to build that component in our implementation.

Table 1. Mapping logical architecture components to IBM products

>

Process engine
The Business Process Execution Language for Web Services (BPEL4WS or BPEL for short) is the current industry standard for describing sophisticated business processes. BPEL replaces and improves on earlier vendor-specific languages for describing business processes, such as IBM FDML and Microsoft's XLANG. WebSphere Business Integration Server Foundation Version 5.1 contains a BPEL-compliant process engine and, therefore, is the obvious choice for the process engine runtime component.

Rules engine
The ability to externalize business rules and change their associated values during runtime is provided by WebSphere Business Integration Server Foundation Version 5.1 in the form of the business-rule beans component included in that release.

Gateway
The gateway component is used to proxy both incoming Web services requests from service consumers and outgoing Web services requests to service providers. This is constructed using the Web Services Gateway component of the WebSphere Application Server Network Deployment 5.1. The Web Services Gateway provides several capabilities needed by the mediator, including protocol transformation, message filtering, and security integration.

Design tools
Two products meet our design and development tooling needs. WebSphere Business Integration Modeler Version 5.1 provides the tools to design and test complex business processes, and to communicate these designs to application developers. WebSphere Studio Application Developer Integration Edition Version 5.1 provides the tools necessary to develop, package, and unit-test BPEL business processes suitable for deployment on the WebSphere Business Integration Server Foundation Version 5.1 runtime.

Service registry
The service registry component is implemented using the WebSphere Application Server Network Deployment 5.1, which provides a Universal Description, Discovery, and Integration (UDDI) service registry that complies with version 2.0 of the UDDI standard.

Transform service
The Web Services Gateway component of WebSphere Application Server Network Deployment 5.1 provides the ability to integrate Java™ API for XML (JAX)-Remote Procedure Call (RPC) handlers, which can interact with messages as they pass through the gateway to perform the necessary transformations. WebSphere Studio Application Developer Integration Edition Version 5.1 tooling provides the capability to easily create a transformer service and allows various complex message transformations to be designed using a drag-and-drop editor.

TripInfo service
The TripInfo service will be developed as a custom Java 2 Platform, Enterprise Edition (J2EE) application and deployed to the WebSphere Business Integration Server Foundation Version 5.1 runtime.

Traveler UI
WebSphere Portal server Version 5.0.2.2 supports the Web Services for Remote Portlets (WSRP) capability and can act as a WSRP producer to serve portlets to WSRP-compliant consumers.

Firewall
IBM SecureWay Firewall Version 4.1 provides the firewall functions needed by the mediator.

Metering service
The metering service will be developed as a custom J2EE application and deployed to the WebSphere Business Integration Server Foundation Version 5.1 runtime.

Service bus
The service bus is composed of several elements, each of which contributes to providing service bus capabilities to the mediator infrastructure and includes WebSphere MQ Version 5.3 and WebSphere Business Integration Server Foundation Version 5.1. (You'll learn more about the architectural considerations of the service bus in an upcoming article.)

Security/identity service
Tivoli Access Manager for e-business Version 5.1 can be integrated with the other mediator infrastructure components to provide a centralized security service that meets the mediator's security requirements.

Back to top

Next steps

We've described a 5-stage roadmap for enabling the mediated exchange solution in this article. Throughout this series, you'll learn each stage in detail, with corresponding articles describing how the capabilities required in each of these steps are designed, implemented, and deployed. Stay tuned!

Resources

• Check out Developer resources for on demand world to learn about IBM's conceptual methodology for delivering software solutions based on the On Demand Business concept.
  
  
• Learn more about on demand computing by reading e-business on demand: A developer's roadmap (developerWorks, February 2003).
  
  
• Browse the series of articles Integrating business processes to streamline the supply chain: Item synchronization with global repositories that focuses on business integration.
  
  
• Learn more about service-oriented architecture and Web services from the IBM Redbook Patterns: Service-Oriented Architecture and Web Services.
  
  
• Download and view a business integration demo.
  
  
• Visit the WebSphere Business Integration zone on developerWorks WebSphere for information about WebSphere Business Integration products.
  
  
• Find out more about how IBM software, hardware, services, and expertise can help your organization become an On Demand Business.
  
  
• Get an overview of WebSphere Business Integration Server Foundation.
  
  
• Browse for books on these and other technical topics.
  
  
• For information about the compatibility and integration of the products used and tested by the IBM Software Group System House Solution Test Team in the "Designing and implementing a mediated exchange" solution, see the "Mediated exchange scenario" section in Integrating IBM middleware to develop business solutions (developerWorks, February 2005).
  
  
• Innovate your business with the latest technology from IBM. Get trial downloads of IBM products now.
  
  

About the authors

Mikhail Genkin is a Scenario Designer working with IBM Software Group System House in Toronto, Canada. He helps IBM development teams design products for business integration. He has contributed to several releases of IBM VisualAge® for Java Enterprise Edition, WebSphere Application Server Enterprise Edition, and WebSphere Application Developer Integration Edition. You can contact Mikhail at genkin@ca.ibm.com.

Luc Chamberland is Program Manager of IBM Software Group System House Business Scenarios. He works with various IBM teams to understand how customers use WebSphere products together and assists product groups to leverage cross-product scenarios to address integration challenges. He has written and presented on Java tools, XML, and open-source technology. You can contact Luc at lchamber@ca.ibm.com.

David Leigh is an Solution Test Architect in IBM Software Group System House in Research Triangle Park, North Carolina. His areas of expertise include the process choreographer, application and server security, high availability, monitoring, IBM AIX® systems, and the Linux™ operating system. You can contact David at dleigh@us.ibm.com.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Participate in a mediated exchange
• Integrate across the value chain
• Create a customizable solution
• Build the solution in stages
• Next steps
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality