Correction added in red.

This is the final post dedicated to web services alone.

As I mentioned before, web services address the important issue of interoperability between different applications built on different technologies. The ability to get these two applications to talk to each other, meaningfully, is what interoperability is all about.

Before I go forward, let me digress a little bit. It is not that the problem of interoperability did not exist before. But there were other ways to address that problem. One of the easiest solutions was to address it at the level of the database i.e. throw the database schema open to other applications that wanted to use that data. But that raised issues of security through they were ways to address that issue. Then there was and still is the methodology of using uploaded files that can be imported and exported. This raises the issues of synchronization and a time lag , but most applications that use this method believe that they can live with that. The time window of the data between the 2 systems being out of sync is so small that it is acceptable.

Finally, more recently, message oriented solutions or Message Oriented Middleware (MOM) was and still is the recommended way of addressing interoperability issues. Enterprise Service Bus (ESB) and Internet Service Bus (ISB) are built on top of messaging infrastructures and provide the most elegant way of integrating multiple applications and building new ones that use the existing portfolio of applications. Reuse has suddenly moved up the development chain!

Now the 2 major competing technologies out there, when it comes to building robust, scalable software applications are Microsoft technologies and Java technologies. This post will look at how web services are built and deployed on these competing technologies and how they can now interoperate , thanks to web services.

My preceding posts have talked about web services alone and I have tried to keep it simple to give the reader a basic understanding of what web services are all about. For the technical reader, or for a reader who wishes to go into the technical details, the book referrals , the Microsoft (MSDN Library) and Sun sites are better sources of information. This is more of an attempt to capture the concepts, the salient ‘whys’ and not the intricate ‘howtos’ and address the concerns of a lay reader who needs just a high-level understanding as to how these technologies are changing the way businesses operate. IT should not remain in isolation and neither can management reside in an ‘ivory tower’ and be unconcerned – so as to push IT operations to the back-office and neither can IT personnel hope to remain in their cubby, cushy(?) cubicles and be unconcerned about the business concerns and changes affecting firms and the industry at large and their ramifications , especially disruptive change. (As another digression, when change happens either in the form of inventions and/or innovations, you in all probability can make more money by investing in firms that benefit from/use them, not the inventions/innovations themselves. It’s a much safer bet! I’m not talking Qualcomm though!)

Back to interoperability! Interoperability between 2 different systems or applications is via the HTTP protocol only. That is the protocol that guarantees interoperability between applications that expose their services.

1> Microsoft Technologies:

The Microsoft enabling technologies that help us write web services are the following:

IIS, ASP.NET and WCF.

IIS: Internet Information Services (IIS) – formerly called Internet Information Server – is a set of Internet-based services for servers created by Microsoft for use with Microsoft Windows.

ASP.NET: ASP.NET is a web application framework developed and marketed by Microsoft to allow programmers to build dynamic web sites, web applications and web services. It was first released in January 2002 with version 1.0 of the .NET Framework, and is the successor to Microsoft’s Active Server Pages (ASP) technology. ASP.NET is built on the Common Language Runtime (CLR), allowing programmers to write ASP.NET code using any supported .NET language. The ASP.NET SOAP extension framework allows ASP.NET components to process SOAP messages.

WCF: The Windows Communication Foundation (or WCF), is an application programming interface in the .NET Framework for building connected, service-oriented applications.

A Service in WCF , like web services elsewhere,  is composed of three parts — you can consider it as the acronym ABC –

Address – where the services is hosted – maps to the more technical URI

Binding – how the service’s client will communicate with the service – this is the protocol to be used

Contract – the different methods that will be accessible via the end-point

WCF provides a unified programming model for building service-oriented applications. This programming model remains consistent and is independent of the run-time environment in which the service is deployed. In practice, this means that the code for your services looks much the same whatever the hosting option.

What this means that the application developer focuses solely on writing the service. How the service is to be used and deployed or hosted is not the developer’s immediate concern.

Hosting Options for WCF services

WCF seeks to abstract the technical details of the hosting of a service. This , in an attempt to make the end user i.e. the developer more productive (But I sometimes wonder, if this is sometimes an excuse to come up with fancy, intimidating acronyms!)

There are 4 different ways in which WCF services can be hosted:

a> Self-Hosting in a Managed Application

b>Managed Windows Services

c> Internet Information Services (IIS)

d>Windows Process Activation Service (WAS)

Of these, to build interoperable services only the following are relevant:

c> Internet Information Services (IIS)

The IIS hosting option is integrated with ASP.NET. On the Windows XP and Windows Server 2003 operating systems, this is the preferred solution for hosting Web service applications that must be highly available and highly scalable. IIS also offers the integrated manageability that customers expect from an enterprise-class server product.

Note that IIS-hosted services can only use the HTTP transport.

d>Windows Process Activation Service (WAS)

Windows Process Activation Service (WAS) is the new process activation mechanism for the Windows Server 2008 that is also available on Windows Vista. It retains the familiar IIS 6.0 process model (application pools and message-based process activation) and hosting features (such as rapid failure protection, health monitoring, and recycling), but it removes the dependency on HTTP from the activation architecture. IIS 7.0 uses WAS to accomplish message-based activation over HTTP. Additional WCF components also plug into WAS to provide message-based activation over the other protocols that WCF supports, such as TCP, MSMQ, and named pipes. This allows applications that use communication protocols to use the IIS features such as process recycling, rapid fail protection, and the common configuration system that were only available to HTTP-based applications.

In effect, when writing interoperable applications, depending on the operating system version , the services will be hosted either using IIS i.e. ASP.NET or Windows Process Activation Services (WAS) or IIS 7.0  with ASP.NET.The HTTP protocol is the protocol of choice.

References: For more details about Hosting Windows Communication Foundation Services

2> Java Platform Technologies:

The J2EE or JEE (Java Enterprise Edition) is the platform upon which web services are deployed, preferably.

The JEE platform supports 2 kinds of web-services:

a> JSE (Jax-RPC/JAX-WS Service end-points) : Here, the web service is deployed through a JAX-RPC/JAX-WS servlet. The web service is available at the web container level. The service is accessed though a servlet which then delegates to a JSE.

b> EJB end-point (Enterprise Java Bean end-point): Here, a web service is a wrapper round a stateless session bean. This is useful is you wish to leverage the transaction capabilities of the EJB container. The only other reason you would wish to use an EJB end-point is if you wish to retro-fit web services onto your existing applications.

In the above 2 cases, a JAX-RPC/JAX-WS mapping is done to map the interfaces, methods and parameters to the WSDL portType, operation, and message definitions. This is crucial to make the technology work.

Here, from J2EE 1.5 onwards, the JAX-RPC API has been replaced by the JAX-WS specification API. RPC stands for Remote Procedure Call and WS for Web Services. JAX-WS also allows Java developers to consume RESTful services, an improvement on its predecessor.

References: http://java.sun.com/developer/technicalArticles/WebServices/restful/

http://cwiki.apache.org/GMOxDOC22/restful-web-services.html

http://java.sun.com/webservices/technologies/index.jsp

In practice, building web services is platform agnostic. So a top-down approach i.e. starting from defining the services in a WSDL file, the tools available on the respective platforms may be used to generate partial implementations. Having a clear picture of the functionality to be exposed to other client applications is thus key to building a good service oriented architecture (SOA) application. Of course, in practice, enabling legacy applications would require a meet-in-the-middle approach, to ensure that the baby is not thrown out with the bath water.

This post can be used to as a starting point to delve into details such as the Basic Profile 1.0  and WSIT (Web Services Interoperability Technology). This post , thus , does not talk about WS-* or WS-extensions. These are meant for making Web Services follow certain guidelines with regards to non-functional requirements and also address interoperability concerns. This post’s purpose was to give the reader a top-level understanding of how Microsoft and Java platforms approach web services and how they are usually deployed. For Java developers, an brief on Apache AXIS would be necessary as well.

 

Have a good day!