J2EE WITH SOAP

the soa provide a powerful framework for building next-generation applications. the p2p approach differs from the soa in

that no attempt is made to define explicit roles, and node or peer can operate in any role it knows about or can discover

through other peers on the p2p network. actually, the document exchange model is the default method of exchanging data

between two endpoints. an rpc call is a specialized case of combining multiple one-way asynchronous messages into a

request-response. the sopa specification describes four major components: formattting conventions for encapsulating

data and routing direction in the form of an envelpoe ,a transport ot protocol binding, encoding rules and an rpc

mechanism. the envelope defiens a convention for describinf the content of a message, which in turn has implications on

how it gets processed. a protocol binding provide a generic mechanism for sendinf a soap envelope via a lower-level

protocol such as http.  encoding rules provide a convention for mapping various application datatypes into an xml tag-

based representation. finally, the rpc mechanism provides a way to represent remote procedure calls and their return

values. a soap envelope contains two primary components: a header and a body, both the header and the body can

contain multiple blocks of information. the namespace declaration prevents tag name conflicts when xml fragements are

combined to form composite documnets. it is analogous to the use of the package keyword in java. the additional

information needed by the protocol that it is bound to. these special urls point to apache's routing and dispatching

mechanism. this mechanism looks at the content of the soap envelope and decides which class to load and which method

to call within the class. apache refers to this destination as a service. the service is registered with the servlet engine in a

two-step process. first , an xml deployment descriptor is created,specifying detailds about the class name of service.,its

associated method call and the target uri, then a special org.apache.soap.server.servermanagerclient class is invoked to

register the service with apache soap. using the rpc router ,any java class and method can be registered as a service; the

apache soap infrastructuer will call the method with the appropriate parameters.

soap-rpc defines a model for representing an rpc and an rpc response using the soap infrastructure.when soap-rpc is

bound to http, an rpc invocation maps naturally to an http request, and an rpc return maps naturally to an http response.,but

this natural mapping is purely conincidental. soap encoding is a set of rules that designates how datatypes are encoded or

serialized over the wire. an identifier might specify the location of a resource or its name independent of location. a

universal reource identifier is a generic representation that can either be a universal resource locator or universal resource

name. a url is something that represents a physical network location and contains things that pertain to a particular

protocol.  a urn is something that does not necessarily resolve to any physical location;generally it is intended to be used to

identigy something uniquely such as a soap action or a namespace.

wsdl is an xml grammar for describing a web service as a collection of acces endpoints capable of exchanging messages

in a procedure or document-oriented fashion. a wsdl document is a recipe used to automate the details involved in

application -to application communication. wsld can be used to describe endpoints and their messgaes,regardless of the

message format or network protocol used to exchange them. treat messages as abstract description of the data being

exchanged; treat  port types as abstract collections of a web service operations. a port type can then be mapped to a

concrete protocol and data format. wsdl has created separate definitions and terminology for defining a web service, the

communication endpoint where that web service exists, the legal format for ipput and output message for the webservice

and an abstract way to declare a binding  to a concrete protocol and data format.
the <definitions> element in a wsdl document acts as a container for the service decription. it provides a place to do global

declarations of namespaces that are intended to be visible throughout the rest of the document. the targetnamespace

attribute of the <definitions> element defines the namespace definition that this document is creating. the <import>

element serves a purpose similar to the #include directive in the c/c++ programming lanuage. it lets you separate the

elements of a service definition into independent documents and include them in the main document. effective use of the

<import> elements promotes the modularization of wsdl documents and creates an environment of reuse that can create

clear service definitions. the <types> element in a wsdl document acts as a container for defining the datatyoes used in

<message> elements .<message> elements define the format of messages interchanged between a client and a web

service. the <message> element is used to model the data exchanaged as part of a web service.<message> elements

reference the types defined in the <type> section. the data contained within a <message> element typed  by a <message>

element is abstract. a message consists of one or more <part> subelements. a <part> subelement identifies the individual

pieces of data that are part of this data message and the datatypes that the pieces adhere to. the <portType> element

specifies a subset of operatipns supported for an endpoint of a web service. in a sense, a <porttype> element provides a

unique identifier to a group of  actions that can be executed at a single endpoint. the <operation> element represents an

operation. this element is an abstract definition of an action  supported by a web service. a wsdl <operation> element is

analogous to a java method definition. a wsdl  operation can have input and output message as part of its action.a

<binding> element is a concreate protocol and data format specification for a <porttype> element. it is where you would

use one of the standard binding extensions -http, soap, or mime or create one of your own. each protocol has its own wire

format. a <service> elements is iused only when desribling the actual endpoint of a service.
a web service is a groupring of  one or more <port> elements. a <port> elements represents a single endpoint for the

webservice.
the uddi project also defines a set of xml schema definitions that describe the data formats used by the various

specification api. two apis are described by the uddi specification: the inquiry api and the publishing api. they are

accessed using the same techniques  but use different xml document, data structures and access points. the inquery api

locates information about a business the services a business offers ,the specification of those services and the

information about what to do in a failure situation.  the publishing api is used to create ,store or update information located

in a uddi registry. all functions in this api require authenticated access to a uddi registry; the uddi registry must have a

logon identity and the security credential for this identity must be passed as a parameter of the xml document for each uddi

invocation. the programmer's api identifies the structure of the request and response messages paying particular attention

to the input parameters for every request messgae. when doing any development with uddi, you should keep a copy of

these two documents. jaxr is a uniform approach to accessing a registry that advertise business information and servcices

in xml. jaxr attempts to provide a single api that can access many difference kinds of registries including eco framework

,ebxml and uddi. wsdl is  used to describe the interface of a web service. <tmodel> uddi documents provide metadata

descriptiomns of a web service and pointers to specifications that describe their implementation .

jaxm consists ofd two main areas. the messaging capability provide a patternfor sending and receiving soap messages.,

with or without attachment. the soap packaging part provide s apis for constructing and deconstructing soap and mime

envelopes. generally, the functionality is separated cleaniy between the javax.xml.messaging package and javax.xml.soap

packages.  a java code generation model for client-side stubs and server-side tie classes based on a set of conventions

for mapping wsdl to java and java to wsdl.
soap is a wire protocol that can be layered upon other protocols such as http ,ftp and smtp. j2ee support these internet protocols through servlets. servlets are respnosible for extracting the soap contents from other wire packet.