Hi Oh and the SMX documentation on the website is unfortunately a mix between the old 3.x and 4.x version. The SMX is aware of that.
For the SMX 4.x docs then start with this link http://servicemix.apache.org/docs/4.4.0/index.html And forget all about JBI components in SMX, they are legacy components. And should only be used for people who is migrating from 3.x to 4.x and still want to use them. For any new users, use Camel instead. There is a blog with some thoughts from one of the SMX founders about the future of JBI http://gnodet.blogspot.se/2010/12/thoughts-about-servicemix.html On Fri, May 11, 2012 at 8:17 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > Welcome to the community. > > The best suggestion I can give you at this point is to: start with plain > Camel. > http://camel.apache.org/ > > Kick the tires with Camel, and get something up and running that > mostly does what you need. > > If you got 15 min to spare then read this intro article about Camel > http://java.dzone.com/articles/open-source-integration-apache > > That should help set the scene, and then dig in from there > > There is a number of Camel examples you can try out and read about > http://camel.apache.org/examples.html > > And if you got Maven experience then there is Maven archetype tooling > to quickly create new projects > http://camel.apache.org/camel-maven-archetypes.html > > > Then later you should look into SMX and how to deploy your application in SMX. > For example check out the SMX quick start guide > http://servicemix.apache.org/docs/4.4.0/quickstart/index.html > > > > On Fri, May 11, 2012 at 6:34 AM, Andrew Thorburn <nzi...@gmail.com> wrote: >> Ok, so I like the idea of ServiceMix, but attempting to dive in >> head-first seems to be a bad idea - there are just simply too many >> options! And the documentation seems to be a bit lacking in the areas >> I'm having trouble with. >> >> My ultimate goal is the following: >> >> One 'Service' which receives a SOAP message over HTTP and sends it on >> over JMS (possibly transformed via XSL first). >> >> One 'Service' which receives a SOAP message over HTTP, converts it >> (possibly via XSL) to a flat, fixed-length record, and then sends it >> over JMS. The response will also be a flat, fixed-length record, which >> will need conversion. But let's ignore that one for now - I'll be very >> happy if I can get the first one up and running. >> >> However, since I don't actually have access to the *real* end-points >> at the moment, what I need to do in the interim, to show that this >> will work for us, is to create a simple 'hello world'-type response >> for the above service. That is, I would create a JMS end-point in SM >> which responds with a fixed (or semi-fixed) SOAP message, ideally >> without writing any Java (XML is fine). >> >> So, where am I stuck with this? At the beginning. I see there are a >> number of different ways to deploy *stuff* to SM, but I can't find a >> good description of what the differences are between them. Should I be >> looking at creating a Blueprint? A Spring Module? An OSGi Module? A >> Spring/OSGi module? A Service Unit with Service Assemblies? Are some >> of these not applicable to what I'm trying to do? Are some of these, >> in fact, actually the same thing, or a sub-set of another thing? >> >> Now, having been looking at the documentation, I think that, once I've >> figured out what sort of deployment object I need to create, I would >> be using the servicemix-cxf-bc component, with a 'Consumer' endpoint, >> and probably a 'Provider' endpoint too. The Consumer would be what I >> would target from my application or from SoapUI, correct? And the >> provider would be what I would use as a mock end-point? >> >> This would a WSDL-first (well, preferably WSDL-only) SOAP deployment, >> as we will be calling out to a web service that someone else is >> providing over JMS. The WSDL does include a JMS binding, though I >> would still likely need to configure the target address and queue and >> so on. >> >> And to configure JMS I will need a separate configuration file, >> provided via the 'busCfg' option? I'm pretty sure that this JMS >> configuration will not need to specify a reply queue - just a >> destination queue, as ServiceMix/CXF will handle getting the reply >> automatically, correct? I believe that it will generate a queue to use >> for this request, and will include the name of that queue in the >> headers of the JMS message it sends. >> >> Assuming that's all correct, how do I actually generate a mock >> response with the provider? I assume I need to use some form of Camel >> Routing for that? >> >> I apologise for all the questions, but I just can't quite get my head >> around how SM is supposed to work, or where I need to look for >> answers. Should I actually be reading the FuseESB documentation, as >> that's based on SM? >> >> Many, many thanks, >> >> - Andrew Thorburn > > > > -- > Claus Ibsen > ----------------- > CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ -- Claus Ibsen ----------------- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
