Using Web services for application integration

Web services is the silver bullet for business-to-business communications. This article explores this concept using the function/method-oriented integration pattern.

Web services will play a major role in function/method-oriented integration, which is one of the most commonly used patterns for enterprise and business-to-business application integration. In this article, I discuss how XML Web services can be used for function/method-oriented application integration; how leading application frameworks (Microsoft .NET and Java 2 enterprise edition [J2EE]) provide support for it; and scenarios where this integration pattern should be used using Web services.

Function/method-oriented integration
Function or method integration involves the direct and rigid application-to-application (A2A) integration of cross-platform applications over a network. It can range from custom code (COBOL, C++, Java); to application programming interfaces (APIs); to remote procedure calls (RPCs); to distributed middleware such as TP monitors, distributed objects, common object request broker architecture (CORBA), Java remote method invocation (RMI), message oriented middleware (MOM), and DCOM; to XML Web services using Simple Object Access Protocol (SOAP).

Function or method-oriented integration is primarily synchronous in nature—it is based on request/response interactions between the client (requesting program) and the server (responding program). See Figure A.

Web services as enabling technology
Web services technology provides a standard mechanism for applications to publish and subscribe to software services over an intranet or the Internet. Client applications (Web service users) may locate these services published by server applications (Web service providers) using Universal Discovery, Description, and Integration (UDDI), determine the interface definition of the service using Web Services Description Language (WSDL), and exchange data using Extensible Markup Language (XML) documents based on Simple Object Access Protocol (SOAP) over universal protocols such as HTTP, FTP, and SMTP.

To the Web services client application, it appears that it is calling a method locally, but the method call is translated to XML (based on SOAP) and sent over the network to the Web services provider application. The provider sends the response of the method call back as an XML document (based on SOAP).

Because Web services are accessible using URLs, HTTP, and XML, applications running on any platform and in any language can access XML Web services.

Support from leading application frameworks
Let’s quickly review how the leading application frameworks—Microsoft .NET and J2EE—provide support to enable function/method-oriented integration.

Microsoft .NET
Microsoft .NET is the Microsoft XML Web services platform. It provides built-in support for building and consuming standards-based Web services. In Microsoft’s .NET framework, client applications can invoke a Web service by implementing a Web service listener.

Using Microsoft .NET, function/method-oriented integration can occur as follows:

• The server application (Web service provider) can implement the Web service in any of the .NET languages, such as C#, VB.NET, or Managed C++, which can be compiled into Microsoft Intermediate Language (MSIL) and executed in a virtual machine called Common Language Runtime (CLR).
• The Web service can be deployed on a .NET platform.
• The client application (Web service user) can implement the Web service listener using MSXML or ASP.NET and invoke the Web service using a method call.

J2EE
J2EE is a set of specifications, each of which dictates how various J2EE functions must operate. It provides Java API for XML-based RPC (JAX-RPC) to support function/method-oriented Web services integration. JAX-RPC uses XML to make remote procedure calls (RPC) and exposes an API for marshalling and unmarshalling arguments, transmitting and receiving procedure calls. As of now, the JAX-RPC reference implementation relies on SOAP 1.1 and HTTP 1.1.

Using JAX-RPC, function/method-oriented integration can occur as follows:

• Define and implement a JAX-RPC-based Web service. The implementation of Web service can be in stand-alone Java application or Enterprise Java Bean (EJB). JAX-RPC API can be used to create SOAP-based wrappers that confirm to the WSDL interface for existing Java classes or EJBs.
• Deploy the Web service on a server-side JAX-RPC runtime system. The deployment is governed by the implementation of the Web service; for example, if the implementation is provided by EJB, the deployment will be in an EJB container.
• Invoke the Web service from the client application on the port described by the WSDL document. To the client application, the invocation of the Web service would appear to be a local method call.

When should function/method-oriented integration be used?
This topic has been one of the most contested issues among application architects: Should the applications be integrated synchronously or asynchronously? Asynchronous message-oriented applications have a different design and architecture than stateful and synchronous function/method-oriented applications. The application architecture, business requirements, and partner agreement (between in-house groups for EAI and partner companies for B2B integration) dictate the usage of this integration pattern.

Web services technology solves some of the shortcomings of RPC- and API-oriented integration (non-XML standard based), as follows:

• RPCs and APIs offer a static solution for function level integration, even if they use XML for client/server communication. Web services offer a dynamic approach for integration, where the services can be discovered, bound to, and used dynamically. This is primarily enabled due to the fact that Web services are found using a defined standard: UDDI.
• RPCs and APIs can use any proprietary protocol, but Web services are built and used over existing, universal protocols such as HTTP and SMTP. This new distributed computing solution exploits the openness of specific Internet technologies to address many of the interoperability issues of CORBA and DCOM.
• RPCs and APIs do not offer the servers a standard way of exposing their public methods to clients. Each server program may have its own implementation. Web services, on the other hand, are always exposed by the servers in a standard form using WSDL. So the clients and servers do not have to implement their own proprietary format for using and publishing public methods.

In conclusion, Web services-based function/method-oriented integration is vendor-, platform-, and language-neutral.

Original article – http://www.techrepublic.com/article/using-web-services-for-application-integration/