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:
- Soap Fault message - system generated due to system error
- 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
- The DIME solution - it seems an old protocol .
- The MTOM solution - protocol on the way
-
Binary encoding - xsd:hexBinary
or axsd: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