Thanls for your feedback Gert. Just a quick question, the SMX documentation is clear concerning the EJB proxy writing using JSR-181 component. In your previous response, you have noticed that it's better to use servicemix-cxf-se component in place of jsr-181 one. In the servicemix-cxf-se component documentation, I can see how to define bean proxy but not really how to define an EJB proxy : - should I use the Spring LocalStatelessSessionProxyFactoryBean to proxy my EJBs (I know that you have give my the answer on IRC but I have forgotten the CXF class to use, sorry :/) ? - how to define JNDI context lookup (provider URL, provider context factory, etc) ?
Thanks, Regards Le Tue, Sep 16, 2008 at 11:00:08AM +0200, Gert Vanthienen a écrit : > L.S., > > 1/ If you want to expose a service on the ESB (like servicemix-bean, > servicemix-jsr181, ...) with HTTP, you only need a http:consumer > endpoint. This can operate in InOut mode, so it will also send the > response back to the client. A SU always targets a single components, > so you can not have a single xbean.xml file with configuration for > multiple components. Starting with SMX 4, you will be able to use a > single XML file or bundle for the entire config though. BTW, you might > want to consider using servicemix-cxf-se instead of servicemix-jsr181 -- > new features are all going into the CXF components. > > 2/ The xbean.xml file is a Spring configuration file -- you can do > anything you can do in Spring there. The implementation looks correct > to me. You can also do the same thing with Camel by the way -- Camel > does have JPA and hibernate components which might make the task a bit > easier. > > 3/ If you want to expose an existing service over a new protocol (like > using JMS instead of HTTP/SOAP), you can just configure a new endpoint > to listen on a JMS queue and send the messages to your existing service > endpoint. This doesn't need to be configured in the same SA though -- > that's entirely up to you. If you want to keep the existing SA running > at all time, you can just create a new SA that adds the endpoint > configuration. Changing protocols is too much of a change to do through > JMX, but you can use e.g. a PropertyPlaceholderConfigurer (remember that > the xbean.xml file is just a Spring file) and restart the SU through JMX > to reload the configuration from the properties file. Lars just added a > blog entry about this last week > (http://lhein.blogspot.com/2008/09/servicemix-and-flexible-endpoint.html) > > 4/ If you package it as SAs in the hotdeploy directory, you'll end up > with a full ServiceMix installation at the client side. This will allow > you and them to start adding other SA and just use it as a plain > ServiceMix install. With the lightweight mode, you can deliver a > solution that only contains what they need, but it will be harder for > them (or you) to use it for anything else. Personally, I would > recommend you to just package your SA in the SMX distro and deliver > that. For SMX4, we will no longer support the lightweight mode (with a > static configuration file). > > Regards, > > Gert > > Jean-Baptiste Onofré wrote: >> Hi all, >> >> I have begin to implement several SU and SA and some questions through in my >> mind :) >> I have made some lookup on the webside and on internet but I haven't really >> found the complete answer. >> >> Well, that's the questions : >> >> 1/ Existing service publication >> Currently, I have several existing services implemented with EJBs. I would >> like to "publish" theses services using ServiceMix. >> For exemple, is it a good way to implement like this : >> - SU using servicemix-http component (in consumer mode) : this SU listen >> client requests on HTTP/SOAP >> - SU using servicemix-jsr181 component : this SU is a proxy to my existing >> EJB >> - SU using servicemix-http component (in producer mode) : this SU feedback >> the service result to the client >> - SA which package SUs >> Is this implementation correct or should I use the lightweight mode (with a >> servicemix.xml file) ? >> In the case that my existing EJBs don't take "simple" method arguments, >> should I create a bean to encapsulate the EJB call (for exemple, I have EJBs >> that take ValueObject (VO) in arguments and not simple scalar types) ? >> If I have right understood, a SU can have only one target component, so it's >> not possible to define usage of servicemix-http and service-jsr181 components >> in the same SU xbean.xml. Correct ? >> >> 2/ Create service beans >> Currently, I have a database stored procedure which performs service. I >> would like to expose this stored procedure. I need to create a "frontend" >> bean. >> Is this implementation correct : >> - SU using servicemix-http component (in consumer mode) : this SU listen >> client requests on HTTP/SOAP >> - SU using servicemix-bean component : Spring implementation bean which call >> others Spring Beans (like Hibernate DAO) to call my stored procedure >> - SU using servicemix-jms component : this SU push the stored procedure >> result to a JMS queue >> Is this implementation correct ? >> Is it possible to use a Spring ApplicationContext XML like definition in >> xbean.xml file ? >> >> 3/ Agile services >> Currently, I create my SAs which define SUs. For exemple, I have provided >> consumer SU using servicemix-http component. This is correct this time, but >> for exemple, in the future, a new customer wouldn't call my service using >> HTTP/SOAP but using JMS. I can do it using servicemix-jms component based SU >> but I need to rebuild my SA with the new SU consumer. >> Is it possible to dynamically change an existing SA (by configuration, by >> JMX or by smx-arch) to avoid to provide a new SA ? >> >> 4/ Simplify the ServiceMix and business services delivery >> To simplify ServiceMix/Business Services delivery and installation to my >> customers, I would like to pre-package the ESB. >> I wonder two ways to do it : >> - I take a default ServiceMix tar.gz and add my SAs in the hot-deploy >> directory >> - I create a lightweight mode using servicemix.xml which define my services >> logic >> What's the best solution ? >> >> Thanks in advance for your feedback. >> >> Regards >> -- Jean-Baptiste Onofré (Nanthrax) BuildProcess/AutoDeploy Project Leader http://buildprocess.sourceforge.net [EMAIL PROTECTED] PGP : 17D4F086
