Web Service

WSDL	Java
Message  input1...n
Opteraton	Method
Message output	Return value
Fault Message	Exception
Service	Service Class
PortType	PortType Class

 

 

Binding - define message format and protocol details

 

Port - define interface exposed by webservice.

 

Operation type - 4 types: one-way, request-response, solicit response, notification

 

From	To
<Message> name	<PortType> =>Operation => Input/Output message attribute
<Message> name	<Binding> => Input/Output => header/body message attribute
<PortyType> =>Operation => input name	<Binding> =>Operation => input name
<PortType> => name	<Binding> => type attribute

 

 

PortType can contain more than 1 operation

 

Binding defines port communication protocol,can define multi-binding for a certain port type

Biding is targeting operation of a port type, it defines

• message format(soap, text)
  
• transport type (http, email...)
  

 

There are 2 kinds of error message:

1. Soap Fault message - system generated due to system error
2. Business error message - defined as fault message, and returned in soap message body

 

 

WSDL Binding Style

• RPC/encoded,
• RPC/literal
• Document/encoded,
• Doument/literal
• document/literal wrapped pattern
  

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.

（http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ ）

 

 

Web service style

RPC, Document which are not how web service is called, but how the message is constructed (formated)

 

Compare two styles

 

RPC	<foo:concat> xmlns:foo="http://ttdev.com/ss" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-Instance"> <s1 xsi:type="xsd:string">abc</s1> <s2 xsi:type="xsd:string">123</s2> </foo:concat>
Document	<foo:concatRequest xmlns:foo="http://ttdev.com/ss"> <s1>abc</s1> <s2>123</s2> </foo:concatRequest>

 

The significant difference is that the former can't be
validated with a schema while the latter can. Therefore, document style web
service is becoming the dominant style. According to an organization called
"WS-I (web services interoperability organization)", you should use document
style web services only.

(Developing  web service with Apache CXF and Axis 2, Kent Ka La Tong ) good book, highly recommneded, first 2 chapters are free, I read it and find its quite helpful and easy to understand,

You can find the free chapters here: http://wiki.apache.org/ws/FrontPage/Axis2/

URI

• URL - location of an obect.
  
• URN - purely Id of an object
  

 

Qname

namespace + local part

In Web service, each port, binding, port type and operation has a Qname uniquely identify it,

 

 

Web Service style

• RPC-Literal is always wrapped (not BARE). - allow more than one element bound to body
• Document Literal (BARE) - allow only one element bound to body
• Document Literal Wrapped (The parameterStyle attribute in the SOAPBinding annotation is removed and that implies the service is wrapped due to "Wrapped" being the default for the attribute.)

• http://www.khanna111.com/articles/SOAP_Styles_Differences.html
• http://www.coderanch.com/t/501314/Web-Services/java/Simple-Unwrapped-Wrapped-SOAP-messages#2277662
• http://fusesource.com/docs/framework/2.2/jaxws/JAXWSServiceDevJavaFirstAnnotateOptionalSOAPBinding.html
• http://msdn.microsoft.com/en-us/library/2b4bx2t6%28VS.80%29.aspx

 

Client side handler

• For an outbound message (for instance, a client request under the request/response MEP), the handleMessage method or handleFault method in a LogicalHandler code execute before their counterparts in a SOAPHandler .

• For an inbound message, the handleMessage method or handleFault method in a SOAPHandler code execute before their counterparts in a LogicalHandler .

 

Way to deal with web service attachement

 

1. The DIME solution - it seems an old protocol .
2. The MTOM solution - protocol on the way
3. Binary encoding - xsd:hexBinary or a xsd:base64Binary type, simplest but not efficient, as paraser will go through it even don't need it.

 

http://www.ibm.com/developerworks/webservices/library/ws-tip-noattach.html

 

 

wsimport

wsdl - physicla location of wsdl file when run the command

wsdlLocation - its set in the @WebserviceClient to point to wsdl file which can be found in Jar file

 

JAXB

If compiler see ref or inner complexType , it will generate elementType

 

Sample 1：

<jaxws:bindings
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    wsdlLocation="xxxx/xxxxx/xxxxxxxx.wsdl"
    xmlns:jaxws="http://java.sun.com/xml/ns/jaxws">
        <jaxws:package name="xx.xx.xxxx.xxx"/>
</jaxws:bindings>

 

Sample 2：

<?xml version="1.0" encoding="UTF-8"?>
<jaxb:bindings jaxb:version="2.0"
               xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               schemaLocation = "xx/xxx/xxxx.xsd"
               node="//xsd:schema">
        <jaxb:schemaBindings>
            <jaxb:package name="package.xxx.xxx"/>
        </jaxb:schemaBindings>   
    </jaxb:bindings>

 

Explain Axis2 - how to handle web service request

http://wso2.org/library/176

 

Web Service class annotation

@javax.jws.WebService(endpointInterface = "xxx.xxx.XXXPortType", targetNamespace = "http://ns.xxxx.xxx.xxxx/xxx/xxx", serviceName = "XXXService", portName = "XXXXPort")
@Addressing(enabled = false)
@HandlerChain(file = "xxxhandlers.xml")

MyServiceImpl implement MyServicePortyType{...}

 

IBM Admin Console URL

http://localhost:9061/ibm/console/unsecureLogon.jsp

https://localhost:9043/ibm/console/logon.jsp

 

 

WSDL 1.1 distinguishes between two message styles: document and RPC. Here's how each style affects the contents of <soap:Body> .

• Document: <soap:Body> contains one or more child elements called parts. There are no SOAP formatting rules for what the <soap:Body> contains; it contains whatever the sender and the receiver agree upon.
• RPC: RPC implies that <soap:Body> contains an element with the name of the method or remote procedure being invoked. This element in turn contains an element for each parameter of that procedure.

For applications that use serialization/deserialization to abstract away the data wire format, there's one more choice to be made: the serialization format. There are two popular serialization formats today:

• SOAP Encoding: SOAP encoding is a set of serialization rules defined in section 5 of SOAP 1.1 and is sometimes referred to as "section 5 encoding." The rules specify how objects, structures, arrays, and object graphs should be serialized. Generally speaking, an application using SOAP encoding is focused on remote procedure calls and will likely use RPC message style. The rest of this article ignores SOAP encoding and focuses on literal format.
• Literal: Data is serialized according to a schema. In practice, this schema is usually expressed using W3C XML Schema. Although there are no prescribed rules for serializing objects, structures, and graphs, etc., the service's schema describes the application-level Infoset of each of the service's messages.

Ref : http://msdn.microsoft.com/en-us/library/ms996466.aspx