With the hype surrounding .NET Web Services, and Sun bringing together an offering for Web Services, it's time we took a look at what's happening. In this article, we compare the two approaches to Web Services, along with examining why you might want to use one method or the other.
Web Services are currently concerned with four basic challenges:
.NET versus J2EE Web Services
A Comparison of Approaches
J. Jeffrey Hanson
1. Service Description
2. Service Implementation
3. Service Publishing, Discovery and Binding
4. Service Invocation and Execution
In the body of this article, we will take each of these challenges in turn and look briefly at how the two technologies handle them.
In order for Web Services to proliferate it is important to be able to describe them in some structured way. The Web Services Description Language (WSDL) addresses this need by defining an XML grammar for describing Web Services as collections of message-enabled endpoints or ports.
In WSDL, the abstract definition of endpoints and messages is separated from their concrete deployment or bindings. The concrete protocol and data format specifications for a particular endpoint type constitute a binding. An endpoint is defined by associating a Web address with a binding, and a collection of endpoints defines a service.
J2EE-enabled Web Services exchange information with interested parties using WSDL to come to an agreement on the proper format for each transferred XML document. Third parties who want to transact business with a J2EE-enabled Web Service company can look up information about the company's Web Services in a registry.
As with a J2EE Web Service, a .NET Web Service supports the WSDL 1.1 specification and uses a WSDL document to describe itself. In this case, however, an XML namespace is used within a WSDL document to uniquely identify the Web Service's endpoints.
.NET provides a client-side component that lets an application invoke Web Service operations described by a WSDL document and a server-side component that maps Web Service operations to COM-object method calls as described by a WSDL and a Web Services Meta Language (WSML) file. This file is needed for Microsoft's implementation of SOAP.
Implementing Web Services currently means structuring data and operations inside of an XML document that complies with the SOAP specification. Once a Web Service component is implemented, a client sends a message to the component as an XML document and the component sends an XML document back to the client as the response.
Existing Java classes and applications can be wrapped using the Java API for XML-based RPC (JAX-RPC) and exposed as Web Services. JAX-RPC uses XML to make remote procedure calls (RPC) and exposes an API for marshalling (packing parameters and return values to be distributed) and un-marshalling arguments and for transmitting and receiving procedure calls.
With J2EE, business services written as Enterprise JavaBeans are wrapped and exposed as Web Services. The resulting wrapper is a SOAP-enabled Web Service that conforms to a WSDL interface based on the original EJB's methods.
The J2EE Web Services architecture is a set of XML-based frameworks, providing infrastructures that allow companies to integrate business-service logic that was previously exposed as proprietary interfaces. Currently, J2EE supports Web Services via the Java API for XML Parsing (JAXP). This API allows developers to perform any Web Service operation by manually parsing XML documents.
.NET applications are no longer executed in native machine code. All programs are compiled to an intermediate binary code called the Microsoft Intermediate Language (MSIL). This portable, binary code is then compiled to native code using a Just In Time compiler (JIT) at run time and run in a kind of virtual machine called the Common Language Runtime (CLR).
With the .NET platform, Microsoft will provide several languages based on the Common Language Infrastructure (CLI), such as Managed C++, JScript, VB.NET and C#. The Microsoft SOAP Toolkit offers components that construct, transmit, read, and process SOAP messages.
Service Publishing, Discovery, and Binding
Once a Web Service has been implemented, it must be published somewhere that allows interested parties to find it. Information about how a client would connect to a Web Service and interact with it must also be exposed somewhere accessible to them. This connection and interaction information is referred to as binding information.
Registries are currently the primary means to publish, discover, and bind Web Services. Registries contain the data structures and taxonomies used to describe Web Services and Web Service providers. A registry can either be hosted by private organizations or by neutral third parties.
IBM and Microsoft have recently announced the Web Services Inspection Language (WSIL) specification to allow applications to browse Web servers for XML Web Services. WSIL promises to complement UDDI by making it easier to discover available services on Web sites not listed in the UDDI registries.
Sun Microsystems is positioning its Java API for XML Registries (JAXR) as a single general purpose API for interoperating with multiple registry types. JAXR allows its clients to access the Web Services provided by a Web Services implementer exposing Web Services built upon an implementation of the JAXR specification.
There are three types of JAXR providers:
- The JAXR Pluggable Provider, which implements features of the JAXR specification that are independent of any specific registry type.
- The Registry-specific JAXR Provider, which implements the JAXR specification in a registry-specific manner.
- The JAXR Bridge Provider, which is not specific to any particular registry. It serves as a bridge to a class of registries such as ebXML or UDDI.
At first, Microsoft had the discovery of Web Services with DISCO in the form of a discovery (DISCO) file. A published DISCO file is an XML document that contains links to other resources that describe the Web Service. Since the wide spread adoption of UDDI, however, Microsoft has supported it in order to maximize interoperability between solutions in what is, after all, a set of specifications for interoperability.
In addition to providing a .NET UDDI server, the UDDI SDK provides support for Visual Studio .NET and depends on the .NET framework. Products such as Microsoft Office XP offer support for service discovery through UDDI.
Service Invocation and Execution
The Simple Object Access Protocol (SOAP) is a simple, lightweight XML-based protocol that defines a messaging framework for exchanging structured data and type information across the Web.
The SOAP specification consists of four main parts:
- A mandatory envelope for encapsulating data
- Optional data-encoding rules for representing application-defined data types, and a model for serializing non-syntactic data models
- A request/response message exchange pattern
- An optional binding between SOAP and HTTP
SOAP can be used in combination with any transport protocol or mechanism that is able to transport the SOAP envelope.
Web Service recipients operate as SOAP listeners and can notify interested parties (other Web Services, applications, etc.) when a Web Service request is received. The SOAP listener validates a SOAP message against corresponding XML schemas as defined in a WSDL file. The SOAP listener then un-marshals the SOAP message. Within the SOAP listener, message dispatchers can invoke the corresponding Web Service code implementation.
Finally, business logic is invoked to get the reply. The result of the business logic is transformed into a SOAP response and returned to the Web Service caller.
J2EE uses the Java API for XML-based RPC (JAX-RPC) to send SOAP method calls to remote parties and receive the results. JAX-RPC enables Java developers to build Web Services incorporating XML based RPC functionality according to the SOAP 1.1 specification.
Once a JAX-RPC service has been defined and implemented, the service is deployed on a server-side JAX-RPC runtime system. The deployment step depends on the type of component that has been used to implement the JAX-RPC service. For example, an EJB based service is deployed in an EJB container.
During the deployment of a JAX-RPC service, the deployment tool configures one or more protocol bindings for this JAX-RPC service. A binding ties an abstract service definition to a specific XML based protocol and transport. An example of a binding is SOAP 1.1 over HTTP.
A Web Service client uses a JAX-RPC service by invoking remote methods on a service port described by a WSDL document.
In Microsoft's .NET framework, interested parties can gain access to a Web Service by implementing a Web Service listener. In order to implement this, a system needs to understand SOAP messages, generate SOAP responses, provide a WSDL contract for the Web Service, and advertise the Service via UDDI.
.NET Developers creating SOAP-based Web Service listeners and consumers currently have three choices:
1. Use the built in .NET SOAP message classes
2. Construct a Web Service listener manually, using MSXML, ASP, or ISAPI, etc.
3. Use the Microsoft Soap Toolkit version 2 to build a Web Service listener that connects to a business facade, implemented using COM.
The Microsoft SOAP Toolkit 2.0 offers a client-side component that lets an application invoke Web Service operations described by a WSDL document.
Time to Choose
Having looked at how J2EE and .NET handle Web Services, we are faced with a choice - which version do we implement? From a purely technical standpoint, each method has advantages and disadvantages.
The key advantage, perhaps, of using the .NET approach to Web Services is that it has been designed for that purpose, whereas J2EE is being retrofitted by the addition of further APIs.
One advantage of using J2EE as a base for your system is that you have a much wider choice of vendor for your pre-built software (application servers mostly), including numerous open source projects. In many ways, open source J2EE application servers are closer to the standard laid down by Sun, because they don't add proprietary extensions to overcome problems.
Ultimately, unless you are starting your system from the bottom up, your choice of Web Services implementation is more than likely going to be influenced by your present system. If you have a team of skilled programmers, with an existing business system, realistically you'll want to continue using that system, be it J2EE based or Microsoft based.
Web Services promise to revolutionize not only the way we develop software systems, but how we do business. Some aspects of Web Services development, such as security and transaction handling, are yet to be completely solved, but must be in order to make the Web Services dream a reality.
WDSL, SOAP, UDDI, XML, Microsoft's .NET and Sun's J2EE provide the technologies and tools needed to get Web Services off to a running start. Are these technologies and tools enough to make Web Services a reality and fulfill all of their promises? Time will tell.
This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com
Or purchase the extended PDF version of this article from: our download site Amazon.com
Adobe Acrobat format (PDF) - 48K 12 pages Price: $20