Agnicient designs and implements Web Services on top of existent J2EE Applications using SOAP, WSDL, UDDI and the Java APIs for XML. We can help you to make your enterprise resources available as Web Services and benefit from their advantages.

Web Services are currently concerned with four basic challenges:

Service Description

Service Implementation

Service Publishing, Discovery and Binding

Service Invocation and Execution

Service Description

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.

Service Implementation

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.

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.

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.

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:

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.

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.