Hi,
I have to paste the proposal in this email since apache wiki is
unreachable today, I will put the proposal on apache wiki when the wiki
server is back.
Any suggestion for this proposal is appreciated.
Cheers
Freeman
=== Summary of Requirements Being Addressed ===
Allow JBI service units to be written using CXF with JAX-WS api and
deployed to any JBI Container.
=== Summary of Proposed Solution ===
To enable CXF service provider or consumer being deployed into JBI
container, a CXF Service Engine should be implemented. CXF service
Engine should be a JBI service engine which implement all standard JBI
component interface and JBI component lifecycle interface, also CXF
Service Eninge itself should be a container which CXF service provider
or consumer can be deployed into. To do this, a new JBI transport
should be implemented. JBI transport should use JBI normalized message
api to send or receive normalized messages. Message sent to NMR
transport should be only plain xml payload, no soap tag should be
included in the message.
CXF Service engine should work with binding component provided by any
JBI container, by this way, multiple transport could be supported.
Also, a configurable CXF binding component which can support
multi-transport should be implemented, by means of the deployment
descriptor of service unit which will be deployed into CXF binding
component, proper transport should be selected on the fly.
=== Changes and/or Additions to APIs and/or Internal Classes ===
To implement CXF Service Engine, according to JBI specification, several
class should be added
public class CXFServiceEngine implements ComponentLifeCycle, Component {}
public class CXFBootstrap implements Bootstrap {}
public class CXFServiceUnitManager implements ServiceUnitManager {}
public class ComponentClassLoader extends URLClassLoader {}
and all service unit lifecycle change should delegate to
public class CXFServiceUnit{}
To implement JBI transport, according to CXF transport api, several
class should be added
public class JBITransportFactory implements ConduitInitiator,
DestinationFactory
public class JBIConduit implements Conduit
public class JBIDestination implements Destination
To implement configurable multi-transport supported CXF binding
componet, should add class
public class CXFBindingComponent implements ComponentLifeCycle, Component {}
public class CXFBCBootstrap implements Bootstrap {}
=== Changes to Configuration ===
A JBITransport class and namespace mapping should be added to
bus-extensions.xml
<extensions xmlns="http://cxf.apache.org/bus/extension";>
<extension class="org.apache.cxf.jbi.transport.JBITransportFactory"
deferred="true">
<namespace>http://cxf.apache.org/transports/jbi</namespace>
<namespace>http://cxf.apache.org/transports/jbi/configuration</namespace>
</extension>
</extensions>
=== Demos Impact ===
1. demo to show internal CXF consumer and internal CXF provider of JBI
container
The CXF Service Engine will start both consumer and provider Serivce
Units in the assembly. The consumer is coded to wait for the providers
endpoint to activate. Once the provider endpoint has activated, the
consumer sends xml payload messages to the provider. These messages are
taken by the CXF JBI transport, wrapped in a NormalizedMessage and sent
via the NMR to the service provider. The responses are sent back in a
similar fashion. greetMe use InOut MEP, sayHi use InOnly MEP. This demo
work with both servicemix and OpenESB to illustrate CXF service engine
can work with any JBI compatible container.
2. demo to show internal CXF provider and external CXF consumer with
different transport
A standalone CXF client(as consumer) invoke servicemix soap binding
service unit using soap/http, the servicemix soap binding service
route this request to CXF service unit using XML/NMR specified by
JBI. Here servicemix soap binding service unit play the role as a
router, connecting CXF service consumer and provider with different
transport and different binding.
Also, this demo show CXF service engine can work with third party
binding component.
3. demo to show internal CXF consumer and external CXF provider with
different transport
A CXF client service unit(as consumer) invoke servicemix JMS binding
service unit using XML/NMR, the servicemix JMS binding service route
this request to CXF standalone server using XML/JMS. Here servicemix JMS
binding service unit play the role as a router, connecting CXF service
consumer and provider with different transport.
4. demo to show external CXF consumer and external CXF provider with
different transport
A CXF client (as consumer) invoke servicemix soap binding service unit
using SOAP/HTTP, the servicemix soap binding service unit route this
request to servicemix jms binding service unit using XML/NMR, then
servicemix jms binding service unit invoke CXF server(as provider) using
XML/JMS. Here servicemix JMS binding component and servicemix http
binding play the role as a kind of transformer, connecting CXF service
consumer and provider with different transport.
5. demo to show CXF configurable multi-transport binding component can
handle request or reponse with different transport(HTTP/CORBA/JMS
and so on) according to the
deployment descriptor of the service unit which is deployed into
it.
=== Documentation Impact ===
Add document to describe how to develop CXF service unit and deploy it
into CXF service engine.
--
Freeman Fang
Software Engineer
IONA Asia Pacific Software Development Center
No.2 Floor A Unit Information Center
Zhongguancun Software Park Haidian District,
Beijing, P.R.China
Tel.: +86-10-82825151 - ex. 551
Fax: +86-10-8282-5210
[EMAIL PROTECTED]
-------------------------------------------------
Making Software Work Together TM
