Web Service

WSDL Java
Message  input1...n                    
OpteratonMethod
Message outputReturn value
Fault MessageException
ServiceService Class
PortTypePortType 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

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值