My Tech Learnings: October 2012

Sunday, October 7, 2012

Encode Decode HTML Entities

Tool to Encode Decode HTML entities
http://centricle.com/tools/html-entities/

Difference Between Document Style and RPC Style WebService

A WSDL SOAP binding can be either a Remote Procedure Call (RPC) style binding or a document style binding. A SOAP binding can also have an encoded use or a literal use. This gives you four style/use models:

RPC/encoded
RPC/literal
Document/encoded
Document/literal

The terminology here is very unfortunate: RPC versus document. These terms imply that the RPC style should be used for RPC programming models and that the document style should be used for document or messaging programming models. That is not the case at all. The style has nothing to do with a programming model. It merely dictates how to translate a WSDL binding to a SOAP message. Nothing more. You can use either style with any programming model.

the terms encoded and literal are only meaningful for the WSDL-to-SOAP mapping, though, at least here, the traditional meanings of the words make a bit more sense.

See basically there is difference in WSDL and SOAP messages. Now we know there are different parts in WSDL file , the specific pasts having difference are

<message&gt: and
<binding&gt:

here is how

A message part may declare either a type attribute or an element attribute, but not both. Which to use depends on the kind of messaging you're doing. If you're using RPC-style messaging, the part elements must use the type attribute; if you're using document-style messaging, the part elements must use the element attribute
RPC Style
<definitions name="BookPrice" ...>
...
<message name="GetBulkBookPriceRequest">
<part name="isbn" type="xsd:string"/>
<part name="quantity" type="xsd:int"/>
</message>
<message name="GetBulkBookPriceResponse">
<part name="price" type="mh:prices" />
</message>
...
</definitions>
Document Style
<message name="SubmitPurchaseOrderMessage">
<part name="order" element="mh:purchaseOrder" />
</message>

The soapbind:binding and soapbind:body elements are responsible for expressing the SOAP-specific details of the Web service.
• soapbind:binding tells us that the "messaging style" is RPC (or document) and that the "network application" protocol is HTTP.
• The soapbind:body element tells us that both the input and output messages use literal encoding.
You may have noticed that attributes of the soapbind:body element change depending on whether you use RPC- or document-style messaging. The soapbind:body element has four kinds of attributes:
1. use :- required to be literal ( ?? can it be document?? ) if absent default=literal
2. namespace :- In "rpc"-style messages, the namespace attribute must be specified with a valid URI. In document style it must not be specified.
3. part :- specifies which part elements in the message definition are being used. necessary only if you are using a subset of the part elements declared by a message
4. and encodingStyle : - never used

RPC style specify the namespace attribute in the soapbind:body. In contrast, document-style messages must not specify the namespace attribute in the soapbind:body element. The namespace of the XML document fragment is derived from its XML schema

Example of a rpc style

<?xml version="1.0" encoding="UTF-8"?>

<definitions name="BookQuoteWS"

targetNamespace="http://www.Monson-Haefel.com/jwsbook/BookQuote"

xmlns:mh="http://www.Monson-Haefel.com/jwsbook/BookQuote"

xmlns:soapbind="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns="http://schemas.xmlsoap.org/wsdl/">

...

<soapbind:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/>

<soapbind:operation style="rpc"

soapAction=

"http://www.Monson-Haefel.com/jwsbook/BookQuote/GetBookPrice"/>

<input>

<soapbind:body use="literal"

namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />

</input>

<soapbind:body use="literal"

namespace="http://www.Monson-Haefel.com/jwsbook/BookQuote" />

</output>

</operation>

</binding>

...

</definitions>

In contrast, document-style messages must not specify the namespace attribute in the soapbind:body element. The namespace of the XML document fragment is derived from its XML schema

<soapbind:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http"/>

<soapbind:operation style="document"/>

<input>

<soapbind:body use="literal" />

</input>

<soapbind:body use="literal" />

</output>

</operation>

</binding>

As an example lets consider one java method in all four ways

public void myMethod(int x, float y);

RPC Encoded

</message>

</operation>

</portType>

Now invoke this method with "5" as the value for parameter x and "5.0" for parameter y. That sends a SOAP message which looks something like below.

RPC/encoded SOAP message for myMethod

<soap:envelope>

<soap:body>

</myMethod>

</soap:body>

</soap:envelope>

Strengths

The WSDL is about as straightforward as it's possible for WSDL to be.
The operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation.

Weakness

· The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance.

· You cannot easily validate this message since only the 5 and 5.0 lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions.

· Although it is legal WSDL, RPC/encoded is not WS-I compliant.

RPC Literal

The RPC/literal WSDL for this method looks almost the same as the RPC/encoded WSDL (see Listing 4). The use in the binding is changed from encoded to literal. That's it.

RPC/literal WSDL for myMethod

</message>

</operation>

</portType>

What about the SOAP message for RPC/literal (see Listing 5)? Here there is a bit more of a change. The type encodings have been removed.

RPC/literal SOAP message for myMethod

Strengths

· The WSDL is still about as straightforward as it is possible for WSDL to be.

· The operation name still appears in the message.

· The type encoding info is eliminated.

· RPC/literal is WS-I compliant.

Weaknesses

· You still cannot easily validate this message since only the < x ... >5< / x > and < y ... > 5.0< / y > lines contain things defined in a schema; the rest of the soap:body contents comes from WSDL definitions.

Document Encoded

Nobody follows this style , it's not WSI compliant

Document Literal

The WSDL for document/literal changes somewhat from the WSDL for RPC/literal. The differences are highlighted in bold

Strengths

There is no type encoding info.
You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema.
Document/literal is WS-I compliant, but with restrictions (seeweaknesses).

Weaknesses

The WSDL is getting a bit more complicated. This is a very minor weakness, however, since WSDL is not meant to be read by humans.
The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible.
WS-I only allows one child of the soap:body in a SOAP message. As you can see in Listing 7, this example's soap:body has two children.

WSDL

WSDL stands for Web Service Description Language. as the full form suggests it is a document that describes Web Service.

WSDL is used to specify the exact

message format,
Internet protocol,
and address

that a client must use to communicate with a particular Web service.

Note :- that WSDL 1.1 is not specific to SOAP; it can be used to describe non-SOAP-based Web services as well.

A WSDL document contains seven important elements: types, import, message, portType, operations, binding, and service, which are nested in the definitions element.

A WSDL description of a "stock quote" service:

<?xml version="1.0"?>

<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"

xmlns:tns="http://example.com/stockquote.wsdl"

xmlns:xsd1="http://example.com/stockquote.xsd"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>

<schema targetNamespace="http://example.com/stockquote.xsd"

xmlns="http://www.w3.org/2000/10/XMLSchema">

<all>

</all>

</complexType>

</element>

<all>

</all>

</complexType>

</element>

</schema>

</types>

</message>

</message>

</operation>

</portType>

<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>

<soap:operation soapAction="http://example.com/GetLastTradePrice"/>

<input>

<soap:body use="literal"/>

</input>

<soap:body use="literal"/>

</output>

</operation>

</binding>

<documentation>My first service</documentation>

<soap:address location="http://example.com/stockquote"/>

</port>

</service>

</definitions>

some data types are defined using XML Schema
some simple message types are defined from the data types
the port type describes a single operation GetLastTradePrice, which uses the message types for input/output
the binding tells that the communication is through SOAP
the port associates the binding with the URI http://example.com/stockquote where the running service can be accessed

The XML Declaration

< ? xml version= " 1 . 0 " encoding = " UTF-8 " ? >

A WSDL document must use either UTF-8 or UTF-16 encoding; other encoding systems are not allowed.

The Definitions Element

The root element of all WSDL documents is the definitions element, which encapsulates the entire document and also provides a WSDL document with its name.

The definitions element usually contains several XML namespace declarations, which is normal for a root element.

Name attribute is not important nothing refers to it, its optional.

The definitions element also declares a targetNamespace attribute, which identifies the namespace of elements defined in the WSDL document—much as it does in XML schema documents.

The types Element

The types element serves as a container for defining any data types that are not described by the XML schema built-in types: complex types and custom simple types.

You can also define an array type inside type.

The Import Element

The import element makes available in the present WSDL document the definitions from a specified namespace in another WSDL document. This feature can be useful if you want to modularize WSDL documents—for example, to separate the abstract definitions (the types, message, and portType elements) from the concrete definitions (the binding, service, and port elements).

Use of the import element is convenient, but it can also create versioning headaches. If WSDL documents are maintained separately, the risk of an imported document being changed without regard to the WSDL documents that import it is pretty high. Take care to ensure that imported WSDL documents are not changed without considering versioning.

You can use import and types together, but you should list the import elements before the types element in a WSDL document.

The WSDL Abstract Interface the message type , portType , and Operations Element

The abstract interface of the Web service is described by

message,
portType,
and operation elements

Message	Can be simple or complex or simple custom
Operation	Like a java method , defines input & output messages for an operation.
Port Type	Like interface ( collections of operation )

The Message Type

describes outgoing and ingoing messages. The way to define a message element depends on whether you use RPC-style or document-style messaging.

They may describe

call parameters,
call return values,
header blocks,
or faults

RPC Style

...

</message>

</message>

...

</definitions>

Document Style

</message>

The Port Type

A portType defines the abstract interface of a Web service.

The "methods" of the portType are its operation elements.

Binding Element

The binding element maps an abstract portType to a set of

· concrete protocols such as SOAP and HTTP,

· messaging styles (RPC or document),

· and encoding styles (Literal or SOAP Encoding).

The Service and port elements

The service element contains one or more port elements, each of which represents a different Web service.

how WSDL tells if WebService is one way or two way.

The port type should have input and output. input before ouptput indicates that in coming msg shud come before outgoing.

</operation>

</portType>

and one way messaging is like

</operation>

</portType>

WebService Synchronous & Asynchronous call,

In Synchronous call, if you are making any request, then you will have to wait till the response, you can't do any other thing until you will not get the response.

In Asynchronous call, if you are making any request, then you don't need to wait for the response and you can perform any other task. Whenever the response will come, you can receive in call back delegate.

SOAP With Attachments

SOAP message can handle attachments. there is another api for that SAAJ. SAAJ stands for the "SOAP with Attachments API for Java -- an offshoot of the Java API for XML Messaging (JAXM) -- automates many of the required steps, such as creating connections or creating and sending the actual messages. This tip chronicles the creation and sending of a synchronous SOAP message.

The process involves five steps:

Creating a SOAP connection
Creating a SOAP message
Populating the message
Sending the message
Retrieving the reply

The figure shows a high-level structure of a SOAP message that has two attachments.

Base on above figure we have following structure of java objects. defined by SAAJ Apis

I. SOAP message

A. SOAP part

1. SOAP envelope

a. SOAP header (optional)

b. SOAP body

Note: Many SAAJ API interfaces extend DOM interfaces.

When you create a new SOAPMessage object, it will automatically have the parts that are required to be in a SOAP message. In other words, a newSOAPMessage object has a SOAPPart object that contains a SOAPEnvelope object. The SOAPEnvelope object in turn automatically contains an empty SOAPHeader object followed by an empty SOAPBody object. If you do not need the SOAPHeader object, which is optional, you can delete it. The rationale for having it automatically included is that more often than not you will need it, so it is more convenient to have it provided.

The SAAJ API provides the AttachmentPart class to represent an attachment part of a SOAP message. A SOAPMessage object automatically has a SOAPPart object and its required subelements, but because AttachmentPart objects are optional, you must create and add them yourself.

If a SOAPMessage object has one or more attachments, each AttachmentPart object must have a MIME header to indicate the type of data it contains. It may also have additional MIME headers to identify it or to give its location. These headers are optional but can be useful when there are multiple attachments.

SAAJ and DOM

The SAAJ APIs extend their counterparts in the org.w3c.dom package:

The Node interface extends the org.w3c.dom.Node interface.
The SOAPElement interface extends both the Node interface and the org.w3c.dom.Element interface.
The SOAPPart class implements the org.w3c.dom.Document interface.
The Text interface extends the org.w3c.dom.Text interface.

public class SOAPTip {

public static void main(String args[]) {

try {

// First create the connection

SOAPConnectionFactory soapConnFactory = SOAPConnectionFactory.newInstance();

SOAPConnection connection = soapConnFactory.createConnection();

//Next, create the actual message

MessageFactory messageFactory = MessageFactory.newInstance();

SOAPMessage message = messageFactory.createMessage();

//Create objects for the message parts

SOAPPart soapPart = message.getSOAPPart();

SOAPEnvelope envelope = soapPart.getEnvelope();

SOAPBody body = envelope.getBody();

//Populate the body

//Create the main element and namespace

SOAPElement bodyElement = body.addChildElement(envelope.createName("getPrice" ,

"ns1", "urn:xmethods-BNPriceCheck"));

//Add content

bodyElement.addChildElement("isbn").addTextNode("0672324229");

//Populate the Message

StreamSource preppedMsgSrc = new StreamSource( new FileInputStream("prepped.msg"));

soapPart.setContent(preppedMsgSrc);

//Save the message

message.saveChanges();

//Check the input

System.out.println("\nREQUEST:\n");

message.writeTo(System.out);

System.out.println();

//Send the message and get a reply

//Set the destination

String destination = "http://services.xmethods.net:80/soap/servlet/rpcrouter";

//Send the message

SOAPMessage reply = connection.call(message, destination);

//Check the output

System.out.println("\nRESPONSE:\n");

//Create the transformer

TransformerFactory transformerFactory = TransformerFactory.newInstance();

Transformer transformer = transformerFactory.newTransformer();

//Extract the content of the reply

Source sourceContent = reply.getSOAPPart().getContent();

//Set the output for the transformation

StreamResult result = new StreamResult(System.out);

transformer.transform(sourceContent, result);

System.out.println();

//Close the connection

connection.close();

} catch(Exception e) {

System.out.println(e.getMessage());

}

Difference between SOAP 1.1 and SOAP 1.2

1. Just as a person can perform one or more roles in a stage play, a node can play one or more roles in a SOAP message path. Unfortunately, the designers of SOAP 1.1 confused the words "actor" and "role"; they specified that you must identify the roles a node will play by declaring an actor attribute. They've recognized their mistake, and in SOAP 1.2 this attribute has been renamed role.

2. Neither SOAP 1.1 nor the BP explicitly prohibits intermediaries from modifying the contents of the Body element. As a result, the ultimate receiver has no way of knowing if the application-specific data has changed somewhere along the message path. SOAP 1.2 reduces this uncertainty by explicitly prohibiting certain intermediaries, called forwarding intermediaries, from changing the contents of the Body element and recommending that all other intermediaries, called active intermediaries, use a header block to document any changes to the Body element.

3. SOAP 1.2 will replace the SOAPAction header with the protocol-independent action media type (a parameter to the "application/soap+xml" MIME type), so dependency on this feature may result in forward-compatibility problems.