Web Service Stack

Whenever we talking about Web Service, we heard "Web Service Stack". What does it mean. Its an internal architecture/implementation of Web Services. This implementation is Comprises of protocols.Those protocols are stack over each other. Yes, but maintain a sequence. This protocol stack is used to define, locate, implement, and make Web services interact with each other.
There are four Web Service protocols:

1. Transport Protocol/Transport Layer : The Transport layer is the first component in the stack and is responsible for moving XML messages between applications. The Transport protocol most commonly used is the standard HTTP protocol. Other commonly used Web protocols are SMTP and FTP.

2. Messaging Protocol/XML Messaging : The messaging layer in the protocol stack is based on an XML model. XML is widely used in Web Services applications and is the foundation for all web services. XML is just one of the standards enabling web services to map between technology domains. You will find many resources on the Web that describe XML messaging. For more information, refer to the World Wide Web Consortium (W3C) site on Messaging listed in the link list below.

The XML Messaging specification is a broadly-defined umbrella under which a number of more specific protocols are defined. SOAP is one of the more popular standards, and is one of the most significant standards in communicating web services over the network. XML provides a means for communicating over the Web using an XML document that both requests and responds to information between two disparate systems. SOAP allows the sender and the receiver of XML documents to support a common data transfer protocol for effective networked communication.

3. Description Protocol/WSDL Layer : This layer represents a way of specifying a public interface for a web service. It contains information on available functions, on data types for XML messaging, binding information about the transport protocol, and the location of the specific web service.

Any client application that wants to know about a service, what data it expects to receive, whether or not it delivers any results, and the supported transport, uses WSDL to find that information. When you create a Web Service, it must be described and advertised to its potential customers before it can be used. WSDL provides a common format for describing and publishing that web service information. Typically, WSDL is used with SOAP, and the WSDL specification includes a SOAP binding.

4. Discovery Protocol/UDDI Layer : This layer represents a way to publish and find web services over the Web. You can think of this layer as the White and Yellow Pages of your phonebook. The White pages of web services provides general information about a specific company, for instance, their business name, description, and address. The Yellow Pages includes the classification of data for the services offered, for instance, industry type and products.

The protocol you use to publish your web services is known as UDDI. The UDDI Business Registry allows anyone to search existing UDDI data and enables you to register your company and its services. With RAD Studio, your data automatically gets published to the registry, or a distributed directory for business and web services.

SOA and Web Service

SOA and Web Service are two different things. SOA stands for "Service Oriented Architecture". SOA is an software architecture. SOA is used to create a distributed system. SOA can be used to enable Software as a Service(SAAS). SOA uses the find-bind-execute paradigm. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service. One thing is that, Services are the building blocks of SOA.

Web Services are the preferred standard-based way to realize SOA architecture. Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.

Java API for XML(JAX):
1. Java API for XML Processing(JAXP) 1.2 - This API lets you process XML documents by invoking a SAX or DOM parser in your application. JAXP 1.2 supports W3C XML Schema.

2.Java API for XML-based RPC (JAX-RPC) 1.1 - This is an API for building and deploying SOAP+WSDL web services clients and endpoints.

3.Java APIs for XML Registries (JAXR) 1.0.4 - This is a Java API for accessing different kinds of XML registries. It provides you with a single set of APIs to access a variety of XML registries, including UDDI and the ebXML Registry. You don't need to worry about the nitty-gritty details of each registry's information model.

4.SOAP with Attachments API for Java (SAAJ) 1.2 - This API lets you produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.

5.JSR 109: Web services for J2EE 1.0 - JSR 109 defines deployment requirements for web services clients and endpoints by leveraging the JAX-RPC programming model. In addition, it defines standard deployment descriptors using the XML Schema, thereby providing a uniform method of deploying web services onto application servers through a wide range of tools.

6.JAX-WS 2.0 (JSR 224) -

7.JAXB - the Java Architecture for XML Binding.

8.StAX - the Streaming API for XML.

Sun's new version of web service stack is JAX-WS.

The difference between JAX-RPC and JAX-WS web service stack.

Web Service Properties

1) self-contained - no additional software is required for WS:
   a) client-side: a programming language with XML/HTML client support
   b) server-side: a web server and a SOAP server are needed
2) loosely coupled - client and server only knows about messages - a
   simple coordination level that allows for more flexible re-configuration
3) web-enabled – WS are published, located and invoked across the web,
   using established lightweight Internet standards
4) language-independent and interoperable - client and server may be
   implemented in different environments and different languages
   composable - WS can be aggregated using workflow techniques to
   perform higher-level business functions
6) dynamically bound - with UDDI and WSDL, the discovery and binding of
   web services can be automated
7) programmatic access - the web services approach does not provide a
   graphical user interface but operates at the command level
8) wrap existing applications - stand-alone applications can easily be
   integrated by implementing a web service as an interface

Externalize complex types for Web Service

It is a good programming practise to externalize re-usable complex types or elements in a separate XSD. This can be achived by using standard XML features.

XML provides a way to import any XSD in another XSD file. Now you can use those complex types or elements from imported XSD, but one thing is that you have to specify imported xsd file in a separated namespace and use the namespace prefix to use the complex type or element.

Suppose i have a XSD file, named base.xsd. In which i have a complex type:


Another xsd file in which AddressBn complex type will be used:


Steps:
1. specify namespace for the imported xsd as shown in the first highlighted text.

2. import the xsd file, with target namespace and schema location attribute as shown in the second highlighted text.

3. use the complex type or element prefix with namespace as shown in the third highlighted text.

Required Annotations for Web Service - Java

Java6 provides some annotations for creating Webservice, when the strategy is bottom-up. Here I describe some required annotations for that.

1. @WebService - This annotation is used to identified the WebService name in the SEI.
2. @WebMethod - This annotation is used to identified the WebService Operation in SEI.
3. @WebParam - This annotation is used to identified the WebService Operation's parameter name in SEI.
4. @WebResult - Customizes the mapping of the return value to a WSDL part and XML element

Writing Web Services using Bottom-Up approch

In this approch, you have to do the following steps:

1. Create SEI (Service Endpoint Interface) and its implementation class. The SEI defines the methods that are available for service consumer. Those methods are called Operations - There are two basic patterns for creating an SEI:
   • Green field development
   You are developing a new service from the ground up. When starting fresh, it is best to start by creating the SEI first. You can then distribute the SEI to any developers that are responsible for implementing the services and consumers that use the SEI.

   • Service enablement
   In this pattern, you typically have an existing set of functionality that is implemented as a Java class and you want to service enable it. This means that you will need to do two things:
      a.Create an SEI that contains only the operations that are going to be exposed as part of the service.
      b.Modify the existing Java class so that it implements the SEI.

2. Add the required annotations -

3. Generate WSDL for contract of the service. This step is optional, if you treat SEI as a contract for your service then no need to create WSDL.

4. Publish the web service - You can use any web container to publish the service. The process is the same as adding servlet for web application.


Example:

Create POJOs for the Service:






Create SEI:


Create SIB:


Publish the service:


Create Service Consumer:


Result:


Download the complete example

Web Service Development Strategies

When developing a Web Service Endpoint (the server-side) you have the option of starting from Java (bottom-up development), or from the abstact contract (WSDL) that defines your service (top-down development). If this is a new service (no existing contract), the bottom-up approach is the fastest route; you only need to add a few annotations to your classes to get a service up and running. However, if you are developing a service with an already defined contract, it is far simpler to use the top-down approach.

Bottom-up use cases:
• Providing a new service, and you want the contract to be generated for you.


Top-down use cases:
• Replacing the implementation of an existing Web Service, and you can't break compatibility with older clients.
• Exposing a service that conforms to a contract specified by a third party (e.g. a vender that calls you back using an already defined protocol).
• Creating a service that adheres to the XML Schema and WSDL you developed by hand up front.

There are no of tools for working with Top-down and Bottom-up Web Service Development.

1. JBossWS is one of the implementation of JAX-WS, provided by JBoss.
Bottom-up
• JBossWS - wsprovide :- Generates JAX-WS portable artifacts, and provides the abstract contract. Used for bottom-up development(Java).

Top-down
• JBossWS - wsconsume :- Consumes the abstract contract (WSDL and Schema files), and produces artifacts for both a server and client. Used for top-down and client development.

2. Sun's implementation of JAX-WS, available with JDK6 distribution.
Bottom-up
• wsgen :- Generates JAX-WS portable artifacts, and provides the abstract contract. Used for bottom-up development(Java).

Top-down
• wsimport :- Consumes the abstract contract (WSDL and Schema files), and produces artifacts for both a server and client. Used for top-down and client development.

Method Overloading in WSDL

There is no direct way to overload java method in WSDL, WSDL does not support Overloading mechanism, but you can achive this through other ways. This will be done through RequestWrapper and ResponseWrapper Annotation. Those Annotations are need to be included in Service Implementation Bean(SIB). There is no harm if you add those in Service Implementation(SI). But SIB is mandatory.

@RequestWrapper - have localName, targetNamespace and class. For method overloading you have to specify class name field.

@ResponseWrapper - have same fileds as RequestWrapper, here also you have to specify class name field.

Code Snippet for Service Implementation:


Code Snippet for Service Implementation Bean:


Use this commeand to generate server side artifact and WSDL:
I am using JAX-WS with Jdk6.

prabir$> wsgen -keep -wsdl -cp bin HelloServer -d client

Here HelloServer is the Service endpoint implementation class also known as Service Implementation Bean.