Web Services

Key features -
  • Application Components, Communicating using open protocals.
  • WS Can exchange data bettween different applications and different platforms.
  • Service oriented architecture ( It enables the development of loosly coupled applications)
  • Interoperability across platforms and programing languages
  • Poratabulity (Ability to migrate applications from one platform to another)
  • Reliability, Availability & Scalability.
  • Better suited to loosely coupled , coarse-grained set of relation ships.
Reliablility - representing the how well it maintains  its service and service quality (Can be meassured no of failures that occures in given time period).

Availabulity - Ready for immediate use. Represents the probabulity that service is available.

Scalablility - Handling large no of client interactions.

The above three can be achived by A platform's support for clustered application deployment environments.


SAOP-  Simple Object Access Model.

UDDI - Universal Discription Discovery and Integration


WSDL - Web Service Defination Language

WS Client Side Processing



WS Server Side Processing

Apache Axis (JAX- RPC 1.0)

Apache Axis is an opnesouce, XML based Web Service framework. It consists of a Java and a C implementation of the SOAP server, and various utilities and APIs for generating and deploying Web service applications. Using Apache Axis, developers can create interoperable, distributed computing applications.

Apache Axis2(JAX-WS 2.0)

Latest Verion of Ais2- 1.6.0

Apache Axis2 is a core engine for Web services. It is a complete re-design and re-write of the widely used Apache Axis SOAP stack.
Why Apache Axis2 A new architecture for Axis2 was introduced during the August 2004 Summit in Colombo, Sri Lanka. The new architecture on which Axis2 is based on is more flexible, efficient and configurable in comparison to Axis1.x architecture. Some well established concepts from Axis 1.x, like handlers etc., have been preserved in the new architecture.
Apache Axis2 not only supports SOAP 1.1 and SOAP 1.2, but it also has integrated support for the widely popular REST style of Web services. The same business logic implementation can offer both a WS-* style interface as well as a REST/POX style interface simultaneously.
Axis2 has support for Spring Framework.
Axis2 comes with many new features, enhancements and industry specification implementations. The key features offered are as follows:

Axis2 Features

  • Speed - Axis2 uses its own object model and StAX (Streaming API for XML) parsing to achieve significantly greater speed than earlier versions of Apache Axis.
  • Low memory foot print- Axis2 was designed ground-up keeping low memory foot print in mind.
  • AXIOM - Axis2 comes with its own light-weight object model, AXIOM, for message processing which is extensible, optimized for performance, and simplified for developers.
  • Hot Deployment - Axis2 is equipped with the capability of deploying Web services and handlers while the system is up and running. In other words, new services can be added to the system without having to shut down the server. Simply drop the required Web service archive into the services directory in the repository, and the deployment model will automatically deploy the service and make it available for use.
  • Asynchronous Web services - Axis2 now supports asynchronous Web services and asynchronous Web services invocation using non-blocking clients and transports.
  • MEP Support - Axis2 now comes handy with the flexibility to support Message Exchange Patterns (MEPs) with in-built support for basic MEPs defined in WSDL 2.0.
  • Flexibility - The Axis2 architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management, and anything else you can imagine.
  • Stability - Axis2 defines a set of published interfaces which change relatively slowly compared to the rest of Axis.
  • Component-oriented Deployment - You can easily define reusable networks of Handlers to implement common patterns of processing for your applications, or to distribute to partners.
  • Transport Framework - We have a clean and simple abstraction for integrating and using Transports (i.e., senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, etc.), and the core of the engine is completely transport-independent.
  • WSDL support - Axis2 supports the Web Services Description Language, version 1.1 and 2.0 , which allows you to easily build stubs to access remote services, and also to automatically export machine-readable descriptions of your deployed services from Axis2.
  • Add-ons - Several Web services specifications have been incorporated including WSS4J for security (Apache Rampart), Sandesha for reliable messaging, Kandula which is an encapsulation of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity.
  • Composition and Extensibility - Modules and phases improve support for composability and extensibility. Modules support composability and can also support new WS-* specifications in a simple and clean manner. They are however not hot deployable as they change the overall behavior of the system.

Introduction (JAX-RPC 1.0 vs JAX-WS 2.0)

Web services have been around a while now. First there was SOAP. But SOAP only described what the messages looked like. Then there was WSDL. But WSDL didn't tell you how to write web services in Java™. Then along came JAX-RPC 1.0. After a few months of use, the Java Community Process (JCP) folks who wrote that specification realized that it needed a few tweaks, so out came JAX-RPC 1.1. After a year or so of using that specification, the JCP folks wanted to build a better version: JAX-RPC 2.0. A primary goal was to align with industry direction, but the industry was not merely doing RPC web services, they were also doing message-oriented web services. So "RPC" was removed from the name and replaced with "WS" (which stands for web Services, of course). Thus the successor to JAX-RPC 1.1 is JAX-WS 2.0 - the Java API for XML-based web services.
What remains the same?
Before we itemize the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss what is the same.
  • JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire.
  • JAX-WS still supports WSDL 1.1, so what you've learned about that specification is still useful. A WSDL 2.0 specification is nearing completion, but it was still in the works at the time that JAX-WS 2.0 was finalized.
What is different?
  • SOAP 1.2 JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.
  • XML/HTTP The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.
  • WS-I's Basic Profiles JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the web services interoperability organization.)
  • New Java features
    • JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
    • Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today's web services novices.
  • The data mapping model
    • JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
    • JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.
  • The interface mapping model JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:
    • JAX-WS's model makes use of new Java 5.0 features.
    • JAX-WS's model introduces asynchronous functionality.
  • The dynamic programming model
    • JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs:
      • It introduces message-oriented functionality.
      • It introduces dynamic asynchronous functionality.
    • JAX-WS also adds a dynamic server model, which JAX-RPC does not have.
  • MTOM (Message Transmission Optimization Mechanism) JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.
  • The handler model
    • The handler model has changed quite a bit from JAX-RPC to JAX-WS.
    • JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification.
In the remainder of this tip, we will discuss SOAP 1.2, XML/HTTP, the WS-I Basic Profiles, and Java 5. Each of the remaining five bullets above will be a separate tip in this series.

SOAP encoding

SOAP encoding has fallen out of favor in the web services community. It is not supported by the WS-I basic profile. So JAX-WS, as the latest incarnation of Java web services, has disallowed SOAP encoding. JAX-RPC supports SOAP encoding, so if you really must use SOAP encoded messages, stick with JAX-RPC.
SOAP 1.2
There is really not a lot of difference, from a programming model point of view, between SOAP 1.1 and SOAP 1.2. As a Java programmer, the only place you will encounter these differences is when using the handlers, which we will cover in a future tip. SAAJ 1.3 has been updated to support SOAP 1.2.
XML/HTTP
Like the changes for SOAP 1.2, there is really not a lot of difference, from a programming model point of view, between SOAP/HTTP and XML/HTTP messages. As a Java programmer, the only place you will encounter these differences is when using the handlers, which we will cover in a future tip. The HTTP binding has its own handler chain and its own set of message context properties.
WS-I's basic profiles
JAX-RPC 1.1 supports WS-I's Basic Profile (BP) 1.0. Since that time, the WS-I folks have developed BP 1.1 (and the associated AP 1.0 and SSBP 1.0). These new profiles clarify some minor points, and more clearly define attachments. JAX-WS 2.0 supports these newer profiles. For the most part, the differences between them do not affect the Java programming model. The exception is attachments. WS-I not only cleared up some questions about attachments, but they also defined their own XML attachment type: wsi:swaRef.
Many people are confused by all these profiles. You will need a little history to clear up the confusion.
WS-I's first basic profile (BP 1.0) did a good job of clarifying the various specs. But it wasn't perfect. And support for SOAP with Attachments (Sw/A) in particular was still rather fuzzy. In their second iteration, the WS-I folks pulled attachments out of the basic profile - BP 1.1 - and fixed some of the things they missed the first time around. At that point they also added two mutually exclusive supplements to the basic profile: AP 1.0 and SSBP 1.0. AP 1.0 is the Attachment Profile which describes how to use Sw/A. SSBP 1.0 is the Simple SOAP Binding Profile, which describes a web services engine that does not support Sw/A (such as Microsoft's .NET). The remaining profiles that WS-I has and is working on build on top of those basic profiles.
Java 5
There are a number of changes to the Java language. JAX-WS relies on: annotations, generics, and executors. We will detail exactly how JAX-WS relies on this new functionality in follow-on tips. For information on these new features of Java, see the Java 5 .
Summary
JAX-WS 2.0 is the successor to JAX-RPC 1.1. There are some things that haven't changed, but most of the programming model is different to a greater or lesser degree. The topics introduced in this tip will be expanded upon in a series of tips which we will publish over the coming months that will compare, in detail, JAX-WS and JAX-RPC. At a high level though, here are a few reasons why you would or would not want to move to JAX-WS from JAX-RPC.
Reasons you may want to stay with JAX-RPC 1.1:
  • If you want to stay with something that's been around a while, JAX-RPC will continue to be supported for some time to come.
  • If you don't want to step up to Java 5.
  • If you want to send SOAP encoded messages or create RPC/encoded style WSDL.
Reasons to step up to JAX-WS 2.0:
  • If you want to use the new message-oriented APIs.
  • If you want to use MTOM to send attachment data.
  • If you want better support for XML schema through JAXB.
  • If you want to use an asynchronous programming model in your web service clients.
  • If you need to have clients or services that can handle SOAP 1.2 messages.
  • If you want to eliminate the need for SOAP in your web services and just use the XML/HTTP binding.
  • If you like playing with leading edge technology.
-----------------------------------------------------------------------------------
Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web.
---------------------------
JAXB  --> Used to translate XML to Java Object instances and vice versa.
SOAP/HTML <--> XML/HTML
------------------------------------------------------------------------------------


What are the current free and commercial implementations available for Web Services?

Can I access a web service from within a browser?
You can use the JavaScript XmlHttpRequest object (read introductions here and here). You'll have to create and process the XML requests and responses yourself, though. This works in Internet Explorer, Safari and Mozilla-based browsers like FireFox.
What are the differences between JAX-RPC, JAX-WS, JAX-RS, Apache Axis, SAAJ, Apache SOAP, JWSDP, Metro, Jersey and GlassFish?
  • JAX-RPC is a specification/API for Java developers to develop SOAP based interoperable web services. This API is now obsolete, and may be dropped from the next JEE version.
  • JAX-WS is the successor to JAX-RPC. It requires Java 5.0, and is not backwards-compatible to JAX-RPC. This article describes the high-level differences to JAX-RPC.
  • SAAJ is another specification/API for using SOAP envelopes with or without attachments. It operates on a lower level than JAX-RPC or JAX-WS, both of which will use SOAP envelopes based on SAAJ if needed.
  • Apache Axis is an open source implementation of the Java WS APIs for sending and receiving SOAP messages. Axis 1 supports JAX-RPC and SAAJ, while Axis 2 supports SAAJ and JAX-WS.
  • Apache SOAP was the first SOAP implementation. It is now obsolete. It's better to use Apache Axis to avail oneself of the latest features.
  • Sun JWSDP - Sun Java Webservices Developer Pack, is an implementation of JAX-RPC, SAAJ and various other XML Java technologies. It is now deprecated in favor of the Metro stack.
  • GlassFish is the open source reference implementation of J2EE 5. As such, it contains an implementation of JAX-WS.
  • Metro is the web services stack used in GlassFish?. It supports SAAJ, JAX-WS, WS-Security and other standards.
  • JAX-RS is a Java API for RESTful web services.
  • Jersey is the reference implementation of the JAX-RS API, as defined in the JSR-311 standard for RESTful web services.