Level: Intermediate Judith Myerson (jmyerson@bellatlantic.net), Systems engineer and architect
24 Feb 2005 Maximize the interoperability of external Web services in multiple Service-Oriented Architectures (SOA) between external and internal Web services. Judith Myerson shows you how you can change the type of service, location, and platform for each Web service to implement business processes of the originating application.
Introduction
In my first paper in this series on enterprise-wide Service-Oriented Architectures (SOA), "Close enterprise system gaps with multiple SOAs" (see Resources), I talked about the scenarios of closing enterprise system gaps with SOAs by showing you how you can reuse Web services -- data-centric and business logic -- from one or more SOAs and combine them into a composite application within the control of an organization.
When Web services are outside the control of the organization, you need to ensure that they can interoperate externally with one another with respect to shared semantics and contractual obligations. Semantic misunderstandings (such as proprietary) and contractual loopholes (such as multiplatform differences) contribute to interoperability problems between external enterprise Web services.
In this paper, I show you the following four instances of implementing Manufacturing Resource Planning (MRP) and Customer Relationship Management (CRM) services:
- Enterprise legacy application
- Dynamic link-up to external Web services
- Co-existence of REpresentational State Transfer/Simple Object Access Protocol (REST/SOAP) requests to an external Web service
- Web services interoperability using IBM® WebSphere® Application Server and Microsoft® Visual Studio .Net
While considering various trade-offs, it is important to determine the maximum number of interoperable SOAs a system can carry so that you can avoid SOA overloads.
Enterprise legacy application
Let's assume an enterprise legacy application (see Figure 1) is divided into modular components of business processes. The application's two critical components -- MRP and CRM -- require frequent changes and recompilation of a long-running application.
Figure 1. Enterprise legacy application
Dynamic service link-up
To increase operational efficiency, it makes more sense to extract these components from the application and rebuild them as external Web services. This way, you can change code in both Web services rather than recompile a large, complex, long-running application.
The application redesigned in a more compact form in the first SOA (see Figure 2) can link-up dynamically to an external enterprise MRP Web service in the second SOA that, in turn, points to an external enterprise CRM Web service in the third SOA. Upon receiving the request, the CRM Web service sends requests and information to the application for further processing.
Figure 2. Dynamic link-up to Web services
Each linkage mechanism comes in the form of sending a request or message, receiving a response, or performing a SQL or HTTP operation. You can also wrap an application lacking the MRP component so that it sends a request to an MRP Web service.
Software frameworks
You should keep in mind that interoperability issues between platforms can arise when switching from one protocol to another and one software framework to another. Some examples include SOAP, REST, .Net Framework, Enterprise Java Beans (EJB), and Java Messaging Service (JMS).
.Net Web services running over HTTP can be called in three different ways: HTTP GET operation, HTTP POST operation, and SOAP. The GET and POST operations are useful if you need to call a Web Service quickly and no SOAP client is readily available. You can use REST to perform GET, POST, PUT, and DELETE operations over the HTTP in a Perl script. In this script, you can specify SQL queries and simple message queues.
If the SOAP client is available, here's how to make a simple choice between REST and SOAP. If the application is resource-based, choose REST. If the application is activity-based, opt for SOAP. Under REST, a client might request that several operations be performed on a series of resources over the HTTP. For SOAP-based requests, only one invoke operation is needed for each activity-oriented service that a client might request be performed.
Invocation framework
To construct SOAP requests, you need Web Services Language Description (WSDL), which is a language describing how to access a Web service and what operations it will perform. You can specify the type of service without customizing code for the Web service and without recompiling the legacy application.
To ensure WSDL will work with various software frameworks, you can take advantage of the IBM Web Services Invocation Framework (WSIF) that lets you use WSDL as a normalized description of disparate software. This means you can access WSDL in a manner that is independent of protocol or location through an API around the description language. It also means you can combine Web services as a composite application using one WSDL in which you can switch protocols or locations under various conditions and exceptions.
To build a WSIF you need to meet minimum requirements, no matter what provider you are going to use. The options include the following:
- JAXP XML parser
- WSDL for Java API
- Apache SOAP
- Apache Axis.
REST and SOAP co-existence
While REST requests do not depend on WSDL like SOAP requests do, you need XML Schemas to validate REST operations. Since WSDL supports the schema specification, REST and SOAP can co-exist as requests from a composite Web service application to an external Web service.
For instance, the application in SOA #1 (see Figure 3) first sends a SOAP request to invoke an activity-oriented service from the MRP Web service in SOA #2 and then sends a REST request to operate on a series of resource-oriented services to the same MRP Web service. All SOAP-based requests are based on the IBM WSIF.
Figure 3. REST and SOAP co-existence
As you can see, the application in the first SOA runs on a Unix or Linux server, while the MRP Web service in the second SOA runs on the IBM WebSphere Application Server (Application Server). You can use WSIF to change the type of service and location in the normalized version of the WSDL for SOAP-based requests.
WebSphere and .Net product interoperability
If you wish to develop more complex Web services as part of a larger enterprise system development project on Linux or a Windows platform, consider IBM Rational® Application Developer for Websphere Software. It comes with Universal Modeling Language (UML) Visual Editor for Java™ and EJB and runs on an Eclipse open source platform, allowing you to extend your development environment . You can also use Microsoft Visual Studio.Net.
You can use either software to partition application logic into modular Web service components of multiple business processes. IBM goes one step higher by offering Web Services Navigator, a Rational Application Developer plug-in, that lets you interact visually with Web services transactions.
If you are using Visual Studio.Net to develop Web services on the Microsoft .Net platform, you can run them on Application Server. This means you can contract Web services interoperability between two platforms (see Resources), and all you need to do is develop a WSDL common to both platforms.
For instance, the application running on a Unix or Linux server (see Figure 4) first sends a SOAP request to invoke an activity-oriented service from the MRP Web service running on Application Server. The application then sends a REST request to operate on a series of resource-oriented services to the same MRP Web service. Upon receiving a request, the CRM Web service in SOA #3 sends a request or information to the originating application.
Figure 4. Multi-platform external Web services
As you can see, the CRM Web service in the third SOA runs on the .Net platform and accesses Application Server. The CRM Web service sends a request or information to the application in the first SOA. You can add a Visual Perl plug-in for Visual Studio.NET. You can also use command-level Perl for a Unix-to-Windows migration of a REST-based Perl script and adapt it to the Visual Perl environment, depending on the complexity of the script.
Visual Studio
It is easier for you to work with Visual Studio .Net than if you use Visual Basic, C++, Java, or Kornshell to encapsulate Unix applications as COM components. It is also easier to work with it than if you develop an application to run Windows applications with Unix shell scripts, or if you migrate Unix applications into a Windows platform to get connected to external Web services.
Here are some tips you should know. First, you should publish your own WSDL in a public location to resolve some interoperability differences. You can skip the automatically-generated WSDL file in either Rational Application Developer's Bottom Up approach or Visual Studio .Net's WSDL First approach. You can use Rational Application Developer's Skeleton or Top Down approach to start with your WSDL file and fill in the Java Class implementation. Alternatively, you can disable the automatic generation of a WSDL file in the Visual Studio's WDSL First approach and publish your own.
Second, to provide yourself with a WSDL template you can work on, consider Rational Application Developer's Bottom Up approach (from a Java Bean), Rational XDE (to generate template code based on class models), or the Visual Studio's Implementation First Approach (to generate template code after you start off by writing code for your Web service). While Rational Application Developer offers the WSDL editor, Visual Studio.Net might not have it.
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.
Conclusion
Maximizing external Web services interoperability between multiplatform 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 resolving interoperability issues will make your job of developing applications much easier. You can develop external Web services, each of which can use a different platform and request protocol. The analysts will find that resolving the issues will make their job of designing and analyzing a system of multiplatform SOAs much easier. They can determine on which platforms Web services can run without incurring SOA overload.
Resources
About the author  | | | 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. |
Rate this page
| 
