In my first article in the series on enterprise-wide SOAs, "Closing enterprise system gaps with multiple SOAs," I talked about the scenarios of closing enterprise system gaps with SOAs by showing how Web services -- data-centric and business logic -- from one or more SOAs can be reused and combined into a composite application within the control of an organization.
In the second article, "Maximize external Web services interoperability," I gave instances of service interoperability without incurring multiple SOA overloads, from simple protocol coexistence to complex interoperability of multiplatforms. And you learned how to change the type of service, location, and platform for each Web service to implement business processes of the originating application.
Part 3 of the series, "Consolidate an SOA as a three-dimensional integration hub to improve speed and reliability," explained how you can consolidate multiple SOAs of Web services and non-Web services as a single, three-dimensional integration hub to connect to various back-end enterprise mainframe systems. In this article, I will explain how you can develop an enterprise SOA middleware application in the three-dimensional space using development tools from IBM® Rational® software. You also learn how Web service components can be combined as a middleware application across multiple SOAs and how they can be developed using these four different approaches:
- Top-down
- Bottom-up
- Sideway
- Embedding
Let's begin by looking at each approach from both physical and logical perspectives.
Logical and physical Web services
A physical Web service is what is published and found in a repository. After creating a logical Web service, you can proceed to combine a logical Web service with another physical Web service to create a new logical Web service for consumption. This allows you to then combine the resulting logical Web service with another physical or logical Web service. You can also transform a logical Web service into a physical Web service component for publication and discovery in the repository.
You can create an SOA middleware application of logical Web services by defining the relationship between a business model of the middleware application and physical Web service components. To do this, you can use either or both Rational Software Architect and Rational Software Modeler to provide development support for model-driven development with Unified Modeling Language (UML) and to support UML visual modeling design for documenting different views of a system, respectively.
The top-down approach starts from the top of a pyramid (see Figure 1) with a middleware application of Web services or non-Web services. You need to divide it into smaller Web services or components, and continue the process of dividing at each lower level of the pyramid until the smallest parts or components reach the bottom of the pyramid. All parts of the system integrate and interoperate with one another with no issues or problems.
Figure 1. Top-down approach
Interoperability, however, can have a different meaning, depending on what the application intends to do. For instance, if the application is data-centric, the interoperability is data-centric. But if the application primarily aims at implementing businesses process, the interoperability is process based.
Now, let's take a look at the top-down approach from a logical perspective. The top-down approach considers the goal of an application that comprises the enterprise SOA middleware application. The goal is grouped into subgoals, each of which is further grouped into smaller units. The process continues until it reaches the bottom of the pyramid of the SOA middleware application.
Obviously, it's important to ensure all subgoals interoperate with one another with no issues or problems. If the goal aims at providing a service or a group of services, service interoperability becomes a top concern. However, if the goal aims at implementing policies and rules, we need to focus on policy interoperability.
In the real world, no such thing as pure data-centric, process-based, or policy interoperability exists. Instead, we typically end up with a mixed bag of data, process, service, and policy interoperability. The portion of the mix for each type of interoperability can vary dynamically, depending on how each Web service is modularized, prioritized, optimized, and maximized for interaction with one another in a loosely coupled manner. It also depends on which platform the Web services run (such as the open Eclipse architecture).
Taking a physical perspective, the bottom-up approach defines a basic Web service component as the smallest part of the foundation. This allows you to combine it with larger elements at the next level, continuing the process until all parts are integrated as a complete middleware application of complex Web services and relationships at the pyramid apex, as shown in Figure 2.
Figure 2. Bottom-up approach
This physical perspective assumes that all parts of the system interoperate with one another with no issues or problems. The meaning of interoperability depends on the type of Web services interoperating with one another: data-centric, business process, or a combination. The portion of the mix of each type of interoperability between applications can vary dynamically.
From a logical perspective, the bottom-up approach starts with subgoals (service components, for example) as the building blocks of the foundation for an enterprise goal of an SOA. You as a developer can, along with analysts, combine them into larger subgoals at the next level. You continue the process until all subgoals are integrated as one enterprise goal for the SOA middleware at the pyramid apex.
It's important to ensure all subgoals will interoperate with one another with no issues or problems. If a subgoal aims at providing a service or a group of services, our top concern is service interoperability among subgoals. However, if a subgoal aims at implementing policies and rules, our concern becomes policy interoperability among subgoals.
From a physical perspective, the sideway approach (shown in Figure 3) allows you to add or delete Web service components sideway to the top-down or bottom-up approach. This allows you to better respond to changing design and development requirements while keeping the existing middleware intact. The sideway perspective assumes that components to be added will interoperate with existing ones with no problems or issues. It also assumes that components to be deleted will not disrupt the interoperability of remaining components with others.
Figure 3. Sideway approach
From a logical perspective, the sideway approach allows you to start by adding a subgoal to the logical Web services at the sideway of either the top-down or bottom-up approach. This lets you add, for example, the type of service and location of the new Web services. You can delete a subgoal from the logical Web services using the sideway of either approach.
You can also change a subgoal of a Web service to reuse it for developing various middleware applications. Just make sure when you logically add, delete, or change a subgoal, the interoperability among Web services works without problems or issues in the production environment. You need to ensure running Web services in the test environment comes out with flying colors with no problems or issues.
From both physical and logical perspectives, the embedded approach is a mix of the previous three approaches two or three levels deep in at least one of the pyramid layers. In the example of the nested, two-level embedding approach, you can embed the top-down approach within the bottom-up approach (see Figure 4) or the other way around. You could also embed the sideway approach within the top-down or bottom-up approach.
Figure 4. Embedding approach
You can achieve a nested three-level embedded approach. You do this by embedding, for example, the sideway approach within the top-down approach and in turn, the bottom-up approach. You could also embed the top-down approach within the second top-down approach and in turn, the bottom-up approach.
Deciding which approach to use
Developing an SOA middleware application in an open architecture depends, for example, on which of the relational or WebSphere® packages you want to use. As mentioned earlier, you can use Rational Software Architect and Rational Software Modeler to model an enterprise SOA middleware with Web services as objects, relational entities, or a mix of both. You can also use Rational Web Developer for WebSphere Software for Linux™, Windows® 2000, Windows 2003 Server and Windows XP to simplify your development of Web services.
Developing an enterprise SOA middleware requires advance planning about how many SOAs can be grouped together as the middleware application. It's best to communicate with a team of business analysts about the issues of which approaches to use to develop the middleware. You'll find, too, that resolving these issues make developing the enterprise SOA middleware easier. You can develop SOAs that can be reused and interact and integrate with one another for the middleware application. And by deciding in advance which approach or combination of approaches to use, the analyst's job of designing and analyzing the middleware is easier. The analyst has the ability to determine which approach to use and how many SOAs can be grouped together, since the middleware is based on various types of interoperability among them and can incur an enterprise SOA overload.
- Get information about how to use service-level agreements (SLAs) in a Web services context from the following articles:
- "Guarantee your Web service with a SLA," (developerWorks, April 2002)
- "Guarantee second-generation Web services applications with a SLA," (developerWorks, August 2004)
- "Integrate Web services into EAI with a SLA guarantee," (developerWorks, August 2004)
- "Secure multiple Web services with a SLA guarantee," (developerWorks, October 2004)
- "Firewalling Web services with a SLA guarantee," (developerWorks, November 2004)
- "Localize Web services with a SLA guarantee," (developerWorks, January 2005)
- "Mitigate risk of vulnerabilities with a SLA guarantee," (developerWorks, January 2005)
- Get information about how to work with Web services in enterprise-wide SOAs from the following articles:
- "Close enterprise system gaps with multiple SOAs," (developerWorks, February 2005)
- "Maximize external Web servies interoperability," (developerWorks, February 2005)
- "Consolidate your SOAs as a three-dimensional integration hub to improve speed and reliability," (developerWorks, March 2005)
- Learn more about IBM Express Middleware for midsized businesses.
- Learn more about Rational tools for Linux development.
- 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.
- Publish your Web service or application in IBM's UDDI Version 2 registry, which features a graphical user interface and conformant APIs for public use.
- Go into the nuts and bolts of developing a service-level agreement in this IBM Redbook for Domino administrators.
- Browse for books on these and other technical topics.
- Want more? Visit the developerWorks SOA and Web services zone for hundreds of informative articles and introductory, intermediate, and advanced tutorials about how to develop Web services applications.
- Innovate your business with other IBM products. Try IBM trial downloads to find out how.
Judith M. Myerson is a systems architect and engineer. Her areas of interest include middleware technologies, enterprise-wide systems, database technologies, application development, network management, security, and project management. You can contact her at jmyerson@bellatlantic.net.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
