[jboss-user] [JBoss Web Services Development] - CXF jms integration

[Jim Ma]

Jim Ma [http://community.jboss.org/people/jim.ma] replied to the discussion

"CXF jms integration"

To view the discussion, visit: http://community.jboss.org/message/540295#540295

--------------------------------------------------------------
> Hi Jim,
> I've taken a look at what you did in your jms-integration branches and have some questions / concers I'd like to discuss here. First of all let me summarize what you've done, so we're sure that we're all on the same page.
> You basically added a deployment descriptor (jbossws-endpoints.xml) parsing that produces some new metadata in SPI (org.jboss.wsf.spi.metadata.endpoints.EndpointsMetaData). Those are later attached to the Deployment and used by EndpointsDescriptorsDeploymentAspect (cxf stack) to produce an instance of org.jboss.wsf.spi.metadata.endpoints.AbstractEndpointsDeployment (namely org.jboss.wsf.stack.cxf.deployment.CXFEndpointsDeployment), with a spring configuration file generated from the metadata. CXFEndpointsDeployment is later deployed by the KernelDeploymentDeployer and is responsible for generating the CXF Bus through the BusHolder, creating a new spi endpoint and adding it to the registry. Before handing over to the KernelDeploymentDeployer, the WSEndpointsRealDeployer (container integration) sets the proper depedencies for ensuring the bean is deployed after any JMS destination bean attached to the current deployment unit.
> 
Thanks for the comments and ideas. Yes.  We are in the same page .
> 
> * jbossws-endpoints.xml: generally  speaking, I would allow users to avoid providing that in most cases.  AFAICS, the reason for that file is just in getting the information on  which jms destinations are to be used for the endpoints included in the  deployment. I think this can also be specified through a user provided  jboss-cxf.xml, hence we need to allow for that too. 
> 
There are following reasons I named it to general jbossws-endpoint.xml and not jms-endpoints.xml:
a) Considering our spi framework and IL architecture, we can only creat the deployer in IL . That means the deployer is stack neutral and it should not only parse/deploy the stack specific deployment descriptor : for example jboss-cxf.xml.

b) There are other transports supported in CXF : invm, jbi.  We can extend this file to support them .  So it is only for jms transport .

c) Combine our features (eg, jaxbintro configuration xml) and  jbossws-endpoint.xml to generated CXF deployment configuraiton.   

> Moreover, something  else we should probably evaluate implementing (perhaps in CXF?) is an  annotation for setting those destinations on the endpoint class  (@JMSTransport or something like that). That said, yes, a user might  still want to use xml for providing that info, in which case a  configuration file like jbossws-endpoints.xml is fine. 
> 
Good point . This is my fourth reason to name it jbossws-endpoints.xml.  The jms configuration can be defined in wsdl file, so user only need to specify the endpoint class name to deploy jms endpoints in CXF.   We also need use this to enable the soap over jms in CXF . 

> * new SPI metadata: besides the naming not completely convincing me, I  think the few info we need (jms destination addresses currently) should  live at the Endpoint level, not higher than that and separated from that  as they currently are in jms-integration branch. Jim, did you evaluate  having a hierarchy for the SPI Endpoint (with the current one becoming  HttpEndpoint and a new JMSEndpoint having the destinations' info)? 
> 

I evaluated to make new SPI metadata to extend the current SPI Endpoint.  But I did not find benifit from it, as our DeploymentAspects was intended to process the SPI HttpEndpoint. It can
not be reused to process JMSEndpoint too.  Now I took the new SPI metadata as flag to dispatch the jms endpoint deployment . New created DeploymentAspect to deploy the jms endpoint  and old DeploymentAspects to deploy  http endpoint .
> Still  on this topic, we might probably create the SPI JMSEndpoint at the same  time as the Http one (currently the WSDeploymentBuilder::build seems to  me to be creating the Deployment only, while the Endpoint is actually  created later by the CXFEndpointsDeployment). The CXFEndpointsDeployment  should probably just do the endpoint registration (perhaps even that  can unified..?), with already existing spi endpoints
> 
This is because the jms SPI Endpoint does not need the exsiting DeploymentAspect to process, and jms SPI Endpoint is created just for registry, and it's in different deploy flow.  Do you see any other points we need to unify  and reuse DeploymentAspect ?
> * WSEndpointsReadDeployer: while I was not able to think about this  solution before for the destinations dependency management, what I don't  like here is that it's not part of our DA group. Where does it run in  the deployers' chain? can we unify things here (make it a DA)?
It is running after the last  DeploymentAspectDeployer and before KernelDeploymentDeployer. It's not possible to unify it to a DA.  It needs the As dependency to create a BeanMetaData.  
> * do you already know whether the proposed architecture is going  to work with CXF 2.3 SOAP-over-JMS-1.0 support too ( http://cxf.apache.org/docs/soap-over-jms-10-support.html http://cxf.apache.org/docs/soap-over-jms-10-support.html)?
Yes. It supports the soap-over-jms. The current deployer architcture supports to deploy the endpoint class with wsdl file .
 I also uses the "soap-over-jms spec" style jms address to reprents the endpoint address for spec "alignment" .

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/540295#540295]

Start a new discussion in JBoss Web Services Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&containerType=14&container=2047]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100430/824d7e36/attachment.html