SOA Suite – Developer Preview

SOA Suite developer preview is available from : http://www.oracle.com/technology/software/products/ias/soapreview.html

Documentation for SOA, ESB, BPEL available from : http://download-east.oracle.com/otn_hosted_doc/soa/docs/index.htm

WSIF Notes

1. The Web Services Invocation Framework (WSIF) is a simple Java API for invoking Web services, no matter how or where the services are provided.
2. WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model.
3. WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.
4. The separation of the API from the actual protocol also means you have flexibility – you can switch protocols, location, etc. without having to even recompile your client code.
5. So if your an externally available SOAP service becomes available as an EJB, you can switch to using RMI/IIOP by just changing the service description (the WSDL), without having to make any modification in applications that use the service.
6. You can exploit WSDL’s extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc.
7. In the WSDL specification, Web service binding descriptions are extensions to the specification. So the SOAP binding, for example, is one way to expose the abstract functionality (and there could be others). Since WSIF mirrors WSDL very closely, it also views SOAP as just one of several ways you might wish to expose your software’s functionality. WSDL thus becomes a normalized description of software, and WSIF is the natural client programming model.
8. The WSIF API allows clients to invoke services focusing on the abstract service description – the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols.
9. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol – for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work.
10. The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services – such as service migration, change of protocols, etc.
11. WSIF also allows new providers to be registered dynamically, so you could enhance your client’s capability without ever having to recompile its code or redeploy it.
12. A provider is a piece of code that supports a WSDL extension and allows invocation of the service through that particular implementation. WSIF providers use the J2SE JAR service provider specification making them discoverable at runtime.
13. Some bindings for which provider is available : java, ejb, jms, jca

WSDL Notes from W3C Spec

1. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.
2. Elements in WSDL:
   1. Types – a container for data type definitions using some type system (such as XSD).
   2. Message – an abstract, typed definition of the data being communicated.
   3. Operation – an abstract description of an action supported by the service.
   4. Port Type – an abstract set of operations supported by one or more endpoints.
   5. Binding – a concrete protocol and data format specification for a particular port type.
   6. Port – a single endpoint defined as a combination of a binding and a network address.
   7. Service – a collection of related endpoints.
3. WSDL doesn’t introduce a type definition language. Supports XSD as canonical type system. Allows using other type definition languages via extensibility.
4. Binding mechanism is used to attach a specific protocol or data format or structure to an abstract message or operation or end point.
5. It introduces specific binding extensions for the following protocols and message format : SOAP 1.1, HTTP GET/POST, MIME. Other binding extensions can also be used.
6. Message definitions are always considered to be an abstract definition of the message content. A message binding describes how the abstract content is mapped into a concrete format.
7. WSDL has four transmission primitives that an endpoint can support:
   1. One-Way:endpoint receives a message.
   2. Request-Response:endpoint receives a message, and sends a correlated message.
   3. Solicit-Response :endpoint sends a message, and receives a correlated message.
   4. Notification : endpoint sends a message.
8. There may be any number of binding for a port type. A Binding must specify exactly one protocol. Binding must not specify address information.
9. A port must not specify more than one address. It must not specify any binding information other than address information.
10. Ports within service have the following relationship:
    1. None of the ports communicate with each other (e.g. the output of one port is not the input of another).
    2. If a service has several ports that share a port type, but employ different bindings or addresses, the ports are alternatives. This allows a consumer of a WSDL document to choose particular port(s) to communicate with based on some criteria (protocol, distance, etc.).
11. SOAP Binding extends WSDL with the following extension elements:
    1. soap:binding – Signify that the binding is bound to the SOAP protocol format: Envelop, header and body. URI for the transport attribute of this element signifies which transport of SOAP. Can be HTTP, SMTP, FTP etc.,
    2. soap:operation – Required for the HTTP protocol binding of SOAP. For other SOAP protocol bindings, soap:action attribute must not be specified and this attribute may be omitted.
    3. soap:body – specifies how message parts appear inside soap body element. May be abstract schema defintiions or concrete. If abstract, then serialized according to some encoding style. The soap:body element is used in both RPC-oriented and document-oriented messages, but the style of the enclosing operation has important effects on how the Body section is structured:
       1. If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body
       2. If the operation style is document there are no additional wrappers, and the message parts appear directly under the SOAP Body element.
    4. soap:address – The SOAP address binding is used to give a port an address (a URI). The URI scheme specified for the address must correspond to the transport specified by the soap:binding.

SOAP Message Embedded in HTTP Request

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI" 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org

/soap/envelope/">
    <soapenv:Body>
        <m:GetLastTradePrice xmlns:m="Some-URI">
            <m:tickerSymbol>DIS</m:tickerSymbol>
        </m:GetLastTradePrice>
    </soapenv:Body>
</soapenv:Envelope>

SOAP Message Embedded in HTTP Response

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org

/soap/envelope/">
    <soapenv:Body>
        <m:GetLastTradePriceResponse xmlns:m="Some-URI">
            <m:price>34.5</m:price>
        </m:GetLastTradePriceResponse>
    </soapenv:Body>
</soapenv:Envelope>

Managing state in SOA

A good link on managing state in SOA. Some of the key points:
1. To Manage conversation state, a state identifier needs to maintain following information w.r.t each request-response interaction

1. Unique identifier of the Web service client
2. Identifier of the Web service conversation originated for that client
3. Identifier of the service request within that conversation
4. Indicator of the conversation phase between the service requester (client) and service provider (Starting, Continuing, and Ending), which is used by the service for proper state maintenance
5. Indicator of the interaction status between the service distribution function of the Web services infrastructure and the invocation interface (very helpful in dynamic invocations with late-binding of Web service interfaces)

2. This identifier information can be passed in three ways:
* Pass the identifier information as an extra parameter in the Web service method; the Web service interface can be designed to accept not only the XML document message, but also to accept additional parameters that represent the state identifier information.
* Pass the identifier information as a part of the XML document—the XML document can contain such information embedded within its body.
* Pass the identifier information in the SOAP message header.
3. First two methods are not preferred as code becomes harder to maintain.
4. Three-step development process:
1. Design and code the basic service components.
2. Develop SOAP message handlers.
3. Construct Web services (expose) out of developed J2EE components.
5. SOAP handlers are for: to handle the insertion of state qualifiers into the standard SOAP message definition. In JAX-RPC services, a handler is represented by a handler class that implements handleRequest() and handleResponse() methods for modifying the request and response message.
6. Create Handlers implementing javax.xml.rpc.handler.Handler and implementing the handleRequest method. The javax.xml.soap.SOAPMessage class is used by the handler to manipulate the SOAP message. A SOAPMessage object contains a SOAPPart object that contains the actual SOAP XML document and a SOAPEnvelope object that is “decomposed” to access SOAP body and header.
7. Get a SoapFactory instance and createElement using it. To the element addTextNode. Finally construct WS using handlers and deploy to AS.