converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 82:||Line 82:|
|Line 88:||Line 88:|
|Line 116:||Line 116:|
| * [http://www.w3.org/TR/2008/WD-soapjms-20081121/]
| * [[http://www.w3.org/TR/2008/WD-soapjms-20081121/]]
Google Summer of Code 2009 – Project Proposal
Implement the SOAP/JMS specification for CXF
Apache CXF is an open source services framework. CXF helps you build and develop services using frontend programming APIs, like JAX-WS. These services can speak a variety of protocols such as SOAP, XML/HTTP, Restful HTTP, or CORBA and work over a variety of transports such as HTTP, JMS or JBI.
SOAP over JMS offers an alternative messaging mechanism to SOAP over HTTP. SOAP over JMS offers more reliable and scalable messaging support than SOAP over HTTP.
SOAP over JMS specification(http://www.w3.org/TR/soapjms/) is aimed at a set of standards for the transport of SOAP messages over JMS (Java Message Service). The main purpose is to ensure interoperability between the implementations of different Web services vendors.
CXF does support SOAP over JMS, but it does not meet the current draft specification defined at http://www.w3.org/TR/soapjms/ and instead uses some proprietary formats, headers, url formats, etc. This project would update the SOAP/JMS support in CXF to be completely specification compliant.
Upon sucessful completion of the SOAP/JMS project, CXF will become one of the very first Open Source implementations of the SOAP/JMS specificiation.
The main concerns are as follows:
- The JMS calls that are made to construct and interpret SOAP/JMS messages in The SOAP/JMS Underlying Protocol Binding.
- The WSDL binding that is used to describe SOAP/JMS services in WSDL Usage.
- How SOAP over JMS uses the URI specification for JMS endpoints.
Make SOAP Over JMS pass the he soapjms test suite (http://dev.w3.org/2008/ws/soapjms/testcases/).
Project Timeline and Deliverables
April 20 to May 14
I'll be getting familiar with the related technologies like JMS, CXF. And these skills will help me to quickly get into the project implementation. I'm also planning to interact with my mentor and the other developers in the community to get much more familiar with the CXF and to get feedbacks from the developer community.
May 15 to May 22
I will review the design of SOAP over JMS which has been implemented in CXF and get the rough design after discussing and reviewing with my mentor and the developer community of CXF.
May 22 to June 6
I will implement the function how SOAP over JMS uses the URI specification for JMS endpoints, and test the URI specification for JMS endpoints.
In this period, I'll review the design of CXF and discuss the way I'm implementing the project with my mentor and the developers in the community.
June 7 to June 30
I will implement the construct and interpret of SOAP/JMS messages in The SOAP/JMS Underlying Protocol Binding, and write test cases.
In this period, I’ll dig deeply into the design of SOAP over JMS Binding and discuss the detailed implementation with my mentor and community.
July 1 to July 10
I will submit midterm evaluations.
July 11 to July 18
I will implement SOAP/JMS services in WSDL Usage. We use WSDL to indicate the use and control the operation of SOAP/JMS Underlying Protocol Binding.
After completion, I will start fixing bugs and writing the rest of the document.
July 19 to August 3
I will write an integration test for SOAP over JMS. Then I will update the documents for SOAP/JMS in CXF. If the test suite (http://dev.w3.org/2008/ws/soapjms/testcases/) is available, I'll work on getting it to pass. It may take one or two weeks.
August 4 to August 15
I will prepare samples and write enough sample guides for SOAP over JMS.
August 15 to August 20
I will finish all the tests and refinement with my mentor.
Figure 1 below shows a workflow diagram for one-way request messaging and two-way request and response messaging to a single receiver. Both JMS queue or JMS topic can be used for one-way request messaging, but JMS queue is the recommended approach because it results in better performance. For two-way request and response messaging, a JMS queue must be used, because JMS topic does not support point-to-point communication.
Figure 1. One-way request messaging, and two-way request and response messaging to a single receiver
Figure 2 shows a workflow diagram for one-way request messaging to multiple receivers. This messaging style resembles the JMS pub-sub structure, so a JMS topic must be used in this case.
Figure 2. One-way request messaging to multiple receivers
I am a second-year master’s student (Computer Software and Theory) at Beijing University of Aeronautics & Astronautics, China. I have been working on web-service related technologies for more than 18 months. And I have learned a lot of skills about web services, service-oriented architecture. I have learned a lot about axis and axis2.
Some significant highlights are:
- With my classmates, I have developed a web service engine
We improve the performance of SOAP processing by using “Dynamic Early Binding” and “XML Pull Parsing” technology.
Implement the Data Binding module of Dynamic Early Binding
Design and Implement the processing chain of SOAP messages for Reliable Messaging
- I have read some code about axis, axis2, mule, r-osgi, and learn the architectures of them. I will continue to focus on distributed OSGi.
- I am familiar with eclipse, osgi, and have about 3 years of Java experience.
- I am familiar with SOAP, WSDL, and Web Service.
I am very excited about this project. I have been involved into the design of the service engine. So I am very confident that I will be able to do an excellent job on this project.
I hope get this chance to contribute to the Open Source community.