-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Because SMX sets up an very fine ActiveMQ broker for you, using JMS via OSGi
services in Blueprint is as easy as:
<reference id="connectionFactory" interface="javax.jms.ConnectionFactory"/>
<bean id="jms" class="org.apache.camel.component.jms.JmsComponent">
<property name="connectionFactory" ref="connectionFactory"/>
</bean>
and then using "jms:queue:myQueue" or "jms:topic:myTopic" URIs as appropriate
in your Camel routes. Of course, if you have very specific needs for how JMS is
to be used, you may need to add some additional information to the Component
definition. You may also want to customize your ActiveMQ broker(s) to various
ends, but that's not difficult. All of the necessary machinery is provided for
you.
- ---
A. Soroka
Software & Systems Engineering :: Online Library Environment
the University of Virginia Library
On May 14, 2012, at 4:32 AM, Andrew Thorburn wrote:
> That turned out to be an awful lot simpler than I thought - once I
> started looking at Camel, it became really, really simple to get a
> class-less web service up and running (haven't tried JMS yet, but it
> can't be *that* much harder). I did encounter a couple of issues, but
> they're Camel issues, not SMX issues.
>
> Thanks,
>
> - Andrew Thorburn
>
> On Sun, May 13, 2012 at 1:32 AM, Andrew Thorburn <[email protected]> wrote:
>> Thanks guys - it's good to know what I should be avoiding, at the very
>> least. So OSGi Bundles/Blueprints it is then. Presumably this means
>> that I should be ignoring everything under
>> http://servicemix.apache.org/docs/4.4.0/jbi/components/index.html as
>> "legacy/deprecated", since they're all JBI-related? Which would mean
>> that I'd be using camel for setting up all the endpoints for the
>> webservices and whatnot?
>>
>> Thanks,
>>
>> - Andrew Thorburn
>>
>> On Fri, May 11, 2012 at 6:34 PM, PAC Kieffer Guillaume
>> <[email protected]> wrote:
>>> Hi,
>>>
>>> I started on ServiceMix one month ago, just some little hints to avoid
>>> losing time:
>>>
>>> As Claus said, be careful about SMX 3 and 4 documentation. You can go
>>> easily with the fuse doc, it is quite detailed and really provides you
>>> infos on ActiveMQ, Camel and ServiceMix.
>>>
>>> Forget about JBI SA/SU in SMX 4.4: Go with OSGi bundles and blueprint.
>>>
>>> If you have no clue about OSGi:
>>> http://www.theserverside.com/news/1363825/OSGi-for-Beginners
>>>
>>> Additionally take a look at Karaf which is the OSGi Container used in SMX:
>>> http://karaf.apache.org/
>>>
>>> Regards,
>>> Guillaume.
>>>
>>>
>>> -----Original Message-----
>>> From: Claus Ibsen [mailto:[email protected]]
>>> Sent: Friday, May 11, 2012 08:17
>>> To: [email protected]
>>> Subject: Re: Getting Started - self-contained SOAP over JMS sample?
>>>
>>> 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 <[email protected]> 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: [email protected]
>>> Web: http://fusesource.com
>>> Twitter: davsclaus, fusenews
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJPsXJHAAoJEATpPYSyaoIki+8IALMKBWKOBix3R6o89e9KtgLX
oXt5rsI67kY20cl4XQAdjqjKNWKZkKMZinfy4outeWJZHQuSxPmO/S8I6yIdl6Zq
0TvyE79DAlDj7V2C9aJR91WEJtzAwlcD+qsetYqfJ2aw9sHaG39vbfPdM9EYL/fM
BOS2XYtSXJpsudjRRqBsh+4JBjUQa3MlQPC4T5Gzch/ZtQr81W/xcErGJ0lBNWcL
6ZthAo0XPuh4O4DRnksrdkfEXojVmZddgotyv1GNo9Td1lN+opa+tuv46ysqfydx
FwSidNPOeA/+gJ1pHnwtE0oSiYX/FI6hN+oEqjttl3UI9aRo8MyNrYkn33RghOc=
=GaVu
-----END PGP SIGNATURE-----
