Introduction

In my second paper in the series on enterprise-wide SOAs, "Maximize external Web services interoperability," I gave instances of service interoperability without incurring multiple SOA overloads -- from simple protocol co-existence to complex interoperability of multi-platforms. I talked about how you can use Visual Studio .Net to develop Web services on the Microsoft® .Net platform and run them on IBM® WebSphere® Application Server.

In this paper, I talk about how you can consolidate multiple SOAs of Web services and non-Web services as one three-dimensional integration hub to connect to various back-end enterprise mainframe systems of the following:

• Enterprise Resource Planning (ERP)
• Customer Relationship Management (CRM)
• Supply Chain Management (SCM)
• Other Enterprise Application Integration (EAI) applications
• Virtualized database management systems

I also talk about how the hub will accept incoming data -- events and data -- from various sources. I use X, Y, and Z axes to illustrate pictures in the three-dimensional space.

Back to top

What is a SOA integration hub?

A SOA integration hub is the integration of consolidated SOAs of Web services and non-Web services with back-end enterprise systems. It gets Web services and non-Web services to talk to the enterprise systems residing on servers, mainframes, and minicomputers, each of which runs on a different platform.

A SOA integration hub, however, is not the same thing as service-oriented integration (SOI). SOI integrates between Web services and a mainframe system running on a different platform. It gets Web services to talk through the gateway to a mainframe system. You need ASP.Net or another technology to get the gateway to behave like another Web service.

SOA is the architecture of Web services interactions based on a set of business processes. You can get a Web service in the first SOA to reuse a service on behalf of a Web service in the second SOA. A Web service could comprise several smaller Web services to deliver a service to human-facing consumers.

To define the interaction, you use the description language (for example, for SOAP) or other means of describing the interaction (for example, REST). Each interaction is self-contained and loosely-coupled, so that each interaction is independent of any other interaction. This is in contrast to a tightly-coupled mainframe system that depends on the gateway for integration with Web services.

Back to top

SOA layers

Let's take a look at SOA layers in the two-dimensional space. After this, I will show you why you are better off with a three-dimensional integration hub.

The first five layers of the IBM version of a SOA (see Resources) are, from bottom up:

• Operational systems
• Component-based
• Services
• Business process
• Presentation layer

The sixth layer is the Integration Architecture (also known as the Enterprise Integration Bus) that vertically covers all of the first five layers. Next to this layer is the layer of Quality of Service, Security, Management, and Monitoring.

It is obvious that the operational layer can consist of EAI packaged applications, legacy, older object-oriented, and business-intelligence applications. All can be integrated with the second layer's component-based systems using SOI - at either project or enterprise level. Components are then combined or integrated into composite applications to provide services in the third layer.

The fourth layer shows how those services flow from one to another according to a set of business processes. The next higher layer leverages Web services at the application interface through the Web Services for Remote Portlet (WSRP) standard or other means at the human-facing presentation level.

SOA that is two-dimensional and static could become problematic. Fortunately, the evolution of the integration hub means that it is becoming three-dimensional and dynamic.

Back to top

Reusable architectures

Let's suppose this Web service needs to get information from a mainframe system before running on the .Net platform and then on a WebSphere platform. You need to integrate Web services with the mainframe gateway behaving like another Web service.

All Web services communicate with one another in XML on how business processes in multiple SOAs should be integrated and implemented in providing services. While Web services are reusable in multiple SOAs, I go a step higher by treating SOAs as reusable architectures.

When I have multiple instances of consolidating reusable SOAs as an integration hub connecting with mainframe systems, I suggest the following four steps for creating the hub:

1. Modularize an array of SOAs as reusable architectures into two parts. The first part primarily involves mechanisms to integrate Web services while the second part mainly focuses on service interactions.
2. Optimize each SOA to a more compact form for optimal speed and reliability. Check disk space for fragmentation that could affect performance.
3. Prioritize SOAs in order of importance and frequency of reuse. Check user requirements for changes in the priority of SOAs.
4. Consolidate SOAs as an integration hub connecting to one or more mainframe systems running on different platforms. Check interoperability issues that have not been previously addressed.

Back to top

Repository of modularized SOAs

You could develop a repository or library of modularized and optimized SOAs grouped into a hierarchy of various categories. Each category could be further divided into subgroups of SOAs with Web services at the lowest levels of the hierarchy.

You could use the repository as a dynamic linkage to a Web services application. When the application needs to access a modularized SOA, it links itself to the repository. When it does not need the retrieved SOA any more, it releases itself from the repository, saving disk space while increasing speed and performance.

Here are some examples of modularized SOAs in the repository:

• Healthcare SOA
• Retail Management SOA
• Logistics SOA
• Radio Frequency Identification (RFID) SOA

Back to top

Repository use example

Let's suppose you use the last three SOAs -- Retail Management, Logistics, and RFID -- in the repository to develop an integration hub and connect them to a mainframe gateway. Over time user requirements change to eliminate the Retail Management SOA and replace it with the Healthcare SOA.

Meanwhile, the Logistics SOA has been updated with a newer version to meet changes in user requirements. After including new subgroups in the RFID SOA, all subgroups are prioritized and optimized.

Back to top

Two-dimensional unshared SOAs

Let's take a look at a two-dimensional hub of three modularized SOAs from the Blue Repository: Retail Management, Logistics, and RFID (see Figure 1). All are connected to a mainframe gateway. You can get the gateway to behave like a Web service if you use ASP.Net, for example.

As you see, the SOAs are not shared. You can combine all three as a composite application to reduce the number of connectors to the mainframe gateway.

Back to top

Two-dimensional shared SOAs

As Figure 2 shows, RFID SOA overlaps Logistics SOA on one side. The overlapped area is shown in yellow with black slant lines. It contains resources both SOAs use to generate a service or two.

Back to top

Represent the hub in a three-dimensional space

How can you visualize the three-dimensional hub on a two-dimensional computer screen? One way of handling this issue is to draw X, Y and Z axes of the integration hub in the two-dimensional space. Another way is to use a software that easily converts a 2D picture into a 3D version.

In a three-dimensional hub, you can replace an existing mainframe with a newer model or a different vendor's without changing the SOAs. Alternatively, you can reconfigure or change the priority of SOAs to adapt to a new or updated mainframe system in response to changing user and organizational requirements.

Back to top

First three-dimensional hub

Consider an integration hub in the three-dimensional space as Figure 3 shows. As you see, RFID SOA is partially behind Logistics SOA. The hidden part of the RFID SOA is outlined with a blue line to the Logistics SOA.

As you see, the connector from the RFID SOA goes through, rather than around, Logistics SOA on its way to the mainframe gateway. What this means is that the connector from the RFID SOA shares some resources with the Logistics SOA.

Back to top

Second three-dimensional hub

Let's suppose the RFID SOA overlaps in front of the Logistics SOA, but not from the sides of either, as Figure 4 shows. This gives the RFID SOA more options of sharing a wider range of resources in the Logistics SOA.

As you see, the connector from RFID SOA goes through Logistics SOA.

Back to top

How many shared SOAs?

The number of SOAs you can share in a three-dimensional hub depends on the trade-offs among the complexity of the project, consolidation issues, and business processes. Like you avoid SOA overhead, you need to ensure that hub overload will not occur in the three-dimensional space during the entire life cycle of development. You should test for the overload at each point of the cycle.

Back to top

Conclusion

Consolidating SOAs in a three-dimensional hub requires planning ahead of time to set the limit for how many SOAs can be developed and shared. You should communicate with a team of business analysts on various consolidation issues. You will find that resolving consolidation issues will make your job of developing a three-dimensional hub much easier. You can develop SOAs that can be reused and shared in a hub. The analysts will find that resolving the issues will make their job of designing and analyzing an integration hub in the three-dimensional space much easier. They can determine which mainframe systems can be connected to the hub without incurring hub overload.

Resources

• Get information on how to work with Web services in enterprise-wide SOAs from the following papers in a series:
  • "Close enterprise system gaps with multiple SOAs"(developerWorks, February 2005)
  • "Maximize external Web services interoperability"(developerWorks, February 2005)
  
  
  
• Want to know about the IBM SOA layers? Go to Part 1 of the "Service-oriented modeling and architecture" series to find out more.
  
  
• 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 .
  
  
• 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)
  
  
  
• Get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. You can download evaluation versions of the products at no charge, or select the Linux® or Windows® version of developerWorks' Software Evaluation Kit.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• 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

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• What is a SOA integration hub?
• SOA layers
• Reusable architectures
• Repository of modularized SOAs
• Repository use example
• Two-dimensional unshared SOAs
• Two-dimensional shared SOAs
• Represent the hub in a three-dimensional space
• First three-dimensional hub
• Second three-dimensional hub
• How many shared 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