In the implementation of SOAP/JMS for CXF, I need build the Fault Message's by myself (http://www.w3.org/TR/2008/WD-soapjms-20081121/#binding-faults). So I just investigate the usage of SOAPFault in CXF.
Firstly, I learn something in subproject cxf-rt-bindings-soap, I can use org.apcche.cxf.binding.soap.SoapFault to create SOAP Fault Message. The method createFault can create different SOAP Fault Messages for different versions.
Secondly, I know that the WS-Reliablemessaging also need build the fault message about SOAPFault. So I investigate subproject cxf-rt-ws-rm and find some useful code and test for org.apache.cxf.ws.rm.soap.SOAPFactory. I have read some codes about it and know how to build a SOAPFault message.
Are there ny other comments in CXF for SOAPFault?
Welcome!
2009年4月25日星期六
SOAP/JMS proposal
I have posted my SOAP/JMS proposal(http://wiki.apache.org/general/soc2009-soapjms-proposal) Any comments, advices are welcome. If you are interested in the project, just feel free to contract me:)
2009年4月24日星期五
MTOM and SwA
1)Message Transmission Optimization Mechanism(MTOM):
MTOM is a method of efficiently sending binary data to and from web services. It uses XOP (XML-binary Optimized Packaging) to transmit binary data and is intended to replace both MIME and DIME attachments. Binary content often has to be encoded to be sent as text data with SOAP messages. MTOM allows more efficient sending of binary data in a SOAP request or response.
The Figure below shows the steps involved in transmitting data between a Consumer and Producer using MTOM.
The Consumer application begins by sending a SOAP Message that contains complex data in Base64Binary encoded format. Base64Binary data type represents arbitrary data (e.g., Images, PDF files, Word Docs) in 65 textual characters that can be displayed as part of a SOAP Message element.
Step 1 in the Figure above, a sample SOAP Body with Base64Binary encoded is going to be transfered. MTOM-aware web services engine detects the presence of Base64Binary encoded data types, , and makes a decision – typically based on data size – to convert the Base64Binary data to MIME data with an XOP content type.
Step 2 of the Figure above shown in results in replacing the Base64Binary data with an element xop:Include that references the original raw bytes of the document being transmitted. The raw bytes are appended to the SOAP Message and are separated by a MIME boundary.
The raw binary data along with the SOAP Message and the MIME Boundary is transmitted over the wire to the Producer(Step 3). The Producer then changes the raw binary data back to Base64Binary (Step 4)encoding for further processing.
With this conversion between Base64Binary and raw binary MIME types, MTOM provides one significant advantage:
Efficient Transmission: Base64Binary encoded data is 33% larger than raw byte transmission using MIME. MTOM therefore reduces data bloat by converting Base64Binary encoding to raw bytes for transmission.
2)SOAP Message with Attachment (SwA)
SwA has been developed as a way to package SOAP messages with attachments, but will be replaced by the more powerful MTOM/XOP mechanisms.
SwA is not a new specification, but rather a mechanism for using the existing SOAP and MIME facilities to perform the transmission of files using Web Services invocations.
The message structure of SwA is as follows:
MTOM is a method of efficiently sending binary data to and from web services. It uses XOP (XML-binary Optimized Packaging) to transmit binary data and is intended to replace both MIME and DIME attachments. Binary content often has to be encoded to be sent as text data with SOAP messages. MTOM allows more efficient sending of binary data in a SOAP request or response.
The Figure below shows the steps involved in transmitting data between a Consumer and Producer using MTOM.
The Consumer application begins by sending a SOAP Message that contains complex data in Base64Binary encoded format. Base64Binary data type represents arbitrary data (e.g., Images, PDF files, Word Docs) in 65 textual characters that can be displayed as part of a SOAP Message element.
Step 1 in the Figure above, a sample SOAP Body with Base64Binary encoded is going to be transfered.
Step 2 of the Figure above shown in results in replacing the Base64Binary data with an
The raw binary data along with the SOAP Message and the MIME Boundary is transmitted over the wire to the Producer(Step 3). The Producer then changes the raw binary data back to Base64Binary (Step 4)encoding for further processing.
With this conversion between Base64Binary and raw binary MIME types, MTOM provides one significant advantage:
Efficient Transmission: Base64Binary encoded data is 33% larger than raw byte transmission using MIME. MTOM therefore reduces data bloat by converting Base64Binary encoding to raw bytes for transmission.
2)SOAP Message with Attachment (SwA)
SwA has been developed as a way to package SOAP messages with attachments, but will be replaced by the more powerful MTOM/XOP mechanisms.
SwA is not a new specification, but rather a mechanism for using the existing SOAP and MIME facilities to perform the transmission of files using Web Services invocations.
The message structure of SwA is as follows:
JMS URI in SOAP/JMS Specification
I have read some articles and SOAP over JMS specification 1.0 (http://www.w3.org/TR/2008/WD-soapjms-20081121/).
Java Messaging Service (JMS) URI is used to describe the connection to a JMS provider, and access to a JMS destination. The JMS URI defines the format for designating connections and destination addresses used in the JMS.
The required particles in the JMS URI are the scheme name ("jms"), the variant identifier, and the portions. The three recognized variants ( above) are "jndi", "queue", and "topic". The portion identifies the JMS destination object in a way that is determined by the particular variant. Each variant may have query parameters specific to that variation.
One example JMS URI:
jms:jndi:destination?jndiInitialContextFactory= com.example.jndi.JndiFactory&priority=3
More information about JMS URI: http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-05.txt
Camel JMS is added by my mentor Willem Jiang:)
Camel JMS. http://camel.apache.org/jms.html
Java Messaging Service (JMS) URI is used to describe the connection to a JMS provider, and access to a JMS destination. The JMS URI defines the format for designating connections and destination addresses used in the JMS.
The required particles in the JMS URI are the scheme name ("jms"), the variant identifier, and the portions. The three recognized variants ( above) are "jndi", "queue", and "topic". The portion identifies the JMS destination object in a way that is determined by the particular variant. Each variant may have query parameters specific to that variation.
One example JMS URI:
jms:jndi:destination?jndiInitialContextFactory= com.example.jndi.JndiFactory&priority=3
More information about JMS URI: http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-05.txt
Camel JMS is added by my mentor Willem Jiang:)
Camel JMS. http://camel.apache.org/jms.html
订阅：
评论 (Atom)