![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
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.
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
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.
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.
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.
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.
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.
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.
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.
- 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)
- "Consolidate your SOAs as a three-dimensional integration hub to improve speed and reliability"(developerWorks, March 2005)
- Find out more about Rational Application Developer's Bottom Up and Top Down approaches (developerWorks, January 2005).
- Download IBM Rational Application Developer to give it a try. Alternatively, you can order a CD.
- Learn more about IBM Web Services Navigator.
- Learn more about how you can use REST for simple Web services at Amazon's Web services.
- Want to know about the IBM WSIF? Go to the Apache website to find out more.
- Read James M. Snell's article comparing resource-oriented and activity-oriented Web services (developerWorks, October 2004).
- 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.
- 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.
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.
Table of contents
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
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
