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>

Multiple DTD in xml and namespace workaround in DTD

Following xml fragments will give an idea of how to use multiple dtd’s in xml and also the workaround of specifying namespace in dtd

File : s.dtd
============
<?xml version=”1.0″ encoding=”UTF-8″?>
<!ELEMENT computer (ns1:address) >
<!ELEMENT ns1:address (type, ipaddress)>
<!ELEMENT type (#PCDATA)>
<!ELEMENT ipaddress (#PCDATA)>

File : s1.dtd
==============
<?xml version=”1.0″ encoding=”UTF-8″?>
<!ELEMENT ns2:student (name, ns2:address, computer) >
<!ATTLIST ns2:student xmlns:ns2 CDATA #FIXED “http://krishna/ns2″>
<!ELEMENT ns2:address (#PCDATA) >
<!ELEMENT name (#PCDATA) >

File:student.xml
================
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE ns2:student SYSTEM “s1.dtd” [<!ENTITY % s SYSTEM "s.dtd">
%s;
]>
<ns2:student xmlns:ns2=”http://krishna/ns2″>
<name >krishna</name>
<ns2:address>unknown</ns2:address>
<computer>
<ns1:address>
<type></type>
<ipaddress></ipaddress>
</ns1:address>
</computer>
</ns2:student>