Introduction

In my third paper in a series on Service-Level Agreements (SLA) ("Use SLAs in a Web services context," see Resources), I talked about how Web services can supplement Enterprise Application Integration (EAI) applications as a way of overcoming EAI limitations. In this paper, I go a little further with a discussion about the scenarios for closing enterprise system gaps with SOAs by showing you how to execute the business logic of Web services to get the proprietary EAI applications to talk to one another. I show you how you can reuse Web services -- data-centric and business logic - from one or more SOAs and combine them into a composite application.

Back to top

EAI gaps

I focus on three major limitations of the EAI approach: proprietary, limited integration, and lack of open industry standards. All create communication gaps between companies' EAI applications, such as the following:

• Customer relationship management (CRM)
• Investor relationship management (IRM)
• Supply-chain management (SCM)
• Enterprise resource planning (ERP)

The proprietary nature of EAI applications is limited by the type of business processes a company applies to EAI applications and by the type of business the company runs. The EAI approach limits the scope of efforts to integrate EAI systems with external applications. It would be costly and time-consuming to customize schemes for mapping business logic between EAI systems and external applications.

Standards for implementing EAI are virtually non-existent. Without the standards, it is difficult to integrate multi-vendor EAI applications over the Internet. Unlike EAI, Web services offer a wide range of standards to bridge applications with external service providers. While EAI is more secure than Web services, IT industries are collaborating to create or improve existing standards (WS-Security) to provide Web services with better security mechanisms.

Back to top

Close the gaps

Middleware technologies in various forms have been used to close EAI gaps. Web services are the best middleware choice for getting EAI applications to communicate with one another. They offer open industry standards to bridge the platform-dependent EAI systems. Some supplement EAI applications to assume the role of a provider or consumer of open industry business processes that EAI applications could not assume in closed environments.

In reality, not all Web services are available in a single SOA. You can combine Web services with base functions to form a composite Web service application. In turn, you can combine these applications with other Web services or composite business in other SOAs to create new or higher-level business services. What this means is that you could use multiple SOAs to bridge the gaps between EAI applications or systems.

Back to top

Orchestrate Web services

In SOA, it takes a series of business processes of high-level business services to orchestrate the execution of multiple Web services. Data-centric Web services rarely execute themselves. The goal of orchestration is to get Web services to close off EAI gaps so that proprietary EAI applications can speak to one another through an integration hub.

In an orchestra, you can expand or contract the scope and nature of the orchestra by reusing codes to change the logic of business processes for a composite application. Base functions presented by individual Web services in a SOA can be reused and combined into a composite application of high-level services to create new business services which, in turn, can be reused and combined into a higher-level composite application of business services in another SOA.

Back to top

Avoid pitfalls

I consider four pitfalls you should avoid when developing or combining Web services into composite applications:

1. Simple Object Access Protocol (SOAP) overhead
2. SOAP interoperability issues
3. Tightly-coupled business services
4. Transaction-heavy environments.

It is not always practical to create Web services everywhere and combine them into an all-Web services application even though Web services are based on a growing list of open industry standards that EAI applications lack. Enterprises could create too much SOAP overhead when processing Web services, thus slowing down the tasks of completing business processes.

Enterprises might also run into the problem with SOAP interoperability between Web services. Although much work has been done to increase SOAP interoperability, SOAP is not yet fully interoperable industry-wide.

Some proprietary EAI applications can perform certain business functions well in a tightly-coupled environment that Web services in a composite application cannot perform well in a loosely-coupled environment. One example of a tightly-coupled business service is a customer swiping a debit card into a card reader, accepting a debit amount, specifying the amount of cash back, and receiving confirmation for automatic debit from his account.

You might find problems integrating some Web services that complete business processes in a short time with other Web services that involve long-running applications based on a complex set of business rules. Web services are well-suited for applications that run in a short time, not for transaction-heavy environments that take a long time to complete business processes.

Back to top

Single SOA scenario

Let's now take a look at how you can combine Web services with base functions to form a composite Web services application, assuming loading performance is at a satisfactory level. Consider the following Web services, each coming from a fully interoperable system:

• Retailer ID
• Retailer Name
• Retailer Address
• Order Quantity
• Pricing
• Tax

As shown in Figure 1, the first four Web services contain only the data base functions, while the last two primarily use business logic to achieve the goal of sending a bill to the intended retailer. I combine all into a composite billing function application that is, in turn, processed in an accounting application.

I start the process with a Retailer ID Web service sending a request to a Retailer Name Web service to match up the name with the retailer id. Upon confirming the discovery of the information, the Retailer Name Web service is combined with a Retailer Address Web Service, an Order Quantity Web Service, a Pricing Web Service, and a Tax Web Service to create a composite application on retailer billing function. This composite application is then processed in an accounting application based on the business logic of the services.

Back to top

Multiple SOA scenario

Let's suppose a small company lacks an internal Tax Service department. It has outsourced tax services to a business that updates, maintains, and manages the Outsourced Tax Web service. For the company, I combine the first five Web services from the first scenario into a composite application with a billing function while assuming performance of the loading process has been satisfactory.

Let's assume a Web service sends a request to combine the outsourced Web service in the second SOA with the composite application in the first SOA. When the request is accepted and implemented, the resulting higher-level composite application is processed in an accounting application based on the business logic of the pricing and tax services. As shown in Figure 2, the second SOA overlaps the first SOA, as the overlapped area could contain Web services and non-Web services common to both SOAs.

Back to top

Single SOA calling EAI applications

Web services focusing on relationship, chain management, and resource planning have different sets of integration rules (or virtual integration hubs), although they are capable of collaborating with each other on integration and aggregation of applications between enterprises. In contrast, the components of an EAI system communicate with one another through an integration hub of middleware technologies to get EAI applications to talk to legacy systems, databases, Web services, and non-Web services.

Let's consider SOA as the major middleware technology in bridging the business functions of multiple EAI applications both within and outside the firewall. To avoid SOAP overhead, limit the number of Web services. Also, avoid slow loading of the EAI applications that the Web services call.

In the scenario where the single SOA calls multiple EAI applications, the Retail ID Web service first calls the Retail Management System (see Figure 3). After a successful loading of the called application, the Web service sends a request to link an ID with a name and address.

The EAI application then searches the requested items in a database. When it finds the name and address, it sends the information to the SOA for inclusion in the composite application of Order Quantity and Pricing Web Services. Meanwhile, the Retail Management System is unloaded to make room for other EAI applications to be called later on.

Next, the resulting composite application calls the Finance Management System that maintains a database of Tax Service process rules. After a successful loading of this EAI application, the order quantity and pricing application connects to it. A higher-level composite billing function is formed. Meanwhile the Finance Management System is unloaded.

Back to top

Multiple SOAs calling EAI applications

Now, let's suppose two SOAs are needed to bridge two EAI applications. In this scenario, I combine the Order Quantity and Order Description Web Services into a composite application in the first SOA. I repeat the process in the third scenario of having the Retail ID Web service to call, load, and send a search request to the Retail Management System (see Figure 4). After a successful search, this EAI application sends the information to the SOA for inclusion in the composite application. Meanwhile, the Retail Management System is unloaded.

Next, the composite application calls and sends a request to the Order Management System to search the Pricing Policies database. After a successful search, the Order Management System connects itself with the Tax Web service in the second SOA. The Tax Web service is then incorporated into the composite billing function in the first SOA. All processes of loading and unloading have been successful with no SOAP overhead problems.

Back to top

How many SOAs?

The number of SOAs you can use to link up with EAI applications depends on the trade-offs among the complexity of the project, interoperability issues, business processes, and loading performance issues. Like you avoid SOAP overhead, you need to ensure that SOA overload will not occur during the entire life cycle of development. You should test for the overload at each point of the cycle.

Back to top

Conclusion

Closing enterprise system gaps with SOAs requires planning ahead of time to set the limit for how many SOAs can be developed. You should communicate with a team of business analysts and IT specialists on various performance issues. You will find that closing EAI gaps with SOAs will make your job of developing applications much easier. You can combine the business logic of Web services from one or more SOAs into one or more composite applications. The analysts will find that closing the gaps will make their job of designing and analyzing a system of SOAs much easier. They can determine what Web services can be combined for optimal performance without incurring SOAP overload.

Resources

• Get information on how to work with Web services in enterprise-wide SOAs from the following papers in a series:
  • "Maximize external Web services interoperability"(developerWorks, February 2005)
  • "Consolidate your SOAs as a three-dimensional integration hub to improve speed and reliability"(developerWorks, March 2005)
  
  
  
• How does Web services compare with JCA and JMS? Read "Choosing among JCA, JMS, and Web services for EAI" to get some answers.
  
  
• Want to know how to better manage your SOA projects? Read "Improve your SOA project plans" to find out more
  
  
• Get information on how to use SLAs in a Web services context from the papers in the following series:
  • "Part 1: Guarantee your Web service with a SLA" (developerWorks, April 2002)
  • "Part 2: Guarantee second-generation Web services applications with a SLA" (developerWorks, August 2004)
  • "Part 3: Integrate Web services into EAI with a SLA guarantee" (developerWorks, October 2004)
  • "Part 4: Secure multiple Web services with a SLA guarantee" (developerWorks, November 2004)
  • "Part 5: Firewall Web services with a SLA guarantee" (developerWorks, December 2004)
  • "Part 6: Localize Web services with a SLA guarantee" (developerWorks, January 2005)
  • "Part 7: Mitigate risk for vulnerability with a SLA guarantee" (developerWorks, January 2005)
  
  
  
• Read Judith M. Myerson's The Complete Book of Middleware , which focuses on the essential principles and priorities of system design and emphasizes the new requirements brought forward by the rise of e-commerce and distributed integrated systems.
  
  
• Get the business insight and the technical know-how to ensure successful systems integration by reading Enterprise Systems Integration, Second Edition .
  
  
• Browse for books on these and other technical topics.
  
  
• Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• EAI gaps
• Close the gaps
• Orchestrate Web services
• Avoid pitfalls
• Single SOA scenario
• Multiple SOA scenario
• Single SOA calling EAI applications
• Multiple SOAs calling EAI applications
• How many SOAs?
• Conclusion
• Resources
• About the author
• 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

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers