You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Gert Vanthienen <ge...@skynet.be> on 2007/05/11 11:26:11 UTC
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Guarav,
Is this the only change that is necessary in the XSL file to switch to
version 2.0?
For what the saxon dependency is concerned:
The previous version of the page used the
servicemix-lwcontainer-service-unit archetype to create the
bridge-xslt-su. I have changed that to use
servicemix-saxon-xslt-service-unit and that one should automatically put
the correct dependency in there to start with.
Gert
gauravsonline wrote:
> Thank you so much. Would like to suggest two more small changes, though not
> important but it would make the things more concrete.
>
> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which should
> be "2.0". If not the case then servicemix gives a warning that "saxon engine
> is 2.0 but the stylesheet version is 1.0".
>
> Secondly, the saxon dependency has to be added in the pom.xml file for XSLT
> SU.
>
> <dependencies>
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-saxon</artifactId>
> <version>3.1-incubating-SNAPSHOT</version>
> </dependency>
> </dependencies>
>
> Hope this makes sense. As of know I just have these many changes only.
>
> Also thanks for ur reply on the second use case. I will now work on that.
>
> Regards....
> Gaurav
>
>
> Gert Vanthienen wrote:
>
>> L.S.,
>>
>>
>> First of all, I have changed
>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>> Could you check if all necessary changes have been done? This page will
>> get replicated to the main site after a while...
>>
>> For your second use case: if you do not need any transformations on the
>> message content, you can create a service assembly with two service units:
>> - one SU based on servicemix-jms, defining the JMS consumer endpoint to
>> read messages from a JMS queue (cfr.
>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>> configuration options)
>> - the other SU based on servicemix-http, defining the HTTP provider
>> endpoint which points to your webservice (cfr.
>> http://incubator.apache.org/servicemix/servicemix-http.html for
>> configuration options)
>>
>> Beware that the service/endpoint name of you HTTP provider endpoint
>> should match the names defined in your webservice's WSDL. You can
>> either use the same service/endpoint name on your JMS endpoint or use
>> the targetService/targetEndpoint attributes to do the routing.
>>
>>
>> Regards,
>>
>> Gert
>>
>> gauravsonline wrote:
>>
>>> HI,
>>> Thanks for your help. Actualy just now I resolved the problem.
>>> The problem was in the xslt-su. The archtyope by default generates the
>>> servicemix.xml file and in the example code its xbean.xml file. So just
>>> renaming the file from servicemix.xml to xbean.xml. The saxon dependency
>>> was
>>> ok.
>>>
>>> Now the next step is to read the messages from the queue and call a web
>>> service. Could you please help??
>>>
>>> Also I would like to request the moderator if they could update this
>>> thing
>>> at :
>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>
>>> in the "XSLT SU" section, as this has costed me two days to resolve.
>>>
>>> Thanks all for your help!
>>>
>>
>>
>
>
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by Gert Vanthienen <ge...@skynet.be>.
L.S.,
Sorry, I don't know how to implement that in ServiceMix. It'll be
interesting for me as well to hear how this can be done...
Regards,
Gert
gauravsonline wrote:
>
> ...
>
> Now, suppose my queue receives a message in the object form of type
> "Message" and I want to typecast it to the required type. Then, after
> that I will invoke a webservice and pass that object as thep parameter for
> the operation (think this would be RPC call). e.g. I am posting messages
> of type class A in the queue (here i will use jms producer), then jms
> consumer will retrieve the messages of type class A. No some how I want
> the onMessage(Message msg) method to be trigerred. The parameter msg will
> be type casted to type class A and then I will call a webservice (i think
> it would be RPC using service stubs) which takes this obect of type A as a
> parameter.
>
> I was looking at the Active MQ implemenattion of it. have cerating
> queries related to it.
>
> 1. How can I invoke the onMessage() method throgh the jms consumer service
> unit?
> 2. How can i invoke the jsr-181 service from inside the onMessage()
> method?
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10620877
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Hi Gnodet,
Yes thats what I did. Created a jms-provider and a http-consumer in one SA
(i have used the bridge-protocol example) and jms-consumer with the
endpoints of the target service in the other SA. So the flow is like I post
the xml messsage thru a client to the http-consumer and the message is
pushed in the queue thru the jms-producer. Now the jms-consumer pulls the
message out and calls the web service. This is basically a routing of the
message, if I am not wrong.
Now, the problem is how can i push a message object into the queue? As you
responded, that the mashaling BC's are still not released so I will have to
get the source from the SVN directly. Let me see if I can do something with
it.
Thanks...
Gaurav
gnodet wrote:
>
> If you know how to send an HTTP request to a JMS queue,
> doing the opposite is quite easy. You just need to exchange
> the endpoint roles so that you will end up with an jms consumer
> and an http provider.
>
> Now, if you really need to send an object, you should use the new
> endpoints
> that have not been released yet (download the svn sources and build the
> trunk
> version). The servicemix-jms BC defines two new endpoints
> <jms:consumer />
> and
> <jms:provider />
> Take a look at the code, and you will see the ConsumerMarshaler and
> ProviderMarhsaler
> interfaces that you can implement to override the transformation from JMS
> <-> JBI.
> You will be able to put your custom marhsaling code there.
>
> On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
>>
>>
>> Hi,
>>
>> Thanks for your response.
>>
>> gnodet wrote:
>> >
>> > Now, if you want to call an external HTTP service, you need to link the
>> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
>> > in the servicemix distribution (and the turorial on the web site), they
>> > are
>> > really related to that (though it's from HTTP to JMS, but the same
>> things
>> > apply).
>> >
>>
>> This part I have done already. I am able to post an xml message to the
>> queue
>> and called a web service.
>>
>> Now, the second part of it is to post the message object.
>>
>> gnodet wrote:
>> >
>> > Which onMessage are you talking about ?
>> > Currently, the JMS BC mainly expects an xml and you can route the
>> > exchange to jsr181 which will unmarshall it and call the pojo.
>> > If you want to use a java object in the JMS message, you will have
>> > to marshal it to xml on the BC side.
>> >
>>
>> We know from J2EE that an MDB has a onMessage() method which is triggered
>> when a message is pushed into the queue. We can have the business logic
>> in
>> this method for calling the target web service. My requiremnt is to
>> implement the same thing using servicemix. But till now I just know about
>> how to push the xml message in the jms of servicemix using http-consumer
>> and
>> then using then jms-provider retrieveing the messages from the queue and
>> invoking the jsr-181 web service.
>>
>> I hope this makes the picture much clear.
>>
>> I have read that we can convert the message object into xml. This comes
>> built-in with activemq. But how to create the SU for it. I also think of
>> doing a transormation from messgae object to xml. But I do not know how
>> to
>> do it. Plz help...
>>
>> Thanks...
>>
>>
>> gnodet wrote:
>> >
>> > Which onMessage are you talking about ?
>> > Currently, the JMS BC mainly expects an xml and you can route the
>> > exchange to jsr181 which will unmarshall it and call the pojo.
>> > If you want to use a java object in the JMS message, you will have
>> > to marshal it to xml on the BC side.
>> > If you don't have a real need for using a java object inside the JMS
>> > message,
>> > I'd really recommand using xml if possible inside ServiceMix.
>> > Now, if you want to call an external HTTP service, you need to link the
>> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
>> > in the servicemix distribution (and the turorial on the web site), they
>> > are
>> > really related to that (though it's from HTTP to JMS, but the same
>> things
>> > apply).
>> >
>> > On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
>> >>
>> >>
>> >> Hi Gert,
>> >>
>> >> Thanks for the help. With little effort I got evertything working at
>> my
>> >> end.
>> >> Moreover the resolution was also very precise and easy to understand.
>> >>
>> >> Now, suppose my queue receives a message in the object form of type
>> >> "Message" and I want to typecast it to the required type. Then,
>> after
>> >> that
>> >> I will invoke a webservice and pass that object as thep parameter for
>> the
>> >> operation (think this would be RPC call). e.g. I am posting messages
>> of
>> >> type
>> >> class A in the queue (here i will use jms producer), then jms consumer
>> >> will
>> >> retrieve the messages of type class A. No some how I want the
>> >> onMessage(Message msg) method to be trigerred. The parameter msg will
>> be
>> >> type casted to type class A and then I will call a webservice (i think
>> it
>> >> would be RPC using service stubs) which takes this obect of type A as
>> a
>> >> parameter.
>> >>
>> >> I was looking at the Active MQ implemenattion of it. have cerating
>> >> queries
>> >> related to it.
>> >>
>> >> 1. How can I invoke the onMessage() method throgh the jms consumer
>> >> service
>> >> unit?
>> >> 2. How can i invoke the jsr-181 service from inside the onMessage()
>> >> method?
>> >>
>> >> Can I implement such a scenario with in service mix end-to-end. Plz
>> >> guide.
>> >>
>> >> Thanks.
>> >>
>> >>
>> >>
>> >> Gert Vanthienen wrote:
>> >> >
>> >> > L.S.,
>> >> >
>> >> > OK, so you have implemented and deployed a web service using the
>> >> JSR-181
>> >> > component. This results in an internal endpoint for
>> ServiceMix. This
>> >> > means that the service is accessible within the ESB itself. If you
>> >> want
>> >> > to make the service available to the outside world, you'll have to
>> add
>> >> an
>> >> > external endpoint (e.g. a JMS or HTTP consumer) for the same
>> >> service. So
>> >> > if you just want to route between your JMS queue and the JSR-181
>> >> endpoint,
>> >> > you create only one JMS consumer endpoint with the same service name
>> to
>> >> > connect the external endpoint with the internal endpoint and you
>> don't
>> >> > need any of the intermediary HTTP endpoint definitions. If you want
>> to
>> >> > have multiple external endpoints (e.g. file poller, http consumer,
>> ftp
>> >> > poller, ...), you can create them and specify
>> >> targetService/targetEndpoint
>> >> > attributes to specify the routing to the internal endpoint.
>> >> >
>> >> > In your example, you've also added an HTTP provider endpoint. This
>> is
>> >> a
>> >> > way to make an external web service available in the ESB (thus
>> >> resulting
>> >> > in another internal endpoint) and that's where your code sample
>> fails
>> >> > (duplicate internal endpoint names).
>> >> >
>> >> > Does this clarify the internal/external endpoint issue for you?
>> >> >
>> >> > Gert
>> >> >
>> >> > gauravsonline wrote:
>> >> >>
>> >> >> Hi Gert,
>> >> >>
>> >> >> I have created the consumer-jms-su and the provider-http-su and SA
>> for
>> >> it
>> >> >> (call it as SA_retrieve). Before that I would like to explain what
>> I
>> >> have
>> >> >> done till now. I have created the bridge example in SMX for sending
>> >> the
>> >> >> messages to the queue. I have also created a JSR 181 web service
>> for
>> >> >> echoing some message with http-consumer-su and
>> jsr181-wsdl-first-su.
>> >> >>
>> >> >> I am able to deploy the SA_retrieve and the bridge example. I am
>> able
>> >> to
>> >> >> send messages to the queue and then the SA_retrieve is able to
>> >> retrieve
>> >> >> the messages. The message is displyed in the SMX console and queue
>> >> >> encount value is checked from JMX console.
>> >> >>
>> >> >> Now in order to make them all work together, I am deploying the SA
>> in
>> >> >> order like this bridge example, echo WS, and then the SA_retrieve
>> WS.
>> >> >> When I deploy the SA_retrieve WS it throws exceptions saying that
>> the
>> >> >> "EchoService" service name and the "EchoPort" endpoint are already
>> >> >> registered to soem internal service. As you told to give the same
>> >> service
>> >> >> name and the endpoint as in the wsdl. But this is creating problem.
>> >> For
>> >> >> your reference I am attaching the configuration of all the SA for
>> your
>> >> >> refence:
>> >> >>
>> >> >> SA_retrieve:
>> >> >> =========
>> >> >> consumer-jms-su: xbean.xml
>> >> >> ----------------------------------
>> >> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
>> >> >> xmlns:test="http://motorola.com/test/test_amq">
>> >> >>
>> >> >> <!-- START SNIPPET: consumer -->
>> >> >> <jms:endpoint service="test:MyConsumerService"
>> >> >> endpoint="jms"
>> >> >> role="consumer"
>> >> >> destinationStyle="queue"
>> >> >> jmsProviderDestinationName="bridge.output"
>> >> >> connectionFactory="#connectionFactory"
>> >> >>
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> defaultOperation="test:Echo" />
>> >> >> <!-- END SNIPPET: consumer -->
>> >> >>
>> >> >> <jms:endpoint service="test:MyConsumerService"
>> >> >> endpoint="jms+soap"
>> >> >> targetInterfaceName="test:MyConsumerInterface"
>> >> >> role="consumer"
>> >> >> destinationStyle="queue"
>> >> >> jmsProviderDestinationName="bridge.output"
>> >> >> connectionFactory="#connectionFactory"
>> >> >> soap="true"
>> >> >>
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> />
>> >> >>
>> >> >> <bean id="connectionFactory"
>> >> >> class="org.apache.activemq.ActiveMQConnectionFactory">
>> >> >> <property name="brokerURL" value="tcp://localhost:61616" />
>> >> >> </bean>
>> >> >> </beans>
>> >> >>
>> >> >> provider-http-su: xbean.xml
>> >> >> ----------------------------------
>> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> >> xmlns:test="http://motorola.com/test/test_amq">
>> >> >>
>> >> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
>> >> >> service="echo:EchoService"
>> >> >> endpoint="EchoPort"
>> >> >> role="provider"
>> >> >> locationURI="http://localhost:9999/echo/"
>> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> soap="true"
>> >> >> wsdlResource="classpath:echo.wsdl"/>
>> >> >>
>> >> >> </beans>
>> >> >> Actually I have kept the wsdl at the path, so its that way.
>> >> >>
>> >> >> JSR181 WS:
>> >> >> ========
>> >> >> jsr181-su: xbean.xml
>> >> >> --------------------------
>> >> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
>> >> >>
>> >> >> <classpath>
>> >> >> <location>.</location>
>> >> >> </classpath>
>> >> >>
>> >> >> <jsr181:endpoint
>> >> pojoClass="com.motorola.test.echo.EchoServiceImpl"
>> >> >> wsdlResource="classpath:echo.wsdl"
>> >> >> style="document" />
>> >> >>
>> >> >> </beans>
>> >> >>
>> >> >> jsr181-su: echo.wsdl
>> >> >> -------------------------
>> >> >> <?xml version="1.0" encoding="UTF-8"?>
>> >> >> <wsdl:definitions
>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>> >> >> xmlns:tns="http://motorola.com/test/echo"
>> >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
>> >> >> targetNamespace="http://motorola.com/test/echo">
>> >> >> <wsdl:types>
>> >> >> <xsd:schema
>> >> >> targetNamespace="http://motorola.com/test/echo">
>> >> >> <xsd:element name="Echo">
>> >> >> <xsd:complexType>
>> >> >> <xsd:sequence>
>> >> >> <xsd:element name="in"
>> >> >> type="xsd:string"></xsd:element>
>> >> >> </xsd:sequence>
>> >> >> </xsd:complexType>
>> >> >> </xsd:element>
>> >> >> <!--<xsd:element name="EchoResponse">
>> >> >> <xsd:complexType>
>> >> >> <xsd:sequence>
>> >> >> <xsd:element
>> >> name="out"
>> >> >> type="xsd:string"/>
>> >> >> </xsd:sequence>
>> >> >> </xsd:complexType>
>> >> >> </xsd:element>-->
>> >> >> </xsd:schema>
>> >> >> </wsdl:types>
>> >> >>
>> >> >> <wsdl:message name="echoRequest">
>> >> >> <wsdl:part element="tns:Echo" name="in"/>
>> >> >> </wsdl:message>
>> >> >> <wsdl:message name="echoResponse">
>> >> >> <wsdl:part type="xsd:boolean" name="out"/>
>> >> >> </wsdl:message>
>> >> >>
>> >> >> <wsdl:portType name="EchoPortType">
>> >> >> <wsdl:operation name="echo">
>> >> >> <wsdl:input message="tns:echoRequest"/>
>> >> >> <wsdl:output message="tns:echoResponse"/>
>> >> >> </wsdl:operation>
>> >> >> </wsdl:portType>
>> >> >>
>> >> >> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
>> >> >> <soap:binding style="document"
>> >> >> transport="http://schemas.xmlsoap.org/soap/http"/>
>> >> >> <wsdl:operation name="echo">
>> >> >> <soap:operation
>> >> >> soapAction="http://motorola.com/test/echo/echo"/>
>> >> >> <wsdl:input>
>> >> >> <soap:body use="literal"/>
>> >> >> </wsdl:input>
>> >> >> <wsdl:output>
>> >> >> <soap:body use="literal"/>
>> >> >> </wsdl:output>
>> >> >> </wsdl:operation>
>> >> >> </wsdl:binding>
>> >> >>
>> >> >> <wsdl:service name="EchoService">
>> >> >> <wsdl:port binding="tns:EchoBinding"
>> name="EchoPort">
>> >> >> <soap:address
>> >> >> location="http://0.0.0.0:9999/echo"/>
>> >> >> </wsdl:port>
>> >> >> </wsdl:service>
>> >> >> </wsdl:definitions>
>> >> >>
>> >> >> consumer-http-su: xbean.xml
>> >> >> ---------------------------------
>> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> >> xmlns:test="http://motorola.com/test/echo">
>> >> >>
>> >> >> <http:endpoint service="test:EchoService"
>> >> >> endpoint="EchoPort"
>> >> >> role="consumer"
>> >> >> locationURI="http://0.0.0.0:9999/echo/"
>> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> soap="true" />
>> >> >>
>> >> >> </beans>
>> >> >>
>> >> >> So I am using the same values for http:endpoint
>> >> >> service="test:EchoService", endpoint="EchoPort" in my echo service
>> >> >> consumer-http-su and in the provider-http-su of SA_reteive SA which
>> is
>> >> >> retrieving the messages. This duplicay is giving the problem.
>> >> >>
>> >> >> Please help, as I am not able to figure out to define the proper
>> >> routing
>> >> >> of the messages beteen SU and across SA.
>> >> >>
>> >> >> Regards,
>> >> >> Gaurav
>> >> >>
>> >> >>
>> >> >> Gert Vanthienen wrote:
>> >> >>>
>> >> >>> Guarav,
>> >> >>>
>> >> >>> Is this the only change that is necessary in the XSL file to
>> switch
>> >> to
>> >> >>> version 2.0?
>> >> >>>
>> >> >>> For what the saxon dependency is concerned:
>> >> >>> The previous version of the page used the
>> >> >>> servicemix-lwcontainer-service-unit archetype to create the
>> >> >>> bridge-xslt-su. I have changed that to use
>> >> >>> servicemix-saxon-xslt-service-unit and that one should
>> automatically
>> >> put
>> >> >>> the correct dependency in there to start with.
>> >> >>>
>> >> >>> Gert
>> >> >>>
>> >> >>> gauravsonline wrote:
>> >> >>>> Thank you so much. Would like to suggest two more small changes,
>> >> though
>> >> >>>> not
>> >> >>>> important but it would make the things more concrete.
>> >> >>>>
>> >> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0",
>> which
>> >> >>>> should
>> >> >>>> be "2.0". If not the case then servicemix gives a warning that
>> >> "saxon
>> >> >>>> engine
>> >> >>>> is 2.0 but the stylesheet version is 1.0".
>> >> >>>>
>> >> >>>> Secondly, the saxon dependency has to be added in the pom.xml
>> file
>> >> for
>> >> >>>> XSLT
>> >> >>>> SU.
>> >> >>>>
>> >> >>>> <dependencies>
>> >> >>>> <dependency>
>> >> >>>> <groupId>org.apache.servicemix</groupId>
>> >> >>>> <artifactId>servicemix-saxon</artifactId>
>> >> >>>> <version>3.1-incubating-SNAPSHOT</version>
>> >> >>>> </dependency>
>> >> >>>> </dependencies>
>> >> >>>>
>> >> >>>> Hope this makes sense. As of know I just have these many changes
>> >> only.
>> >> >>>>
>> >> >>>> Also thanks for ur reply on the second use case. I will now work
>> on
>> >> >>>> that.
>> >> >>>>
>> >> >>>> Regards....
>> >> >>>> Gaurav
>> >> >>>>
>> >> >>>>
>> >> >>>> Gert Vanthienen wrote:
>> >> >>>>
>> >> >>>>> L.S.,
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> First of all, I have changed
>> >> >>>>>
>> >>
>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>> >> >>>>> Could you check if all necessary changes have been done? This
>> page
>> >> >>>>> will
>> >> >>>>> get replicated to the main site after a while...
>> >> >>>>>
>> >> >>>>> For your second use case: if you do not need any transformations
>> on
>> >> >>>>> the
>> >> >>>>> message content, you can create a service assembly with two
>> service
>> >> >>>>> units:
>> >> >>>>> - one SU based on servicemix-jms, defining the JMS consumer
>> >> endpoint
>> >> >>>>> to
>> >> >>>>> read messages from a JMS queue (cfr.
>> >> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>> >> >>>>> configuration options)
>> >> >>>>> - the other SU based on servicemix-http, defining the HTTP
>> provider
>> >> >>>>> endpoint which points to your webservice (cfr.
>> >> >>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>> >> >>>>> configuration options)
>> >> >>>>>
>> >> >>>>> Beware that the service/endpoint name of you HTTP provider
>> endpoint
>> >> >>>>> should match the names defined in your webservice's WSDL. You
>> can
>> >> >>>>> either use the same service/endpoint name on your JMS endpoint
>> or
>> >> use
>> >> >>>>> the targetService/targetEndpoint attributes to do the routing.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Regards,
>> >> >>>>>
>> >> >>>>> Gert
>> >> >>>>>
>> >> >>>>> gauravsonline wrote:
>> >> >>>>>
>> >> >>>>>> HI,
>> >> >>>>>> Thanks for your help. Actualy just now I resolved the problem.
>> >> >>>>>> The problem was in the xslt-su. The archtyope by default
>> generates
>> >> >>>>>> the
>> >> >>>>>> servicemix.xml file and in the example code its xbean.xml file.
>> So
>> >> >>>>>> just
>> >> >>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>> >> >>>>>> dependency
>> >> >>>>>> was
>> >> >>>>>> ok.
>> >> >>>>>>
>> >> >>>>>> Now the next step is to read the messages from the queue and
>> call
>> >> a
>> >> >>>>>> web
>> >> >>>>>> service. Could you please help??
>> >> >>>>>>
>> >> >>>>>> Also I would like to request the moderator if they could update
>> >> this
>> >> >>>>>> thing
>> >> >>>>>> at :
>> >> >>>>>>
>> >> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >> >>>>>>
>> >> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >> >>>>>>
>> >> >>>>>> in the "XSLT SU" section, as this has costed me two days to
>> >> resolve.
>> >> >>>>>>
>> >> >>>>>> Thanks all for your help!
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
>> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Principal Engineer, IONA
>> > Blog: http://gnodet.blogspot.com/
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10623352
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10624001
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Thanks Gnodt. Let me look into it.
gnodet wrote:
>
> There should be some nightly snapshots available on the maven repo
> http://people.apache.org/repo/m2-snapshot-repository/
>
> The distribution is available at
>
> http://people.apache.org/repo/m2-snapshot-repository/org/apache/servicemix/apache-servicemix/3.2-incubating-SNAPSHOT/apache-servicemix-3.2-incubating-20070503.120612-25.tar.gz
>
> But you will need the code and look at the unit tests, as this is not
> really
> documented yet.
>
> On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
>>
>>
>> Hi Gnodet,
>>
>> Yes thats what I did. Created a jms-provider and a http-consumer in one
>> SA
>> (i have used the bridge-protocol example) and jms-consumer with the
>> endpoints of the target service in the other SA. So the flow is like I
>> post
>> the xml messsage thru a client to the http-consumer and the message is
>> pushed in the queue thru the jms-producer. Now the jms-consumer pulls the
>> message out and calls the web service. This is basically a routing of the
>> message, if I am not wrong.
>>
>> Now, the problem is how can i push a message object into the queue? As
>> you
>> responded, that the mashaling BC's are still not released so I will have
>> to
>> get the source from the SVN directly. Let me see if I can do something
>> with
>> it. If you can help me in placing the build then that would be great.
>>
>> Thanks...
>>
>> Gaurav
>>
>>
>> gnodet wrote:
>> >
>> > If you know how to send an HTTP request to a JMS queue,
>> > doing the opposite is quite easy. You just need to exchange
>> > the endpoint roles so that you will end up with an jms consumer
>> > and an http provider.
>> >
>> > Now, if you really need to send an object, you should use the new
>> > endpoints
>> > that have not been released yet (download the svn sources and build the
>> > trunk
>> > version). The servicemix-jms BC defines two new endpoints
>> > <jms:consumer />
>> > and
>> > <jms:provider />
>> > Take a look at the code, and you will see the ConsumerMarshaler and
>> > ProviderMarhsaler
>> > interfaces that you can implement to override the transformation from
>> JMS
>> > <-> JBI.
>> > You will be able to put your custom marhsaling code there.
>> >
>> > On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
>> >>
>> >>
>> >> Hi,
>> >>
>> >> Thanks for your response.
>> >>
>> >> gnodet wrote:
>> >> >
>> >> > Now, if you want to call an external HTTP service, you need to link
>> the
>> >> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
>> >> > in the servicemix distribution (and the turorial on the web site),
>> they
>> >> > are
>> >> > really related to that (though it's from HTTP to JMS, but the same
>> >> things
>> >> > apply).
>> >> >
>> >>
>> >> This part I have done already. I am able to post an xml message to the
>> >> queue
>> >> and called a web service.
>> >>
>> >> Now, the second part of it is to post the message object.
>> >>
>> >> gnodet wrote:
>> >> >
>> >> > Which onMessage are you talking about ?
>> >> > Currently, the JMS BC mainly expects an xml and you can route the
>> >> > exchange to jsr181 which will unmarshall it and call the pojo.
>> >> > If you want to use a java object in the JMS message, you will have
>> >> > to marshal it to xml on the BC side.
>> >> >
>> >>
>> >> We know from J2EE that an MDB has a onMessage() method which is
>> triggered
>> >> when a message is pushed into the queue. We can have the business
>> logic
>> >> in
>> >> this method for calling the target web service. My requiremnt is to
>> >> implement the same thing using servicemix. But till now I just know
>> about
>> >> how to push the xml message in the jms of servicemix using
>> http-consumer
>> >> and
>> >> then using then jms-provider retrieveing the messages from the queue
>> and
>> >> invoking the jsr-181 web service.
>> >>
>> >> I hope this makes the picture much clear.
>> >>
>> >> I have read that we can convert the message object into xml. This
>> comes
>> >> built-in with activemq. But how to create the SU for it. I also think
>> of
>> >> doing a transormation from messgae object to xml. But I do not know
>> how
>> >> to
>> >> do it. Plz help...
>> >>
>> >> Thanks...
>> >>
>> >>
>> >> gnodet wrote:
>> >> >
>> >> > Which onMessage are you talking about ?
>> >> > Currently, the JMS BC mainly expects an xml and you can route the
>> >> > exchange to jsr181 which will unmarshall it and call the pojo.
>> >> > If you want to use a java object in the JMS message, you will have
>> >> > to marshal it to xml on the BC side.
>> >> > If you don't have a real need for using a java object inside the JMS
>> >> > message,
>> >> > I'd really recommand using xml if possible inside ServiceMix.
>> >> > Now, if you want to call an external HTTP service, you need to link
>> the
>> >> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
>> >> > in the servicemix distribution (and the turorial on the web site),
>> they
>> >> > are
>> >> > really related to that (though it's from HTTP to JMS, but the same
>> >> things
>> >> > apply).
>> >> >
>> >> > On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
>> >> >>
>> >> >>
>> >> >> Hi Gert,
>> >> >>
>> >> >> Thanks for the help. With little effort I got evertything working
>> at
>> >> my
>> >> >> end.
>> >> >> Moreover the resolution was also very precise and easy to
>> understand.
>> >> >>
>> >> >> Now, suppose my queue receives a message in the object form of type
>> >> >> "Message" and I want to typecast it to the required type. Then,
>> >> after
>> >> >> that
>> >> >> I will invoke a webservice and pass that object as thep parameter
>> for
>> >> the
>> >> >> operation (think this would be RPC call). e.g. I am posting
>> messages
>> >> of
>> >> >> type
>> >> >> class A in the queue (here i will use jms producer), then jms
>> consumer
>> >> >> will
>> >> >> retrieve the messages of type class A. No some how I want the
>> >> >> onMessage(Message msg) method to be trigerred. The parameter msg
>> will
>> >> be
>> >> >> type casted to type class A and then I will call a webservice (i
>> think
>> >> it
>> >> >> would be RPC using service stubs) which takes this obect of type A
>> as
>> >> a
>> >> >> parameter.
>> >> >>
>> >> >> I was looking at the Active MQ implemenattion of it. have cerating
>> >> >> queries
>> >> >> related to it.
>> >> >>
>> >> >> 1. How can I invoke the onMessage() method throgh the jms consumer
>> >> >> service
>> >> >> unit?
>> >> >> 2. How can i invoke the jsr-181 service from inside the onMessage()
>> >> >> method?
>> >> >>
>> >> >> Can I implement such a scenario with in service mix end-to-end. Plz
>> >> >> guide.
>> >> >>
>> >> >> Thanks.
>> >> >>
>> >> >>
>> >> >>
>> >> >> Gert Vanthienen wrote:
>> >> >> >
>> >> >> > L.S.,
>> >> >> >
>> >> >> > OK, so you have implemented and deployed a web service using the
>> >> >> JSR-181
>> >> >> > component. This results in an internal endpoint for
>> >> ServiceMix. This
>> >> >> > means that the service is accessible within the ESB itself. If
>> you
>> >> >> want
>> >> >> > to make the service available to the outside world, you'll have
>> to
>> >> add
>> >> >> an
>> >> >> > external endpoint (e.g. a JMS or HTTP consumer) for the same
>> >> >> service. So
>> >> >> > if you just want to route between your JMS queue and the JSR-181
>> >> >> endpoint,
>> >> >> > you create only one JMS consumer endpoint with the same service
>> name
>> >> to
>> >> >> > connect the external endpoint with the internal endpoint and you
>> >> don't
>> >> >> > need any of the intermediary HTTP endpoint definitions. If you
>> want
>> >> to
>> >> >> > have multiple external endpoints (e.g. file poller, http
>> consumer,
>> >> ftp
>> >> >> > poller, ...), you can create them and specify
>> >> >> targetService/targetEndpoint
>> >> >> > attributes to specify the routing to the internal endpoint.
>> >> >> >
>> >> >> > In your example, you've also added an HTTP provider
>> endpoint. This
>> >> is
>> >> >> a
>> >> >> > way to make an external web service available in the ESB (thus
>> >> >> resulting
>> >> >> > in another internal endpoint) and that's where your code sample
>> >> fails
>> >> >> > (duplicate internal endpoint names).
>> >> >> >
>> >> >> > Does this clarify the internal/external endpoint issue for you?
>> >> >> >
>> >> >> > Gert
>> >> >> >
>> >> >> > gauravsonline wrote:
>> >> >> >>
>> >> >> >> Hi Gert,
>> >> >> >>
>> >> >> >> I have created the consumer-jms-su and the provider-http-su and
>> SA
>> >> for
>> >> >> it
>> >> >> >> (call it as SA_retrieve). Before that I would like to explain
>> what
>> >> I
>> >> >> have
>> >> >> >> done till now. I have created the bridge example in SMX for
>> sending
>> >> >> the
>> >> >> >> messages to the queue. I have also created a JSR 181 web service
>> >> for
>> >> >> >> echoing some message with http-consumer-su and
>> >> jsr181-wsdl-first-su.
>> >> >> >>
>> >> >> >> I am able to deploy the SA_retrieve and the bridge example. I am
>> >> able
>> >> >> to
>> >> >> >> send messages to the queue and then the SA_retrieve is able to
>> >> >> retrieve
>> >> >> >> the messages. The message is displyed in the SMX console and
>> queue
>> >> >> >> encount value is checked from JMX console.
>> >> >> >>
>> >> >> >> Now in order to make them all work together, I am deploying the
>> SA
>> >> in
>> >> >> >> order like this bridge example, echo WS, and then the
>> SA_retrieve
>> >> WS.
>> >> >> >> When I deploy the SA_retrieve WS it throws exceptions saying
>> that
>> >> the
>> >> >> >> "EchoService" service name and the "EchoPort" endpoint are
>> already
>> >> >> >> registered to soem internal service. As you told to give the
>> same
>> >> >> service
>> >> >> >> name and the endpoint as in the wsdl. But this is creating
>> problem.
>> >> >> For
>> >> >> >> your reference I am attaching the configuration of all the SA
>> for
>> >> your
>> >> >> >> refence:
>> >> >> >>
>> >> >> >> SA_retrieve:
>> >> >> >> =========
>> >> >> >> consumer-jms-su: xbean.xml
>> >> >> >> ----------------------------------
>> >> >> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
>> >> >> >> xmlns:test="http://motorola.com/test/test_amq">
>> >> >> >>
>> >> >> >> <!-- START SNIPPET: consumer -->
>> >> >> >> <jms:endpoint service="test:MyConsumerService"
>> >> >> >> endpoint="jms"
>> >> >> >> role="consumer"
>> >> >> >> destinationStyle="queue"
>> >> >> >> jmsProviderDestinationName="bridge.output"
>> >> >> >> connectionFactory="#connectionFactory"
>> >> >> >>
>> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> >> defaultOperation="test:Echo" />
>> >> >> >> <!-- END SNIPPET: consumer -->
>> >> >> >>
>> >> >> >> <jms:endpoint service="test:MyConsumerService"
>> >> >> >> endpoint="jms+soap"
>> >> >> >> targetInterfaceName="test:MyConsumerInterface"
>> >> >> >> role="consumer"
>> >> >> >> destinationStyle="queue"
>> >> >> >> jmsProviderDestinationName="bridge.output"
>> >> >> >> connectionFactory="#connectionFactory"
>> >> >> >> soap="true"
>> >> >> >>
>> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> />
>> >> >> >>
>> >> >> >> <bean id="connectionFactory"
>> >> >> >> class="org.apache.activemq.ActiveMQConnectionFactory">
>> >> >> >> <property name="brokerURL" value="tcp://localhost:61616" />
>> >> >> >> </bean>
>> >> >> >> </beans>
>> >> >> >>
>> >> >> >> provider-http-su: xbean.xml
>> >> >> >> ----------------------------------
>> >> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> >> >> xmlns:test="http://motorola.com/test/test_amq">
>> >> >> >>
>> >> >> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
>> >> >> >> service="echo:EchoService"
>> >> >> >> endpoint="EchoPort"
>> >> >> >> role="provider"
>> >> >> >> locationURI="http://localhost:9999/echo/"
>> >> >> >> defaultMep="
>> http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> >> soap="true"
>> >> >> >> wsdlResource="classpath:echo.wsdl"/>
>> >> >> >>
>> >> >> >> </beans>
>> >> >> >> Actually I have kept the wsdl at the path, so its that way.
>> >> >> >>
>> >> >> >> JSR181 WS:
>> >> >> >> ========
>> >> >> >> jsr181-su: xbean.xml
>> >> >> >> --------------------------
>> >> >> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
>> >> >> >>
>> >> >> >> <classpath>
>> >> >> >> <location>.</location>
>> >> >> >> </classpath>
>> >> >> >>
>> >> >> >> <jsr181:endpoint
>> >> >> pojoClass="com.motorola.test.echo.EchoServiceImpl"
>> >> >> >> wsdlResource="classpath:echo.wsdl"
>> >> >> >> style="document" />
>> >> >> >>
>> >> >> >> </beans>
>> >> >> >>
>> >> >> >> jsr181-su: echo.wsdl
>> >> >> >> -------------------------
>> >> >> >> <?xml version="1.0" encoding="UTF-8"?>
>> >> >> >> <wsdl:definitions
>> >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>> >> >> >> xmlns:tns="http://motorola.com/test/echo"
>> >> >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> >> >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
>> >> >> >> targetNamespace="http://motorola.com/test/echo">
>> >> >> >> <wsdl:types>
>> >> >> >> <xsd:schema
>> >> >> >> targetNamespace="http://motorola.com/test/echo">
>> >> >> >> <xsd:element name="Echo">
>> >> >> >> <xsd:complexType>
>> >> >> >> <xsd:sequence>
>> >> >> >> <xsd:element name="in"
>> >> >> >> type="xsd:string"></xsd:element>
>> >> >> >> </xsd:sequence>
>> >> >> >> </xsd:complexType>
>> >> >> >> </xsd:element>
>> >> >> >> <!--<xsd:element name="EchoResponse">
>> >> >> >> <xsd:complexType>
>> >> >> >> <xsd:sequence>
>> >> >> >> <xsd:element
>> >> >> name="out"
>> >> >> >> type="xsd:string"/>
>> >> >> >> </xsd:sequence>
>> >> >> >> </xsd:complexType>
>> >> >> >> </xsd:element>-->
>> >> >> >> </xsd:schema>
>> >> >> >> </wsdl:types>
>> >> >> >>
>> >> >> >> <wsdl:message name="echoRequest">
>> >> >> >> <wsdl:part element="tns:Echo" name="in"/>
>> >> >> >> </wsdl:message>
>> >> >> >> <wsdl:message name="echoResponse">
>> >> >> >> <wsdl:part type="xsd:boolean" name="out"/>
>> >> >> >> </wsdl:message>
>> >> >> >>
>> >> >> >> <wsdl:portType name="EchoPortType">
>> >> >> >> <wsdl:operation name="echo">
>> >> >> >> <wsdl:input message="tns:echoRequest"/>
>> >> >> >> <wsdl:output
>> message="tns:echoResponse"/>
>> >> >> >> </wsdl:operation>
>> >> >> >> </wsdl:portType>
>> >> >> >>
>> >> >> >> <wsdl:binding name="EchoBinding"
>> type="tns:EchoPortType">
>> >> >> >> <soap:binding style="document"
>> >> >> >> transport="http://schemas.xmlsoap.org/soap/http"/>
>> >> >> >> <wsdl:operation name="echo">
>> >> >> >> <soap:operation
>> >> >> >> soapAction="http://motorola.com/test/echo/echo"/>
>> >> >> >> <wsdl:input>
>> >> >> >> <soap:body use="literal"/>
>> >> >> >> </wsdl:input>
>> >> >> >> <wsdl:output>
>> >> >> >> <soap:body use="literal"/>
>> >> >> >> </wsdl:output>
>> >> >> >> </wsdl:operation>
>> >> >> >> </wsdl:binding>
>> >> >> >>
>> >> >> >> <wsdl:service name="EchoService">
>> >> >> >> <wsdl:port binding="tns:EchoBinding"
>> >> name="EchoPort">
>> >> >> >> <soap:address
>> >> >> >> location="http://0.0.0.0:9999/echo"/>
>> >> >> >> </wsdl:port>
>> >> >> >> </wsdl:service>
>> >> >> >> </wsdl:definitions>
>> >> >> >>
>> >> >> >> consumer-http-su: xbean.xml
>> >> >> >> ---------------------------------
>> >> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> >> >> xmlns:test="http://motorola.com/test/echo">
>> >> >> >>
>> >> >> >> <http:endpoint service="test:EchoService"
>> >> >> >> endpoint="EchoPort"
>> >> >> >> role="consumer"
>> >> >> >> locationURI="http://0.0.0.0:9999/echo/"
>> >> >> >> defaultMep="
>> http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> >> soap="true" />
>> >> >> >>
>> >> >> >> </beans>
>> >> >> >>
>> >> >> >> So I am using the same values for http:endpoint
>> >> >> >> service="test:EchoService", endpoint="EchoPort" in my echo
>> service
>> >> >> >> consumer-http-su and in the provider-http-su of SA_reteive SA
>> which
>> >> is
>> >> >> >> retrieving the messages. This duplicay is giving the problem.
>> >> >> >>
>> >> >> >> Please help, as I am not able to figure out to define the proper
>> >> >> routing
>> >> >> >> of the messages beteen SU and across SA.
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Gaurav
>> >> >> >>
>> >> >> >>
>> >> >> >> Gert Vanthienen wrote:
>> >> >> >>>
>> >> >> >>> Guarav,
>> >> >> >>>
>> >> >> >>> Is this the only change that is necessary in the XSL file to
>> >> switch
>> >> >> to
>> >> >> >>> version 2.0?
>> >> >> >>>
>> >> >> >>> For what the saxon dependency is concerned:
>> >> >> >>> The previous version of the page used the
>> >> >> >>> servicemix-lwcontainer-service-unit archetype to create the
>> >> >> >>> bridge-xslt-su. I have changed that to use
>> >> >> >>> servicemix-saxon-xslt-service-unit and that one should
>> >> automatically
>> >> >> put
>> >> >> >>> the correct dependency in there to start with.
>> >> >> >>>
>> >> >> >>> Gert
>> >> >> >>>
>> >> >> >>> gauravsonline wrote:
>> >> >> >>>> Thank you so much. Would like to suggest two more small
>> changes,
>> >> >> though
>> >> >> >>>> not
>> >> >> >>>> important but it would make the things more concrete.
>> >> >> >>>>
>> >> >> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0",
>> >> which
>> >> >> >>>> should
>> >> >> >>>> be "2.0". If not the case then servicemix gives a warning that
>> >> >> "saxon
>> >> >> >>>> engine
>> >> >> >>>> is 2.0 but the stylesheet version is 1.0".
>> >> >> >>>>
>> >> >> >>>> Secondly, the saxon dependency has to be added in the pom.xml
>> >> file
>> >> >> for
>> >> >> >>>> XSLT
>> >> >> >>>> SU.
>> >> >> >>>>
>> >> >> >>>> <dependencies>
>> >> >> >>>> <dependency>
>> >> >> >>>> <groupId>org.apache.servicemix</groupId>
>> >> >> >>>> <artifactId>servicemix-saxon</artifactId>
>> >> >> >>>> <version>3.1-incubating-SNAPSHOT</version>
>> >> >> >>>> </dependency>
>> >> >> >>>> </dependencies>
>> >> >> >>>>
>> >> >> >>>> Hope this makes sense. As of know I just have these many
>> changes
>> >> >> only.
>> >> >> >>>>
>> >> >> >>>> Also thanks for ur reply on the second use case. I will now
>> work
>> >> on
>> >> >> >>>> that.
>> >> >> >>>>
>> >> >> >>>> Regards....
>> >> >> >>>> Gaurav
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>> Gert Vanthienen wrote:
>> >> >> >>>>
>> >> >> >>>>> L.S.,
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> First of all, I have changed
>> >> >> >>>>>
>> >> >>
>> >>
>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>> >> >> >>>>> Could you check if all necessary changes have been done?
>> This
>> >> page
>> >> >> >>>>> will
>> >> >> >>>>> get replicated to the main site after a while...
>> >> >> >>>>>
>> >> >> >>>>> For your second use case: if you do not need any
>> transformations
>> >> on
>> >> >> >>>>> the
>> >> >> >>>>> message content, you can create a service assembly with two
>> >> service
>> >> >> >>>>> units:
>> >> >> >>>>> - one SU based on servicemix-jms, defining the JMS consumer
>> >> >> endpoint
>> >> >> >>>>> to
>> >> >> >>>>> read messages from a JMS queue (cfr.
>> >> >> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html
>> for
>> >> >> >>>>> configuration options)
>> >> >> >>>>> - the other SU based on servicemix-http, defining the HTTP
>> >> provider
>> >> >> >>>>> endpoint which points to your webservice (cfr.
>> >> >> >>>>>
>> http://incubator.apache.org/servicemix/servicemix-http.htmlfor
>> >> >> >>>>> configuration options)
>> >> >> >>>>>
>> >> >> >>>>> Beware that the service/endpoint name of you HTTP provider
>> >> endpoint
>> >> >> >>>>> should match the names defined in your webservice's WSDL.
>> You
>> >> can
>> >> >> >>>>> either use the same service/endpoint name on your JMS
>> endpoint
>> >> or
>> >> >> use
>> >> >> >>>>> the targetService/targetEndpoint attributes to do the
>> routing.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> Regards,
>> >> >> >>>>>
>> >> >> >>>>> Gert
>> >> >> >>>>>
>> >> >> >>>>> gauravsonline wrote:
>> >> >> >>>>>
>> >> >> >>>>>> HI,
>> >> >> >>>>>> Thanks for your help. Actualy just now I resolved the
>> problem.
>> >> >> >>>>>> The problem was in the xslt-su. The archtyope by default
>> >> generates
>> >> >> >>>>>> the
>> >> >> >>>>>> servicemix.xml file and in the example code its
>> xbean.xmlfile.
>> >> So
>> >> >> >>>>>> just
>> >> >> >>>>>> renaming the file from servicemix.xml to xbean.xml. The
>> saxon
>> >> >> >>>>>> dependency
>> >> >> >>>>>> was
>> >> >> >>>>>> ok.
>> >> >> >>>>>>
>> >> >> >>>>>> Now the next step is to read the messages from the queue and
>> >> call
>> >> >> a
>> >> >> >>>>>> web
>> >> >> >>>>>> service. Could you please help??
>> >> >> >>>>>>
>> >> >> >>>>>> Also I would like to request the moderator if they could
>> update
>> >> >> this
>> >> >> >>>>>> thing
>> >> >> >>>>>> at :
>> >> >> >>>>>>
>> >> >>
>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >> >> >>>>>>
>> >> >>
>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >> >> >>>>>>
>> >> >> >>>>>> in the "XSLT SU" section, as this has costed me two days to
>> >> >> resolve.
>> >> >> >>>>>>
>> >> >> >>>>>> Thanks all for your help!
>> >> >> >>>>>>
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
>> >> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > Cheers,
>> >> > Guillaume Nodet
>> >> > ------------------------
>> >> > Principal Engineer, IONA
>> >> > Blog: http://gnodet.blogspot.com/
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10623352
>> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Principal Engineer, IONA
>> > Blog: http://gnodet.blogspot.com/
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10624002
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10624544
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are differentfromBridgeexample's
Posted by Guillaume Nodet <gn...@gmail.com>.
There should be some nightly snapshots available on the maven repo
http://people.apache.org/repo/m2-snapshot-repository/
The distribution is available at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/servicemix/apache-servicemix/3.2-incubating-SNAPSHOT/apache-servicemix-3.2-incubating-20070503.120612-25.tar.gz
But you will need the code and look at the unit tests, as this is not really
documented yet.
On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
>
>
> Hi Gnodet,
>
> Yes thats what I did. Created a jms-provider and a http-consumer in one SA
> (i have used the bridge-protocol example) and jms-consumer with the
> endpoints of the target service in the other SA. So the flow is like I
> post
> the xml messsage thru a client to the http-consumer and the message is
> pushed in the queue thru the jms-producer. Now the jms-consumer pulls the
> message out and calls the web service. This is basically a routing of the
> message, if I am not wrong.
>
> Now, the problem is how can i push a message object into the queue? As you
> responded, that the mashaling BC's are still not released so I will have
> to
> get the source from the SVN directly. Let me see if I can do something
> with
> it. If you can help me in placing the build then that would be great.
>
> Thanks...
>
> Gaurav
>
>
> gnodet wrote:
> >
> > If you know how to send an HTTP request to a JMS queue,
> > doing the opposite is quite easy. You just need to exchange
> > the endpoint roles so that you will end up with an jms consumer
> > and an http provider.
> >
> > Now, if you really need to send an object, you should use the new
> > endpoints
> > that have not been released yet (download the svn sources and build the
> > trunk
> > version). The servicemix-jms BC defines two new endpoints
> > <jms:consumer />
> > and
> > <jms:provider />
> > Take a look at the code, and you will see the ConsumerMarshaler and
> > ProviderMarhsaler
> > interfaces that you can implement to override the transformation from
> JMS
> > <-> JBI.
> > You will be able to put your custom marhsaling code there.
> >
> > On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
> >>
> >>
> >> Hi,
> >>
> >> Thanks for your response.
> >>
> >> gnodet wrote:
> >> >
> >> > Now, if you want to call an external HTTP service, you need to link
> the
> >> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
> >> > in the servicemix distribution (and the turorial on the web site),
> they
> >> > are
> >> > really related to that (though it's from HTTP to JMS, but the same
> >> things
> >> > apply).
> >> >
> >>
> >> This part I have done already. I am able to post an xml message to the
> >> queue
> >> and called a web service.
> >>
> >> Now, the second part of it is to post the message object.
> >>
> >> gnodet wrote:
> >> >
> >> > Which onMessage are you talking about ?
> >> > Currently, the JMS BC mainly expects an xml and you can route the
> >> > exchange to jsr181 which will unmarshall it and call the pojo.
> >> > If you want to use a java object in the JMS message, you will have
> >> > to marshal it to xml on the BC side.
> >> >
> >>
> >> We know from J2EE that an MDB has a onMessage() method which is
> triggered
> >> when a message is pushed into the queue. We can have the business logic
> >> in
> >> this method for calling the target web service. My requiremnt is to
> >> implement the same thing using servicemix. But till now I just know
> about
> >> how to push the xml message in the jms of servicemix using
> http-consumer
> >> and
> >> then using then jms-provider retrieveing the messages from the queue
> and
> >> invoking the jsr-181 web service.
> >>
> >> I hope this makes the picture much clear.
> >>
> >> I have read that we can convert the message object into xml. This comes
> >> built-in with activemq. But how to create the SU for it. I also think
> of
> >> doing a transormation from messgae object to xml. But I do not know how
> >> to
> >> do it. Plz help...
> >>
> >> Thanks...
> >>
> >>
> >> gnodet wrote:
> >> >
> >> > Which onMessage are you talking about ?
> >> > Currently, the JMS BC mainly expects an xml and you can route the
> >> > exchange to jsr181 which will unmarshall it and call the pojo.
> >> > If you want to use a java object in the JMS message, you will have
> >> > to marshal it to xml on the BC side.
> >> > If you don't have a real need for using a java object inside the JMS
> >> > message,
> >> > I'd really recommand using xml if possible inside ServiceMix.
> >> > Now, if you want to call an external HTTP service, you need to link
> the
> >> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
> >> > in the servicemix distribution (and the turorial on the web site),
> they
> >> > are
> >> > really related to that (though it's from HTTP to JMS, but the same
> >> things
> >> > apply).
> >> >
> >> > On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
> >> >>
> >> >>
> >> >> Hi Gert,
> >> >>
> >> >> Thanks for the help. With little effort I got evertything working at
> >> my
> >> >> end.
> >> >> Moreover the resolution was also very precise and easy to
> understand.
> >> >>
> >> >> Now, suppose my queue receives a message in the object form of type
> >> >> "Message" and I want to typecast it to the required type. Then,
> >> after
> >> >> that
> >> >> I will invoke a webservice and pass that object as thep parameter
> for
> >> the
> >> >> operation (think this would be RPC call). e.g. I am posting messages
> >> of
> >> >> type
> >> >> class A in the queue (here i will use jms producer), then jms
> consumer
> >> >> will
> >> >> retrieve the messages of type class A. No some how I want the
> >> >> onMessage(Message msg) method to be trigerred. The parameter msg
> will
> >> be
> >> >> type casted to type class A and then I will call a webservice (i
> think
> >> it
> >> >> would be RPC using service stubs) which takes this obect of type A
> as
> >> a
> >> >> parameter.
> >> >>
> >> >> I was looking at the Active MQ implemenattion of it. have cerating
> >> >> queries
> >> >> related to it.
> >> >>
> >> >> 1. How can I invoke the onMessage() method throgh the jms consumer
> >> >> service
> >> >> unit?
> >> >> 2. How can i invoke the jsr-181 service from inside the onMessage()
> >> >> method?
> >> >>
> >> >> Can I implement such a scenario with in service mix end-to-end. Plz
> >> >> guide.
> >> >>
> >> >> Thanks.
> >> >>
> >> >>
> >> >>
> >> >> Gert Vanthienen wrote:
> >> >> >
> >> >> > L.S.,
> >> >> >
> >> >> > OK, so you have implemented and deployed a web service using the
> >> >> JSR-181
> >> >> > component. This results in an internal endpoint for
> >> ServiceMix. This
> >> >> > means that the service is accessible within the ESB itself. If
> you
> >> >> want
> >> >> > to make the service available to the outside world, you'll have to
> >> add
> >> >> an
> >> >> > external endpoint (e.g. a JMS or HTTP consumer) for the same
> >> >> service. So
> >> >> > if you just want to route between your JMS queue and the JSR-181
> >> >> endpoint,
> >> >> > you create only one JMS consumer endpoint with the same service
> name
> >> to
> >> >> > connect the external endpoint with the internal endpoint and you
> >> don't
> >> >> > need any of the intermediary HTTP endpoint definitions. If you
> want
> >> to
> >> >> > have multiple external endpoints (e.g. file poller, http consumer,
> >> ftp
> >> >> > poller, ...), you can create them and specify
> >> >> targetService/targetEndpoint
> >> >> > attributes to specify the routing to the internal endpoint.
> >> >> >
> >> >> > In your example, you've also added an HTTP provider
> endpoint. This
> >> is
> >> >> a
> >> >> > way to make an external web service available in the ESB (thus
> >> >> resulting
> >> >> > in another internal endpoint) and that's where your code sample
> >> fails
> >> >> > (duplicate internal endpoint names).
> >> >> >
> >> >> > Does this clarify the internal/external endpoint issue for you?
> >> >> >
> >> >> > Gert
> >> >> >
> >> >> > gauravsonline wrote:
> >> >> >>
> >> >> >> Hi Gert,
> >> >> >>
> >> >> >> I have created the consumer-jms-su and the provider-http-su and
> SA
> >> for
> >> >> it
> >> >> >> (call it as SA_retrieve). Before that I would like to explain
> what
> >> I
> >> >> have
> >> >> >> done till now. I have created the bridge example in SMX for
> sending
> >> >> the
> >> >> >> messages to the queue. I have also created a JSR 181 web service
> >> for
> >> >> >> echoing some message with http-consumer-su and
> >> jsr181-wsdl-first-su.
> >> >> >>
> >> >> >> I am able to deploy the SA_retrieve and the bridge example. I am
> >> able
> >> >> to
> >> >> >> send messages to the queue and then the SA_retrieve is able to
> >> >> retrieve
> >> >> >> the messages. The message is displyed in the SMX console and
> queue
> >> >> >> encount value is checked from JMX console.
> >> >> >>
> >> >> >> Now in order to make them all work together, I am deploying the
> SA
> >> in
> >> >> >> order like this bridge example, echo WS, and then the SA_retrieve
> >> WS.
> >> >> >> When I deploy the SA_retrieve WS it throws exceptions saying that
> >> the
> >> >> >> "EchoService" service name and the "EchoPort" endpoint are
> already
> >> >> >> registered to soem internal service. As you told to give the same
> >> >> service
> >> >> >> name and the endpoint as in the wsdl. But this is creating
> problem.
> >> >> For
> >> >> >> your reference I am attaching the configuration of all the SA for
> >> your
> >> >> >> refence:
> >> >> >>
> >> >> >> SA_retrieve:
> >> >> >> =========
> >> >> >> consumer-jms-su: xbean.xml
> >> >> >> ----------------------------------
> >> >> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
> >> >> >> xmlns:test="http://motorola.com/test/test_amq">
> >> >> >>
> >> >> >> <!-- START SNIPPET: consumer -->
> >> >> >> <jms:endpoint service="test:MyConsumerService"
> >> >> >> endpoint="jms"
> >> >> >> role="consumer"
> >> >> >> destinationStyle="queue"
> >> >> >> jmsProviderDestinationName="bridge.output"
> >> >> >> connectionFactory="#connectionFactory"
> >> >> >>
> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> >> >> defaultOperation="test:Echo" />
> >> >> >> <!-- END SNIPPET: consumer -->
> >> >> >>
> >> >> >> <jms:endpoint service="test:MyConsumerService"
> >> >> >> endpoint="jms+soap"
> >> >> >> targetInterfaceName="test:MyConsumerInterface"
> >> >> >> role="consumer"
> >> >> >> destinationStyle="queue"
> >> >> >> jmsProviderDestinationName="bridge.output"
> >> >> >> connectionFactory="#connectionFactory"
> >> >> >> soap="true"
> >> >> >>
> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> >> />
> >> >> >>
> >> >> >> <bean id="connectionFactory"
> >> >> >> class="org.apache.activemq.ActiveMQConnectionFactory">
> >> >> >> <property name="brokerURL" value="tcp://localhost:61616" />
> >> >> >> </bean>
> >> >> >> </beans>
> >> >> >>
> >> >> >> provider-http-su: xbean.xml
> >> >> >> ----------------------------------
> >> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> >> >> >> xmlns:test="http://motorola.com/test/test_amq">
> >> >> >>
> >> >> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
> >> >> >> service="echo:EchoService"
> >> >> >> endpoint="EchoPort"
> >> >> >> role="provider"
> >> >> >> locationURI="http://localhost:9999/echo/"
> >> >> >> defaultMep="
> http://www.w3.org/2004/08/wsdl/in-out"
> >> >> >> soap="true"
> >> >> >> wsdlResource="classpath:echo.wsdl"/>
> >> >> >>
> >> >> >> </beans>
> >> >> >> Actually I have kept the wsdl at the path, so its that way.
> >> >> >>
> >> >> >> JSR181 WS:
> >> >> >> ========
> >> >> >> jsr181-su: xbean.xml
> >> >> >> --------------------------
> >> >> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
> >> >> >>
> >> >> >> <classpath>
> >> >> >> <location>.</location>
> >> >> >> </classpath>
> >> >> >>
> >> >> >> <jsr181:endpoint
> >> >> pojoClass="com.motorola.test.echo.EchoServiceImpl"
> >> >> >> wsdlResource="classpath:echo.wsdl"
> >> >> >> style="document" />
> >> >> >>
> >> >> >> </beans>
> >> >> >>
> >> >> >> jsr181-su: echo.wsdl
> >> >> >> -------------------------
> >> >> >> <?xml version="1.0" encoding="UTF-8"?>
> >> >> >> <wsdl:definitions
> >> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> >> >> >> xmlns:tns="http://motorola.com/test/echo"
> >> >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> >> >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
> >> >> >> targetNamespace="http://motorola.com/test/echo">
> >> >> >> <wsdl:types>
> >> >> >> <xsd:schema
> >> >> >> targetNamespace="http://motorola.com/test/echo">
> >> >> >> <xsd:element name="Echo">
> >> >> >> <xsd:complexType>
> >> >> >> <xsd:sequence>
> >> >> >> <xsd:element name="in"
> >> >> >> type="xsd:string"></xsd:element>
> >> >> >> </xsd:sequence>
> >> >> >> </xsd:complexType>
> >> >> >> </xsd:element>
> >> >> >> <!--<xsd:element name="EchoResponse">
> >> >> >> <xsd:complexType>
> >> >> >> <xsd:sequence>
> >> >> >> <xsd:element
> >> >> name="out"
> >> >> >> type="xsd:string"/>
> >> >> >> </xsd:sequence>
> >> >> >> </xsd:complexType>
> >> >> >> </xsd:element>-->
> >> >> >> </xsd:schema>
> >> >> >> </wsdl:types>
> >> >> >>
> >> >> >> <wsdl:message name="echoRequest">
> >> >> >> <wsdl:part element="tns:Echo" name="in"/>
> >> >> >> </wsdl:message>
> >> >> >> <wsdl:message name="echoResponse">
> >> >> >> <wsdl:part type="xsd:boolean" name="out"/>
> >> >> >> </wsdl:message>
> >> >> >>
> >> >> >> <wsdl:portType name="EchoPortType">
> >> >> >> <wsdl:operation name="echo">
> >> >> >> <wsdl:input message="tns:echoRequest"/>
> >> >> >> <wsdl:output message="tns:echoResponse"/>
> >> >> >> </wsdl:operation>
> >> >> >> </wsdl:portType>
> >> >> >>
> >> >> >> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
> >> >> >> <soap:binding style="document"
> >> >> >> transport="http://schemas.xmlsoap.org/soap/http"/>
> >> >> >> <wsdl:operation name="echo">
> >> >> >> <soap:operation
> >> >> >> soapAction="http://motorola.com/test/echo/echo"/>
> >> >> >> <wsdl:input>
> >> >> >> <soap:body use="literal"/>
> >> >> >> </wsdl:input>
> >> >> >> <wsdl:output>
> >> >> >> <soap:body use="literal"/>
> >> >> >> </wsdl:output>
> >> >> >> </wsdl:operation>
> >> >> >> </wsdl:binding>
> >> >> >>
> >> >> >> <wsdl:service name="EchoService">
> >> >> >> <wsdl:port binding="tns:EchoBinding"
> >> name="EchoPort">
> >> >> >> <soap:address
> >> >> >> location="http://0.0.0.0:9999/echo"/>
> >> >> >> </wsdl:port>
> >> >> >> </wsdl:service>
> >> >> >> </wsdl:definitions>
> >> >> >>
> >> >> >> consumer-http-su: xbean.xml
> >> >> >> ---------------------------------
> >> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> >> >> >> xmlns:test="http://motorola.com/test/echo">
> >> >> >>
> >> >> >> <http:endpoint service="test:EchoService"
> >> >> >> endpoint="EchoPort"
> >> >> >> role="consumer"
> >> >> >> locationURI="http://0.0.0.0:9999/echo/"
> >> >> >> defaultMep="
> http://www.w3.org/2004/08/wsdl/in-out"
> >> >> >> soap="true" />
> >> >> >>
> >> >> >> </beans>
> >> >> >>
> >> >> >> So I am using the same values for http:endpoint
> >> >> >> service="test:EchoService", endpoint="EchoPort" in my echo
> service
> >> >> >> consumer-http-su and in the provider-http-su of SA_reteive SA
> which
> >> is
> >> >> >> retrieving the messages. This duplicay is giving the problem.
> >> >> >>
> >> >> >> Please help, as I am not able to figure out to define the proper
> >> >> routing
> >> >> >> of the messages beteen SU and across SA.
> >> >> >>
> >> >> >> Regards,
> >> >> >> Gaurav
> >> >> >>
> >> >> >>
> >> >> >> Gert Vanthienen wrote:
> >> >> >>>
> >> >> >>> Guarav,
> >> >> >>>
> >> >> >>> Is this the only change that is necessary in the XSL file to
> >> switch
> >> >> to
> >> >> >>> version 2.0?
> >> >> >>>
> >> >> >>> For what the saxon dependency is concerned:
> >> >> >>> The previous version of the page used the
> >> >> >>> servicemix-lwcontainer-service-unit archetype to create the
> >> >> >>> bridge-xslt-su. I have changed that to use
> >> >> >>> servicemix-saxon-xslt-service-unit and that one should
> >> automatically
> >> >> put
> >> >> >>> the correct dependency in there to start with.
> >> >> >>>
> >> >> >>> Gert
> >> >> >>>
> >> >> >>> gauravsonline wrote:
> >> >> >>>> Thank you so much. Would like to suggest two more small
> changes,
> >> >> though
> >> >> >>>> not
> >> >> >>>> important but it would make the things more concrete.
> >> >> >>>>
> >> >> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0",
> >> which
> >> >> >>>> should
> >> >> >>>> be "2.0". If not the case then servicemix gives a warning that
> >> >> "saxon
> >> >> >>>> engine
> >> >> >>>> is 2.0 but the stylesheet version is 1.0".
> >> >> >>>>
> >> >> >>>> Secondly, the saxon dependency has to be added in the pom.xml
> >> file
> >> >> for
> >> >> >>>> XSLT
> >> >> >>>> SU.
> >> >> >>>>
> >> >> >>>> <dependencies>
> >> >> >>>> <dependency>
> >> >> >>>> <groupId>org.apache.servicemix</groupId>
> >> >> >>>> <artifactId>servicemix-saxon</artifactId>
> >> >> >>>> <version>3.1-incubating-SNAPSHOT</version>
> >> >> >>>> </dependency>
> >> >> >>>> </dependencies>
> >> >> >>>>
> >> >> >>>> Hope this makes sense. As of know I just have these many
> changes
> >> >> only.
> >> >> >>>>
> >> >> >>>> Also thanks for ur reply on the second use case. I will now
> work
> >> on
> >> >> >>>> that.
> >> >> >>>>
> >> >> >>>> Regards....
> >> >> >>>> Gaurav
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> Gert Vanthienen wrote:
> >> >> >>>>
> >> >> >>>>> L.S.,
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> First of all, I have changed
> >> >> >>>>>
> >> >>
> >>
> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
> >> >> >>>>> Could you check if all necessary changes have been done? This
> >> page
> >> >> >>>>> will
> >> >> >>>>> get replicated to the main site after a while...
> >> >> >>>>>
> >> >> >>>>> For your second use case: if you do not need any
> transformations
> >> on
> >> >> >>>>> the
> >> >> >>>>> message content, you can create a service assembly with two
> >> service
> >> >> >>>>> units:
> >> >> >>>>> - one SU based on servicemix-jms, defining the JMS consumer
> >> >> endpoint
> >> >> >>>>> to
> >> >> >>>>> read messages from a JMS queue (cfr.
> >> >> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
> >> >> >>>>> configuration options)
> >> >> >>>>> - the other SU based on servicemix-http, defining the HTTP
> >> provider
> >> >> >>>>> endpoint which points to your webservice (cfr.
> >> >> >>>>> http://incubator.apache.org/servicemix/servicemix-http.htmlfor
> >> >> >>>>> configuration options)
> >> >> >>>>>
> >> >> >>>>> Beware that the service/endpoint name of you HTTP provider
> >> endpoint
> >> >> >>>>> should match the names defined in your webservice's WSDL. You
> >> can
> >> >> >>>>> either use the same service/endpoint name on your JMS endpoint
> >> or
> >> >> use
> >> >> >>>>> the targetService/targetEndpoint attributes to do the routing.
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>> Regards,
> >> >> >>>>>
> >> >> >>>>> Gert
> >> >> >>>>>
> >> >> >>>>> gauravsonline wrote:
> >> >> >>>>>
> >> >> >>>>>> HI,
> >> >> >>>>>> Thanks for your help. Actualy just now I resolved the
> problem.
> >> >> >>>>>> The problem was in the xslt-su. The archtyope by default
> >> generates
> >> >> >>>>>> the
> >> >> >>>>>> servicemix.xml file and in the example code its xbean.xmlfile.
> >> So
> >> >> >>>>>> just
> >> >> >>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
> >> >> >>>>>> dependency
> >> >> >>>>>> was
> >> >> >>>>>> ok.
> >> >> >>>>>>
> >> >> >>>>>> Now the next step is to read the messages from the queue and
> >> call
> >> >> a
> >> >> >>>>>> web
> >> >> >>>>>> service. Could you please help??
> >> >> >>>>>>
> >> >> >>>>>> Also I would like to request the moderator if they could
> update
> >> >> this
> >> >> >>>>>> thing
> >> >> >>>>>> at :
> >> >> >>>>>>
> >> >>
> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
> >> >> >>>>>>
> >> >>
> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
> >> >> >>>>>>
> >> >> >>>>>> in the "XSLT SU" section, as this has costed me two days to
> >> >> resolve.
> >> >> >>>>>>
> >> >> >>>>>> Thanks all for your help!
> >> >> >>>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>>
> >> >> >>>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
> >> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > Cheers,
> >> > Guillaume Nodet
> >> > ------------------------
> >> > Principal Engineer, IONA
> >> > Blog: http://gnodet.blogspot.com/
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10623352
> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10624002
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Hi Gnodet,
Yes thats what I did. Created a jms-provider and a http-consumer in one SA
(i have used the bridge-protocol example) and jms-consumer with the
endpoints of the target service in the other SA. So the flow is like I post
the xml messsage thru a client to the http-consumer and the message is
pushed in the queue thru the jms-producer. Now the jms-consumer pulls the
message out and calls the web service. This is basically a routing of the
message, if I am not wrong.
Now, the problem is how can i push a message object into the queue? As you
responded, that the mashaling BC's are still not released so I will have to
get the source from the SVN directly. Let me see if I can do something with
it. If you can help me in placing the build then that would be great.
Thanks...
Gaurav
gnodet wrote:
>
> If you know how to send an HTTP request to a JMS queue,
> doing the opposite is quite easy. You just need to exchange
> the endpoint roles so that you will end up with an jms consumer
> and an http provider.
>
> Now, if you really need to send an object, you should use the new
> endpoints
> that have not been released yet (download the svn sources and build the
> trunk
> version). The servicemix-jms BC defines two new endpoints
> <jms:consumer />
> and
> <jms:provider />
> Take a look at the code, and you will see the ConsumerMarshaler and
> ProviderMarhsaler
> interfaces that you can implement to override the transformation from JMS
> <-> JBI.
> You will be able to put your custom marhsaling code there.
>
> On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
>>
>>
>> Hi,
>>
>> Thanks for your response.
>>
>> gnodet wrote:
>> >
>> > Now, if you want to call an external HTTP service, you need to link the
>> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
>> > in the servicemix distribution (and the turorial on the web site), they
>> > are
>> > really related to that (though it's from HTTP to JMS, but the same
>> things
>> > apply).
>> >
>>
>> This part I have done already. I am able to post an xml message to the
>> queue
>> and called a web service.
>>
>> Now, the second part of it is to post the message object.
>>
>> gnodet wrote:
>> >
>> > Which onMessage are you talking about ?
>> > Currently, the JMS BC mainly expects an xml and you can route the
>> > exchange to jsr181 which will unmarshall it and call the pojo.
>> > If you want to use a java object in the JMS message, you will have
>> > to marshal it to xml on the BC side.
>> >
>>
>> We know from J2EE that an MDB has a onMessage() method which is triggered
>> when a message is pushed into the queue. We can have the business logic
>> in
>> this method for calling the target web service. My requiremnt is to
>> implement the same thing using servicemix. But till now I just know about
>> how to push the xml message in the jms of servicemix using http-consumer
>> and
>> then using then jms-provider retrieveing the messages from the queue and
>> invoking the jsr-181 web service.
>>
>> I hope this makes the picture much clear.
>>
>> I have read that we can convert the message object into xml. This comes
>> built-in with activemq. But how to create the SU for it. I also think of
>> doing a transormation from messgae object to xml. But I do not know how
>> to
>> do it. Plz help...
>>
>> Thanks...
>>
>>
>> gnodet wrote:
>> >
>> > Which onMessage are you talking about ?
>> > Currently, the JMS BC mainly expects an xml and you can route the
>> > exchange to jsr181 which will unmarshall it and call the pojo.
>> > If you want to use a java object in the JMS message, you will have
>> > to marshal it to xml on the BC side.
>> > If you don't have a real need for using a java object inside the JMS
>> > message,
>> > I'd really recommand using xml if possible inside ServiceMix.
>> > Now, if you want to call an external HTTP service, you need to link the
>> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
>> > in the servicemix distribution (and the turorial on the web site), they
>> > are
>> > really related to that (though it's from HTTP to JMS, but the same
>> things
>> > apply).
>> >
>> > On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
>> >>
>> >>
>> >> Hi Gert,
>> >>
>> >> Thanks for the help. With little effort I got evertything working at
>> my
>> >> end.
>> >> Moreover the resolution was also very precise and easy to understand.
>> >>
>> >> Now, suppose my queue receives a message in the object form of type
>> >> "Message" and I want to typecast it to the required type. Then,
>> after
>> >> that
>> >> I will invoke a webservice and pass that object as thep parameter for
>> the
>> >> operation (think this would be RPC call). e.g. I am posting messages
>> of
>> >> type
>> >> class A in the queue (here i will use jms producer), then jms consumer
>> >> will
>> >> retrieve the messages of type class A. No some how I want the
>> >> onMessage(Message msg) method to be trigerred. The parameter msg will
>> be
>> >> type casted to type class A and then I will call a webservice (i think
>> it
>> >> would be RPC using service stubs) which takes this obect of type A as
>> a
>> >> parameter.
>> >>
>> >> I was looking at the Active MQ implemenattion of it. have cerating
>> >> queries
>> >> related to it.
>> >>
>> >> 1. How can I invoke the onMessage() method throgh the jms consumer
>> >> service
>> >> unit?
>> >> 2. How can i invoke the jsr-181 service from inside the onMessage()
>> >> method?
>> >>
>> >> Can I implement such a scenario with in service mix end-to-end. Plz
>> >> guide.
>> >>
>> >> Thanks.
>> >>
>> >>
>> >>
>> >> Gert Vanthienen wrote:
>> >> >
>> >> > L.S.,
>> >> >
>> >> > OK, so you have implemented and deployed a web service using the
>> >> JSR-181
>> >> > component. This results in an internal endpoint for
>> ServiceMix. This
>> >> > means that the service is accessible within the ESB itself. If you
>> >> want
>> >> > to make the service available to the outside world, you'll have to
>> add
>> >> an
>> >> > external endpoint (e.g. a JMS or HTTP consumer) for the same
>> >> service. So
>> >> > if you just want to route between your JMS queue and the JSR-181
>> >> endpoint,
>> >> > you create only one JMS consumer endpoint with the same service name
>> to
>> >> > connect the external endpoint with the internal endpoint and you
>> don't
>> >> > need any of the intermediary HTTP endpoint definitions. If you want
>> to
>> >> > have multiple external endpoints (e.g. file poller, http consumer,
>> ftp
>> >> > poller, ...), you can create them and specify
>> >> targetService/targetEndpoint
>> >> > attributes to specify the routing to the internal endpoint.
>> >> >
>> >> > In your example, you've also added an HTTP provider endpoint. This
>> is
>> >> a
>> >> > way to make an external web service available in the ESB (thus
>> >> resulting
>> >> > in another internal endpoint) and that's where your code sample
>> fails
>> >> > (duplicate internal endpoint names).
>> >> >
>> >> > Does this clarify the internal/external endpoint issue for you?
>> >> >
>> >> > Gert
>> >> >
>> >> > gauravsonline wrote:
>> >> >>
>> >> >> Hi Gert,
>> >> >>
>> >> >> I have created the consumer-jms-su and the provider-http-su and SA
>> for
>> >> it
>> >> >> (call it as SA_retrieve). Before that I would like to explain what
>> I
>> >> have
>> >> >> done till now. I have created the bridge example in SMX for sending
>> >> the
>> >> >> messages to the queue. I have also created a JSR 181 web service
>> for
>> >> >> echoing some message with http-consumer-su and
>> jsr181-wsdl-first-su.
>> >> >>
>> >> >> I am able to deploy the SA_retrieve and the bridge example. I am
>> able
>> >> to
>> >> >> send messages to the queue and then the SA_retrieve is able to
>> >> retrieve
>> >> >> the messages. The message is displyed in the SMX console and queue
>> >> >> encount value is checked from JMX console.
>> >> >>
>> >> >> Now in order to make them all work together, I am deploying the SA
>> in
>> >> >> order like this bridge example, echo WS, and then the SA_retrieve
>> WS.
>> >> >> When I deploy the SA_retrieve WS it throws exceptions saying that
>> the
>> >> >> "EchoService" service name and the "EchoPort" endpoint are already
>> >> >> registered to soem internal service. As you told to give the same
>> >> service
>> >> >> name and the endpoint as in the wsdl. But this is creating problem.
>> >> For
>> >> >> your reference I am attaching the configuration of all the SA for
>> your
>> >> >> refence:
>> >> >>
>> >> >> SA_retrieve:
>> >> >> =========
>> >> >> consumer-jms-su: xbean.xml
>> >> >> ----------------------------------
>> >> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
>> >> >> xmlns:test="http://motorola.com/test/test_amq">
>> >> >>
>> >> >> <!-- START SNIPPET: consumer -->
>> >> >> <jms:endpoint service="test:MyConsumerService"
>> >> >> endpoint="jms"
>> >> >> role="consumer"
>> >> >> destinationStyle="queue"
>> >> >> jmsProviderDestinationName="bridge.output"
>> >> >> connectionFactory="#connectionFactory"
>> >> >>
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> defaultOperation="test:Echo" />
>> >> >> <!-- END SNIPPET: consumer -->
>> >> >>
>> >> >> <jms:endpoint service="test:MyConsumerService"
>> >> >> endpoint="jms+soap"
>> >> >> targetInterfaceName="test:MyConsumerInterface"
>> >> >> role="consumer"
>> >> >> destinationStyle="queue"
>> >> >> jmsProviderDestinationName="bridge.output"
>> >> >> connectionFactory="#connectionFactory"
>> >> >> soap="true"
>> >> >>
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> />
>> >> >>
>> >> >> <bean id="connectionFactory"
>> >> >> class="org.apache.activemq.ActiveMQConnectionFactory">
>> >> >> <property name="brokerURL" value="tcp://localhost:61616" />
>> >> >> </bean>
>> >> >> </beans>
>> >> >>
>> >> >> provider-http-su: xbean.xml
>> >> >> ----------------------------------
>> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> >> xmlns:test="http://motorola.com/test/test_amq">
>> >> >>
>> >> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
>> >> >> service="echo:EchoService"
>> >> >> endpoint="EchoPort"
>> >> >> role="provider"
>> >> >> locationURI="http://localhost:9999/echo/"
>> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> soap="true"
>> >> >> wsdlResource="classpath:echo.wsdl"/>
>> >> >>
>> >> >> </beans>
>> >> >> Actually I have kept the wsdl at the path, so its that way.
>> >> >>
>> >> >> JSR181 WS:
>> >> >> ========
>> >> >> jsr181-su: xbean.xml
>> >> >> --------------------------
>> >> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
>> >> >>
>> >> >> <classpath>
>> >> >> <location>.</location>
>> >> >> </classpath>
>> >> >>
>> >> >> <jsr181:endpoint
>> >> pojoClass="com.motorola.test.echo.EchoServiceImpl"
>> >> >> wsdlResource="classpath:echo.wsdl"
>> >> >> style="document" />
>> >> >>
>> >> >> </beans>
>> >> >>
>> >> >> jsr181-su: echo.wsdl
>> >> >> -------------------------
>> >> >> <?xml version="1.0" encoding="UTF-8"?>
>> >> >> <wsdl:definitions
>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>> >> >> xmlns:tns="http://motorola.com/test/echo"
>> >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
>> >> >> targetNamespace="http://motorola.com/test/echo">
>> >> >> <wsdl:types>
>> >> >> <xsd:schema
>> >> >> targetNamespace="http://motorola.com/test/echo">
>> >> >> <xsd:element name="Echo">
>> >> >> <xsd:complexType>
>> >> >> <xsd:sequence>
>> >> >> <xsd:element name="in"
>> >> >> type="xsd:string"></xsd:element>
>> >> >> </xsd:sequence>
>> >> >> </xsd:complexType>
>> >> >> </xsd:element>
>> >> >> <!--<xsd:element name="EchoResponse">
>> >> >> <xsd:complexType>
>> >> >> <xsd:sequence>
>> >> >> <xsd:element
>> >> name="out"
>> >> >> type="xsd:string"/>
>> >> >> </xsd:sequence>
>> >> >> </xsd:complexType>
>> >> >> </xsd:element>-->
>> >> >> </xsd:schema>
>> >> >> </wsdl:types>
>> >> >>
>> >> >> <wsdl:message name="echoRequest">
>> >> >> <wsdl:part element="tns:Echo" name="in"/>
>> >> >> </wsdl:message>
>> >> >> <wsdl:message name="echoResponse">
>> >> >> <wsdl:part type="xsd:boolean" name="out"/>
>> >> >> </wsdl:message>
>> >> >>
>> >> >> <wsdl:portType name="EchoPortType">
>> >> >> <wsdl:operation name="echo">
>> >> >> <wsdl:input message="tns:echoRequest"/>
>> >> >> <wsdl:output message="tns:echoResponse"/>
>> >> >> </wsdl:operation>
>> >> >> </wsdl:portType>
>> >> >>
>> >> >> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
>> >> >> <soap:binding style="document"
>> >> >> transport="http://schemas.xmlsoap.org/soap/http"/>
>> >> >> <wsdl:operation name="echo">
>> >> >> <soap:operation
>> >> >> soapAction="http://motorola.com/test/echo/echo"/>
>> >> >> <wsdl:input>
>> >> >> <soap:body use="literal"/>
>> >> >> </wsdl:input>
>> >> >> <wsdl:output>
>> >> >> <soap:body use="literal"/>
>> >> >> </wsdl:output>
>> >> >> </wsdl:operation>
>> >> >> </wsdl:binding>
>> >> >>
>> >> >> <wsdl:service name="EchoService">
>> >> >> <wsdl:port binding="tns:EchoBinding"
>> name="EchoPort">
>> >> >> <soap:address
>> >> >> location="http://0.0.0.0:9999/echo"/>
>> >> >> </wsdl:port>
>> >> >> </wsdl:service>
>> >> >> </wsdl:definitions>
>> >> >>
>> >> >> consumer-http-su: xbean.xml
>> >> >> ---------------------------------
>> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> >> xmlns:test="http://motorola.com/test/echo">
>> >> >>
>> >> >> <http:endpoint service="test:EchoService"
>> >> >> endpoint="EchoPort"
>> >> >> role="consumer"
>> >> >> locationURI="http://0.0.0.0:9999/echo/"
>> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> >> soap="true" />
>> >> >>
>> >> >> </beans>
>> >> >>
>> >> >> So I am using the same values for http:endpoint
>> >> >> service="test:EchoService", endpoint="EchoPort" in my echo service
>> >> >> consumer-http-su and in the provider-http-su of SA_reteive SA which
>> is
>> >> >> retrieving the messages. This duplicay is giving the problem.
>> >> >>
>> >> >> Please help, as I am not able to figure out to define the proper
>> >> routing
>> >> >> of the messages beteen SU and across SA.
>> >> >>
>> >> >> Regards,
>> >> >> Gaurav
>> >> >>
>> >> >>
>> >> >> Gert Vanthienen wrote:
>> >> >>>
>> >> >>> Guarav,
>> >> >>>
>> >> >>> Is this the only change that is necessary in the XSL file to
>> switch
>> >> to
>> >> >>> version 2.0?
>> >> >>>
>> >> >>> For what the saxon dependency is concerned:
>> >> >>> The previous version of the page used the
>> >> >>> servicemix-lwcontainer-service-unit archetype to create the
>> >> >>> bridge-xslt-su. I have changed that to use
>> >> >>> servicemix-saxon-xslt-service-unit and that one should
>> automatically
>> >> put
>> >> >>> the correct dependency in there to start with.
>> >> >>>
>> >> >>> Gert
>> >> >>>
>> >> >>> gauravsonline wrote:
>> >> >>>> Thank you so much. Would like to suggest two more small changes,
>> >> though
>> >> >>>> not
>> >> >>>> important but it would make the things more concrete.
>> >> >>>>
>> >> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0",
>> which
>> >> >>>> should
>> >> >>>> be "2.0". If not the case then servicemix gives a warning that
>> >> "saxon
>> >> >>>> engine
>> >> >>>> is 2.0 but the stylesheet version is 1.0".
>> >> >>>>
>> >> >>>> Secondly, the saxon dependency has to be added in the pom.xml
>> file
>> >> for
>> >> >>>> XSLT
>> >> >>>> SU.
>> >> >>>>
>> >> >>>> <dependencies>
>> >> >>>> <dependency>
>> >> >>>> <groupId>org.apache.servicemix</groupId>
>> >> >>>> <artifactId>servicemix-saxon</artifactId>
>> >> >>>> <version>3.1-incubating-SNAPSHOT</version>
>> >> >>>> </dependency>
>> >> >>>> </dependencies>
>> >> >>>>
>> >> >>>> Hope this makes sense. As of know I just have these many changes
>> >> only.
>> >> >>>>
>> >> >>>> Also thanks for ur reply on the second use case. I will now work
>> on
>> >> >>>> that.
>> >> >>>>
>> >> >>>> Regards....
>> >> >>>> Gaurav
>> >> >>>>
>> >> >>>>
>> >> >>>> Gert Vanthienen wrote:
>> >> >>>>
>> >> >>>>> L.S.,
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> First of all, I have changed
>> >> >>>>>
>> >>
>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>> >> >>>>> Could you check if all necessary changes have been done? This
>> page
>> >> >>>>> will
>> >> >>>>> get replicated to the main site after a while...
>> >> >>>>>
>> >> >>>>> For your second use case: if you do not need any transformations
>> on
>> >> >>>>> the
>> >> >>>>> message content, you can create a service assembly with two
>> service
>> >> >>>>> units:
>> >> >>>>> - one SU based on servicemix-jms, defining the JMS consumer
>> >> endpoint
>> >> >>>>> to
>> >> >>>>> read messages from a JMS queue (cfr.
>> >> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>> >> >>>>> configuration options)
>> >> >>>>> - the other SU based on servicemix-http, defining the HTTP
>> provider
>> >> >>>>> endpoint which points to your webservice (cfr.
>> >> >>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>> >> >>>>> configuration options)
>> >> >>>>>
>> >> >>>>> Beware that the service/endpoint name of you HTTP provider
>> endpoint
>> >> >>>>> should match the names defined in your webservice's WSDL. You
>> can
>> >> >>>>> either use the same service/endpoint name on your JMS endpoint
>> or
>> >> use
>> >> >>>>> the targetService/targetEndpoint attributes to do the routing.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> Regards,
>> >> >>>>>
>> >> >>>>> Gert
>> >> >>>>>
>> >> >>>>> gauravsonline wrote:
>> >> >>>>>
>> >> >>>>>> HI,
>> >> >>>>>> Thanks for your help. Actualy just now I resolved the problem.
>> >> >>>>>> The problem was in the xslt-su. The archtyope by default
>> generates
>> >> >>>>>> the
>> >> >>>>>> servicemix.xml file and in the example code its xbean.xml file.
>> So
>> >> >>>>>> just
>> >> >>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>> >> >>>>>> dependency
>> >> >>>>>> was
>> >> >>>>>> ok.
>> >> >>>>>>
>> >> >>>>>> Now the next step is to read the messages from the queue and
>> call
>> >> a
>> >> >>>>>> web
>> >> >>>>>> service. Could you please help??
>> >> >>>>>>
>> >> >>>>>> Also I would like to request the moderator if they could update
>> >> this
>> >> >>>>>> thing
>> >> >>>>>> at :
>> >> >>>>>>
>> >> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >> >>>>>>
>> >> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >> >>>>>>
>> >> >>>>>> in the "XSLT SU" section, as this has costed me two days to
>> >> resolve.
>> >> >>>>>>
>> >> >>>>>> Thanks all for your help!
>> >> >>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
>> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>> > --
>> > Cheers,
>> > Guillaume Nodet
>> > ------------------------
>> > Principal Engineer, IONA
>> > Blog: http://gnodet.blogspot.com/
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10623352
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10624002
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are differentfromBridgeexample's
Posted by Guillaume Nodet <gn...@gmail.com>.
If you know how to send an HTTP request to a JMS queue,
doing the opposite is quite easy. You just need to exchange
the endpoint roles so that you will end up with an jms consumer
and an http provider.
Now, if you really need to send an object, you should use the new endpoints
that have not been released yet (download the svn sources and build the
trunk
version). The servicemix-jms BC defines two new endpoints
<jms:consumer />
and
<jms:provider />
Take a look at the code, and you will see the ConsumerMarshaler and
ProviderMarhsaler
interfaces that you can implement to override the transformation from JMS
<-> JBI.
You will be able to put your custom marhsaling code there.
On 5/15/07, gauravsonline <sa...@techmahindra.com> wrote:
>
>
> Hi,
>
> Thanks for your response.
>
> gnodet wrote:
> >
> > Now, if you want to call an external HTTP service, you need to link the
> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
> > in the servicemix distribution (and the turorial on the web site), they
> > are
> > really related to that (though it's from HTTP to JMS, but the same
> things
> > apply).
> >
>
> This part I have done already. I am able to post an xml message to the
> queue
> and called a web service.
>
> Now, the second part of it is to post the message object.
>
> gnodet wrote:
> >
> > Which onMessage are you talking about ?
> > Currently, the JMS BC mainly expects an xml and you can route the
> > exchange to jsr181 which will unmarshall it and call the pojo.
> > If you want to use a java object in the JMS message, you will have
> > to marshal it to xml on the BC side.
> >
>
> We know from J2EE that an MDB has a onMessage() method which is triggered
> when a message is pushed into the queue. We can have the business logic in
> this method for calling the target web service. My requiremnt is to
> implement the same thing using servicemix. But till now I just know about
> how to push the xml message in the jms of servicemix using http-consumer
> and
> then using then jms-provider retrieveing the messages from the queue and
> invoking the jsr-181 web service.
>
> I hope this makes the picture much clear.
>
> I have read that we can convert the message object into xml. This comes
> built-in with activemq. But how to create the SU for it. I also think of
> doing a transormation from messgae object to xml. But I do not know how to
> do it. Plz help...
>
> Thanks...
>
>
> gnodet wrote:
> >
> > Which onMessage are you talking about ?
> > Currently, the JMS BC mainly expects an xml and you can route the
> > exchange to jsr181 which will unmarshall it and call the pojo.
> > If you want to use a java object in the JMS message, you will have
> > to marshal it to xml on the BC side.
> > If you don't have a real need for using a java object inside the JMS
> > message,
> > I'd really recommand using xml if possible inside ServiceMix.
> > Now, if you want to call an external HTTP service, you need to link the
> > JMS endpoint to an HTTP endpoint. Take a look at the bridge example
> > in the servicemix distribution (and the turorial on the web site), they
> > are
> > really related to that (though it's from HTTP to JMS, but the same
> things
> > apply).
> >
> > On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
> >>
> >>
> >> Hi Gert,
> >>
> >> Thanks for the help. With little effort I got evertything working at my
> >> end.
> >> Moreover the resolution was also very precise and easy to understand.
> >>
> >> Now, suppose my queue receives a message in the object form of type
> >> "Message" and I want to typecast it to the required type. Then, after
> >> that
> >> I will invoke a webservice and pass that object as thep parameter for
> the
> >> operation (think this would be RPC call). e.g. I am posting messages of
> >> type
> >> class A in the queue (here i will use jms producer), then jms consumer
> >> will
> >> retrieve the messages of type class A. No some how I want the
> >> onMessage(Message msg) method to be trigerred. The parameter msg will
> be
> >> type casted to type class A and then I will call a webservice (i think
> it
> >> would be RPC using service stubs) which takes this obect of type A as a
> >> parameter.
> >>
> >> I was looking at the Active MQ implemenattion of it. have cerating
> >> queries
> >> related to it.
> >>
> >> 1. How can I invoke the onMessage() method throgh the jms consumer
> >> service
> >> unit?
> >> 2. How can i invoke the jsr-181 service from inside the onMessage()
> >> method?
> >>
> >> Can I implement such a scenario with in service mix end-to-end. Plz
> >> guide.
> >>
> >> Thanks.
> >>
> >>
> >>
> >> Gert Vanthienen wrote:
> >> >
> >> > L.S.,
> >> >
> >> > OK, so you have implemented and deployed a web service using the
> >> JSR-181
> >> > component. This results in an internal endpoint for
> ServiceMix. This
> >> > means that the service is accessible within the ESB itself. If you
> >> want
> >> > to make the service available to the outside world, you'll have to
> add
> >> an
> >> > external endpoint (e.g. a JMS or HTTP consumer) for the same
> >> service. So
> >> > if you just want to route between your JMS queue and the JSR-181
> >> endpoint,
> >> > you create only one JMS consumer endpoint with the same service name
> to
> >> > connect the external endpoint with the internal endpoint and you
> don't
> >> > need any of the intermediary HTTP endpoint definitions. If you want
> to
> >> > have multiple external endpoints (e.g. file poller, http consumer,
> ftp
> >> > poller, ...), you can create them and specify
> >> targetService/targetEndpoint
> >> > attributes to specify the routing to the internal endpoint.
> >> >
> >> > In your example, you've also added an HTTP provider endpoint. This
> is
> >> a
> >> > way to make an external web service available in the ESB (thus
> >> resulting
> >> > in another internal endpoint) and that's where your code sample fails
> >> > (duplicate internal endpoint names).
> >> >
> >> > Does this clarify the internal/external endpoint issue for you?
> >> >
> >> > Gert
> >> >
> >> > gauravsonline wrote:
> >> >>
> >> >> Hi Gert,
> >> >>
> >> >> I have created the consumer-jms-su and the provider-http-su and SA
> for
> >> it
> >> >> (call it as SA_retrieve). Before that I would like to explain what I
> >> have
> >> >> done till now. I have created the bridge example in SMX for sending
> >> the
> >> >> messages to the queue. I have also created a JSR 181 web service for
> >> >> echoing some message with http-consumer-su and jsr181-wsdl-first-su.
> >> >>
> >> >> I am able to deploy the SA_retrieve and the bridge example. I am
> able
> >> to
> >> >> send messages to the queue and then the SA_retrieve is able to
> >> retrieve
> >> >> the messages. The message is displyed in the SMX console and queue
> >> >> encount value is checked from JMX console.
> >> >>
> >> >> Now in order to make them all work together, I am deploying the SA
> in
> >> >> order like this bridge example, echo WS, and then the SA_retrieve
> WS.
> >> >> When I deploy the SA_retrieve WS it throws exceptions saying that
> the
> >> >> "EchoService" service name and the "EchoPort" endpoint are already
> >> >> registered to soem internal service. As you told to give the same
> >> service
> >> >> name and the endpoint as in the wsdl. But this is creating problem.
> >> For
> >> >> your reference I am attaching the configuration of all the SA for
> your
> >> >> refence:
> >> >>
> >> >> SA_retrieve:
> >> >> =========
> >> >> consumer-jms-su: xbean.xml
> >> >> ----------------------------------
> >> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
> >> >> xmlns:test="http://motorola.com/test/test_amq">
> >> >>
> >> >> <!-- START SNIPPET: consumer -->
> >> >> <jms:endpoint service="test:MyConsumerService"
> >> >> endpoint="jms"
> >> >> role="consumer"
> >> >> destinationStyle="queue"
> >> >> jmsProviderDestinationName="bridge.output"
> >> >> connectionFactory="#connectionFactory"
> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> >> defaultOperation="test:Echo" />
> >> >> <!-- END SNIPPET: consumer -->
> >> >>
> >> >> <jms:endpoint service="test:MyConsumerService"
> >> >> endpoint="jms+soap"
> >> >> targetInterfaceName="test:MyConsumerInterface"
> >> >> role="consumer"
> >> >> destinationStyle="queue"
> >> >> jmsProviderDestinationName="bridge.output"
> >> >> connectionFactory="#connectionFactory"
> >> >> soap="true"
> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> />
> >> >>
> >> >> <bean id="connectionFactory"
> >> >> class="org.apache.activemq.ActiveMQConnectionFactory">
> >> >> <property name="brokerURL" value="tcp://localhost:61616" />
> >> >> </bean>
> >> >> </beans>
> >> >>
> >> >> provider-http-su: xbean.xml
> >> >> ----------------------------------
> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> >> >> xmlns:test="http://motorola.com/test/test_amq">
> >> >>
> >> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
> >> >> service="echo:EchoService"
> >> >> endpoint="EchoPort"
> >> >> role="provider"
> >> >> locationURI="http://localhost:9999/echo/"
> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> >> soap="true"
> >> >> wsdlResource="classpath:echo.wsdl"/>
> >> >>
> >> >> </beans>
> >> >> Actually I have kept the wsdl at the path, so its that way.
> >> >>
> >> >> JSR181 WS:
> >> >> ========
> >> >> jsr181-su: xbean.xml
> >> >> --------------------------
> >> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
> >> >>
> >> >> <classpath>
> >> >> <location>.</location>
> >> >> </classpath>
> >> >>
> >> >> <jsr181:endpoint
> >> pojoClass="com.motorola.test.echo.EchoServiceImpl"
> >> >> wsdlResource="classpath:echo.wsdl"
> >> >> style="document" />
> >> >>
> >> >> </beans>
> >> >>
> >> >> jsr181-su: echo.wsdl
> >> >> -------------------------
> >> >> <?xml version="1.0" encoding="UTF-8"?>
> >> >> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> >> >> xmlns:tns="http://motorola.com/test/echo"
> >> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> >> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
> >> >> targetNamespace="http://motorola.com/test/echo">
> >> >> <wsdl:types>
> >> >> <xsd:schema
> >> >> targetNamespace="http://motorola.com/test/echo">
> >> >> <xsd:element name="Echo">
> >> >> <xsd:complexType>
> >> >> <xsd:sequence>
> >> >> <xsd:element name="in"
> >> >> type="xsd:string"></xsd:element>
> >> >> </xsd:sequence>
> >> >> </xsd:complexType>
> >> >> </xsd:element>
> >> >> <!--<xsd:element name="EchoResponse">
> >> >> <xsd:complexType>
> >> >> <xsd:sequence>
> >> >> <xsd:element
> >> name="out"
> >> >> type="xsd:string"/>
> >> >> </xsd:sequence>
> >> >> </xsd:complexType>
> >> >> </xsd:element>-->
> >> >> </xsd:schema>
> >> >> </wsdl:types>
> >> >>
> >> >> <wsdl:message name="echoRequest">
> >> >> <wsdl:part element="tns:Echo" name="in"/>
> >> >> </wsdl:message>
> >> >> <wsdl:message name="echoResponse">
> >> >> <wsdl:part type="xsd:boolean" name="out"/>
> >> >> </wsdl:message>
> >> >>
> >> >> <wsdl:portType name="EchoPortType">
> >> >> <wsdl:operation name="echo">
> >> >> <wsdl:input message="tns:echoRequest"/>
> >> >> <wsdl:output message="tns:echoResponse"/>
> >> >> </wsdl:operation>
> >> >> </wsdl:portType>
> >> >>
> >> >> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
> >> >> <soap:binding style="document"
> >> >> transport="http://schemas.xmlsoap.org/soap/http"/>
> >> >> <wsdl:operation name="echo">
> >> >> <soap:operation
> >> >> soapAction="http://motorola.com/test/echo/echo"/>
> >> >> <wsdl:input>
> >> >> <soap:body use="literal"/>
> >> >> </wsdl:input>
> >> >> <wsdl:output>
> >> >> <soap:body use="literal"/>
> >> >> </wsdl:output>
> >> >> </wsdl:operation>
> >> >> </wsdl:binding>
> >> >>
> >> >> <wsdl:service name="EchoService">
> >> >> <wsdl:port binding="tns:EchoBinding"
> name="EchoPort">
> >> >> <soap:address
> >> >> location="http://0.0.0.0:9999/echo"/>
> >> >> </wsdl:port>
> >> >> </wsdl:service>
> >> >> </wsdl:definitions>
> >> >>
> >> >> consumer-http-su: xbean.xml
> >> >> ---------------------------------
> >> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> >> >> xmlns:test="http://motorola.com/test/echo">
> >> >>
> >> >> <http:endpoint service="test:EchoService"
> >> >> endpoint="EchoPort"
> >> >> role="consumer"
> >> >> locationURI="http://0.0.0.0:9999/echo/"
> >> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> >> soap="true" />
> >> >>
> >> >> </beans>
> >> >>
> >> >> So I am using the same values for http:endpoint
> >> >> service="test:EchoService", endpoint="EchoPort" in my echo service
> >> >> consumer-http-su and in the provider-http-su of SA_reteive SA which
> is
> >> >> retrieving the messages. This duplicay is giving the problem.
> >> >>
> >> >> Please help, as I am not able to figure out to define the proper
> >> routing
> >> >> of the messages beteen SU and across SA.
> >> >>
> >> >> Regards,
> >> >> Gaurav
> >> >>
> >> >>
> >> >> Gert Vanthienen wrote:
> >> >>>
> >> >>> Guarav,
> >> >>>
> >> >>> Is this the only change that is necessary in the XSL file to switch
> >> to
> >> >>> version 2.0?
> >> >>>
> >> >>> For what the saxon dependency is concerned:
> >> >>> The previous version of the page used the
> >> >>> servicemix-lwcontainer-service-unit archetype to create the
> >> >>> bridge-xslt-su. I have changed that to use
> >> >>> servicemix-saxon-xslt-service-unit and that one should
> automatically
> >> put
> >> >>> the correct dependency in there to start with.
> >> >>>
> >> >>> Gert
> >> >>>
> >> >>> gauravsonline wrote:
> >> >>>> Thank you so much. Would like to suggest two more small changes,
> >> though
> >> >>>> not
> >> >>>> important but it would make the things more concrete.
> >> >>>>
> >> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0",
> which
> >> >>>> should
> >> >>>> be "2.0". If not the case then servicemix gives a warning that
> >> "saxon
> >> >>>> engine
> >> >>>> is 2.0 but the stylesheet version is 1.0".
> >> >>>>
> >> >>>> Secondly, the saxon dependency has to be added in the pom.xml file
> >> for
> >> >>>> XSLT
> >> >>>> SU.
> >> >>>>
> >> >>>> <dependencies>
> >> >>>> <dependency>
> >> >>>> <groupId>org.apache.servicemix</groupId>
> >> >>>> <artifactId>servicemix-saxon</artifactId>
> >> >>>> <version>3.1-incubating-SNAPSHOT</version>
> >> >>>> </dependency>
> >> >>>> </dependencies>
> >> >>>>
> >> >>>> Hope this makes sense. As of know I just have these many changes
> >> only.
> >> >>>>
> >> >>>> Also thanks for ur reply on the second use case. I will now work
> on
> >> >>>> that.
> >> >>>>
> >> >>>> Regards....
> >> >>>> Gaurav
> >> >>>>
> >> >>>>
> >> >>>> Gert Vanthienen wrote:
> >> >>>>
> >> >>>>> L.S.,
> >> >>>>>
> >> >>>>>
> >> >>>>> First of all, I have changed
> >> >>>>>
> >>
> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
> >> >>>>> Could you check if all necessary changes have been done? This
> page
> >> >>>>> will
> >> >>>>> get replicated to the main site after a while...
> >> >>>>>
> >> >>>>> For your second use case: if you do not need any transformations
> on
> >> >>>>> the
> >> >>>>> message content, you can create a service assembly with two
> service
> >> >>>>> units:
> >> >>>>> - one SU based on servicemix-jms, defining the JMS consumer
> >> endpoint
> >> >>>>> to
> >> >>>>> read messages from a JMS queue (cfr.
> >> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
> >> >>>>> configuration options)
> >> >>>>> - the other SU based on servicemix-http, defining the HTTP
> provider
> >> >>>>> endpoint which points to your webservice (cfr.
> >> >>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
> >> >>>>> configuration options)
> >> >>>>>
> >> >>>>> Beware that the service/endpoint name of you HTTP provider
> endpoint
> >> >>>>> should match the names defined in your webservice's WSDL. You
> can
> >> >>>>> either use the same service/endpoint name on your JMS endpoint or
> >> use
> >> >>>>> the targetService/targetEndpoint attributes to do the routing.
> >> >>>>>
> >> >>>>>
> >> >>>>> Regards,
> >> >>>>>
> >> >>>>> Gert
> >> >>>>>
> >> >>>>> gauravsonline wrote:
> >> >>>>>
> >> >>>>>> HI,
> >> >>>>>> Thanks for your help. Actualy just now I resolved the problem.
> >> >>>>>> The problem was in the xslt-su. The archtyope by default
> generates
> >> >>>>>> the
> >> >>>>>> servicemix.xml file and in the example code its xbean.xml file.
> So
> >> >>>>>> just
> >> >>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
> >> >>>>>> dependency
> >> >>>>>> was
> >> >>>>>> ok.
> >> >>>>>>
> >> >>>>>> Now the next step is to read the messages from the queue and
> call
> >> a
> >> >>>>>> web
> >> >>>>>> service. Could you please help??
> >> >>>>>>
> >> >>>>>> Also I would like to request the moderator if they could update
> >> this
> >> >>>>>> thing
> >> >>>>>> at :
> >> >>>>>>
> >> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
> >> >>>>>>
> >> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
> >> >>>>>>
> >> >>>>>> in the "XSLT SU" section, as this has costed me two days to
> >> resolve.
> >> >>>>>>
> >> >>>>>> Thanks all for your help!
> >> >>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
> >> Sent from the ServiceMix - User mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10623352
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Hi,
Thanks for your response.
gnodet wrote:
>
> Now, if you want to call an external HTTP service, you need to link the
> JMS endpoint to an HTTP endpoint. Take a look at the bridge example
> in the servicemix distribution (and the turorial on the web site), they
> are
> really related to that (though it's from HTTP to JMS, but the same things
> apply).
>
This part I have done already. I am able to post an xml message to the queue
and called a web service.
Now, the second part of it is to post the message object.
gnodet wrote:
>
> Which onMessage are you talking about ?
> Currently, the JMS BC mainly expects an xml and you can route the
> exchange to jsr181 which will unmarshall it and call the pojo.
> If you want to use a java object in the JMS message, you will have
> to marshal it to xml on the BC side.
>
We know from J2EE that an MDB has a onMessage() method which is triggered
when a message is pushed into the queue. We can have the business logic in
this method for calling the target web service. My requiremnt is to
implement the same thing using servicemix. But till now I just know about
how to push the xml message in the jms of servicemix using http-consumer and
then using then jms-provider retrieveing the messages from the queue and
invoking the jsr-181 web service.
I hope this makes the picture much clear.
I have read that we can convert the message object into xml. This comes
built-in with activemq. But how to create the SU for it. I also think of
doing a transormation from messgae object to xml. But I do not know how to
do it. Plz help...
Thanks...
gnodet wrote:
>
> Which onMessage are you talking about ?
> Currently, the JMS BC mainly expects an xml and you can route the
> exchange to jsr181 which will unmarshall it and call the pojo.
> If you want to use a java object in the JMS message, you will have
> to marshal it to xml on the BC side.
> If you don't have a real need for using a java object inside the JMS
> message,
> I'd really recommand using xml if possible inside ServiceMix.
> Now, if you want to call an external HTTP service, you need to link the
> JMS endpoint to an HTTP endpoint. Take a look at the bridge example
> in the servicemix distribution (and the turorial on the web site), they
> are
> really related to that (though it's from HTTP to JMS, but the same things
> apply).
>
> On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
>>
>>
>> Hi Gert,
>>
>> Thanks for the help. With little effort I got evertything working at my
>> end.
>> Moreover the resolution was also very precise and easy to understand.
>>
>> Now, suppose my queue receives a message in the object form of type
>> "Message" and I want to typecast it to the required type. Then, after
>> that
>> I will invoke a webservice and pass that object as thep parameter for the
>> operation (think this would be RPC call). e.g. I am posting messages of
>> type
>> class A in the queue (here i will use jms producer), then jms consumer
>> will
>> retrieve the messages of type class A. No some how I want the
>> onMessage(Message msg) method to be trigerred. The parameter msg will be
>> type casted to type class A and then I will call a webservice (i think it
>> would be RPC using service stubs) which takes this obect of type A as a
>> parameter.
>>
>> I was looking at the Active MQ implemenattion of it. have cerating
>> queries
>> related to it.
>>
>> 1. How can I invoke the onMessage() method throgh the jms consumer
>> service
>> unit?
>> 2. How can i invoke the jsr-181 service from inside the onMessage()
>> method?
>>
>> Can I implement such a scenario with in service mix end-to-end. Plz
>> guide.
>>
>> Thanks.
>>
>>
>>
>> Gert Vanthienen wrote:
>> >
>> > L.S.,
>> >
>> > OK, so you have implemented and deployed a web service using the
>> JSR-181
>> > component. This results in an internal endpoint for ServiceMix. This
>> > means that the service is accessible within the ESB itself. If you
>> want
>> > to make the service available to the outside world, you'll have to add
>> an
>> > external endpoint (e.g. a JMS or HTTP consumer) for the same
>> service. So
>> > if you just want to route between your JMS queue and the JSR-181
>> endpoint,
>> > you create only one JMS consumer endpoint with the same service name to
>> > connect the external endpoint with the internal endpoint and you don't
>> > need any of the intermediary HTTP endpoint definitions. If you want to
>> > have multiple external endpoints (e.g. file poller, http consumer, ftp
>> > poller, ...), you can create them and specify
>> targetService/targetEndpoint
>> > attributes to specify the routing to the internal endpoint.
>> >
>> > In your example, you've also added an HTTP provider endpoint. This is
>> a
>> > way to make an external web service available in the ESB (thus
>> resulting
>> > in another internal endpoint) and that's where your code sample fails
>> > (duplicate internal endpoint names).
>> >
>> > Does this clarify the internal/external endpoint issue for you?
>> >
>> > Gert
>> >
>> > gauravsonline wrote:
>> >>
>> >> Hi Gert,
>> >>
>> >> I have created the consumer-jms-su and the provider-http-su and SA for
>> it
>> >> (call it as SA_retrieve). Before that I would like to explain what I
>> have
>> >> done till now. I have created the bridge example in SMX for sending
>> the
>> >> messages to the queue. I have also created a JSR 181 web service for
>> >> echoing some message with http-consumer-su and jsr181-wsdl-first-su.
>> >>
>> >> I am able to deploy the SA_retrieve and the bridge example. I am able
>> to
>> >> send messages to the queue and then the SA_retrieve is able to
>> retrieve
>> >> the messages. The message is displyed in the SMX console and queue
>> >> encount value is checked from JMX console.
>> >>
>> >> Now in order to make them all work together, I am deploying the SA in
>> >> order like this bridge example, echo WS, and then the SA_retrieve WS.
>> >> When I deploy the SA_retrieve WS it throws exceptions saying that the
>> >> "EchoService" service name and the "EchoPort" endpoint are already
>> >> registered to soem internal service. As you told to give the same
>> service
>> >> name and the endpoint as in the wsdl. But this is creating problem.
>> For
>> >> your reference I am attaching the configuration of all the SA for your
>> >> refence:
>> >>
>> >> SA_retrieve:
>> >> =========
>> >> consumer-jms-su: xbean.xml
>> >> ----------------------------------
>> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
>> >> xmlns:test="http://motorola.com/test/test_amq">
>> >>
>> >> <!-- START SNIPPET: consumer -->
>> >> <jms:endpoint service="test:MyConsumerService"
>> >> endpoint="jms"
>> >> role="consumer"
>> >> destinationStyle="queue"
>> >> jmsProviderDestinationName="bridge.output"
>> >> connectionFactory="#connectionFactory"
>> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> defaultOperation="test:Echo" />
>> >> <!-- END SNIPPET: consumer -->
>> >>
>> >> <jms:endpoint service="test:MyConsumerService"
>> >> endpoint="jms+soap"
>> >> targetInterfaceName="test:MyConsumerInterface"
>> >> role="consumer"
>> >> destinationStyle="queue"
>> >> jmsProviderDestinationName="bridge.output"
>> >> connectionFactory="#connectionFactory"
>> >> soap="true"
>> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> />
>> >>
>> >> <bean id="connectionFactory"
>> >> class="org.apache.activemq.ActiveMQConnectionFactory">
>> >> <property name="brokerURL" value="tcp://localhost:61616" />
>> >> </bean>
>> >> </beans>
>> >>
>> >> provider-http-su: xbean.xml
>> >> ----------------------------------
>> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> xmlns:test="http://motorola.com/test/test_amq">
>> >>
>> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
>> >> service="echo:EchoService"
>> >> endpoint="EchoPort"
>> >> role="provider"
>> >> locationURI="http://localhost:9999/echo/"
>> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> soap="true"
>> >> wsdlResource="classpath:echo.wsdl"/>
>> >>
>> >> </beans>
>> >> Actually I have kept the wsdl at the path, so its that way.
>> >>
>> >> JSR181 WS:
>> >> ========
>> >> jsr181-su: xbean.xml
>> >> --------------------------
>> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
>> >>
>> >> <classpath>
>> >> <location>.</location>
>> >> </classpath>
>> >>
>> >> <jsr181:endpoint
>> pojoClass="com.motorola.test.echo.EchoServiceImpl"
>> >> wsdlResource="classpath:echo.wsdl"
>> >> style="document" />
>> >>
>> >> </beans>
>> >>
>> >> jsr181-su: echo.wsdl
>> >> -------------------------
>> >> <?xml version="1.0" encoding="UTF-8"?>
>> >> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>> >> xmlns:tns="http://motorola.com/test/echo"
>> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
>> >> targetNamespace="http://motorola.com/test/echo">
>> >> <wsdl:types>
>> >> <xsd:schema
>> >> targetNamespace="http://motorola.com/test/echo">
>> >> <xsd:element name="Echo">
>> >> <xsd:complexType>
>> >> <xsd:sequence>
>> >> <xsd:element name="in"
>> >> type="xsd:string"></xsd:element>
>> >> </xsd:sequence>
>> >> </xsd:complexType>
>> >> </xsd:element>
>> >> <!--<xsd:element name="EchoResponse">
>> >> <xsd:complexType>
>> >> <xsd:sequence>
>> >> <xsd:element
>> name="out"
>> >> type="xsd:string"/>
>> >> </xsd:sequence>
>> >> </xsd:complexType>
>> >> </xsd:element>-->
>> >> </xsd:schema>
>> >> </wsdl:types>
>> >>
>> >> <wsdl:message name="echoRequest">
>> >> <wsdl:part element="tns:Echo" name="in"/>
>> >> </wsdl:message>
>> >> <wsdl:message name="echoResponse">
>> >> <wsdl:part type="xsd:boolean" name="out"/>
>> >> </wsdl:message>
>> >>
>> >> <wsdl:portType name="EchoPortType">
>> >> <wsdl:operation name="echo">
>> >> <wsdl:input message="tns:echoRequest"/>
>> >> <wsdl:output message="tns:echoResponse"/>
>> >> </wsdl:operation>
>> >> </wsdl:portType>
>> >>
>> >> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
>> >> <soap:binding style="document"
>> >> transport="http://schemas.xmlsoap.org/soap/http"/>
>> >> <wsdl:operation name="echo">
>> >> <soap:operation
>> >> soapAction="http://motorola.com/test/echo/echo"/>
>> >> <wsdl:input>
>> >> <soap:body use="literal"/>
>> >> </wsdl:input>
>> >> <wsdl:output>
>> >> <soap:body use="literal"/>
>> >> </wsdl:output>
>> >> </wsdl:operation>
>> >> </wsdl:binding>
>> >>
>> >> <wsdl:service name="EchoService">
>> >> <wsdl:port binding="tns:EchoBinding" name="EchoPort">
>> >> <soap:address
>> >> location="http://0.0.0.0:9999/echo"/>
>> >> </wsdl:port>
>> >> </wsdl:service>
>> >> </wsdl:definitions>
>> >>
>> >> consumer-http-su: xbean.xml
>> >> ---------------------------------
>> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> >> xmlns:test="http://motorola.com/test/echo">
>> >>
>> >> <http:endpoint service="test:EchoService"
>> >> endpoint="EchoPort"
>> >> role="consumer"
>> >> locationURI="http://0.0.0.0:9999/echo/"
>> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> >> soap="true" />
>> >>
>> >> </beans>
>> >>
>> >> So I am using the same values for http:endpoint
>> >> service="test:EchoService", endpoint="EchoPort" in my echo service
>> >> consumer-http-su and in the provider-http-su of SA_reteive SA which is
>> >> retrieving the messages. This duplicay is giving the problem.
>> >>
>> >> Please help, as I am not able to figure out to define the proper
>> routing
>> >> of the messages beteen SU and across SA.
>> >>
>> >> Regards,
>> >> Gaurav
>> >>
>> >>
>> >> Gert Vanthienen wrote:
>> >>>
>> >>> Guarav,
>> >>>
>> >>> Is this the only change that is necessary in the XSL file to switch
>> to
>> >>> version 2.0?
>> >>>
>> >>> For what the saxon dependency is concerned:
>> >>> The previous version of the page used the
>> >>> servicemix-lwcontainer-service-unit archetype to create the
>> >>> bridge-xslt-su. I have changed that to use
>> >>> servicemix-saxon-xslt-service-unit and that one should automatically
>> put
>> >>> the correct dependency in there to start with.
>> >>>
>> >>> Gert
>> >>>
>> >>> gauravsonline wrote:
>> >>>> Thank you so much. Would like to suggest two more small changes,
>> though
>> >>>> not
>> >>>> important but it would make the things more concrete.
>> >>>>
>> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which
>> >>>> should
>> >>>> be "2.0". If not the case then servicemix gives a warning that
>> "saxon
>> >>>> engine
>> >>>> is 2.0 but the stylesheet version is 1.0".
>> >>>>
>> >>>> Secondly, the saxon dependency has to be added in the pom.xml file
>> for
>> >>>> XSLT
>> >>>> SU.
>> >>>>
>> >>>> <dependencies>
>> >>>> <dependency>
>> >>>> <groupId>org.apache.servicemix</groupId>
>> >>>> <artifactId>servicemix-saxon</artifactId>
>> >>>> <version>3.1-incubating-SNAPSHOT</version>
>> >>>> </dependency>
>> >>>> </dependencies>
>> >>>>
>> >>>> Hope this makes sense. As of know I just have these many changes
>> only.
>> >>>>
>> >>>> Also thanks for ur reply on the second use case. I will now work on
>> >>>> that.
>> >>>>
>> >>>> Regards....
>> >>>> Gaurav
>> >>>>
>> >>>>
>> >>>> Gert Vanthienen wrote:
>> >>>>
>> >>>>> L.S.,
>> >>>>>
>> >>>>>
>> >>>>> First of all, I have changed
>> >>>>>
>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>> >>>>> Could you check if all necessary changes have been done? This page
>> >>>>> will
>> >>>>> get replicated to the main site after a while...
>> >>>>>
>> >>>>> For your second use case: if you do not need any transformations on
>> >>>>> the
>> >>>>> message content, you can create a service assembly with two service
>> >>>>> units:
>> >>>>> - one SU based on servicemix-jms, defining the JMS consumer
>> endpoint
>> >>>>> to
>> >>>>> read messages from a JMS queue (cfr.
>> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>> >>>>> configuration options)
>> >>>>> - the other SU based on servicemix-http, defining the HTTP provider
>> >>>>> endpoint which points to your webservice (cfr.
>> >>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>> >>>>> configuration options)
>> >>>>>
>> >>>>> Beware that the service/endpoint name of you HTTP provider endpoint
>> >>>>> should match the names defined in your webservice's WSDL. You can
>> >>>>> either use the same service/endpoint name on your JMS endpoint or
>> use
>> >>>>> the targetService/targetEndpoint attributes to do the routing.
>> >>>>>
>> >>>>>
>> >>>>> Regards,
>> >>>>>
>> >>>>> Gert
>> >>>>>
>> >>>>> gauravsonline wrote:
>> >>>>>
>> >>>>>> HI,
>> >>>>>> Thanks for your help. Actualy just now I resolved the problem.
>> >>>>>> The problem was in the xslt-su. The archtyope by default generates
>> >>>>>> the
>> >>>>>> servicemix.xml file and in the example code its xbean.xml file. So
>> >>>>>> just
>> >>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>> >>>>>> dependency
>> >>>>>> was
>> >>>>>> ok.
>> >>>>>>
>> >>>>>> Now the next step is to read the messages from the queue and call
>> a
>> >>>>>> web
>> >>>>>> service. Could you please help??
>> >>>>>>
>> >>>>>> Also I would like to request the moderator if they could update
>> this
>> >>>>>> thing
>> >>>>>> at :
>> >>>>>>
>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >>>>>>
>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>> >>>>>>
>> >>>>>> in the "XSLT SU" section, as this has costed me two days to
>> resolve.
>> >>>>>>
>> >>>>>> Thanks all for your help!
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
>> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>>
>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10623352
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are differentfromBridgeexample's
Posted by Guillaume Nodet <gn...@gmail.com>.
Which onMessage are you talking about ?
Currently, the JMS BC mainly expects an xml and you can route the
exchange to jsr181 which will unmarshall it and call the pojo.
If you want to use a java object in the JMS message, you will have
to marshal it to xml on the BC side.
If you don't have a real need for using a java object inside the JMS
message,
I'd really recommand using xml if possible inside ServiceMix.
Now, if you want to call an external HTTP service, you need to link the
JMS endpoint to an HTTP endpoint. Take a look at the bridge example
in the servicemix distribution (and the turorial on the web site), they are
really related to that (though it's from HTTP to JMS, but the same things
apply).
On 5/14/07, gauravsonline <sa...@techmahindra.com> wrote:
>
>
> Hi Gert,
>
> Thanks for the help. With little effort I got evertything working at my
> end.
> Moreover the resolution was also very precise and easy to understand.
>
> Now, suppose my queue receives a message in the object form of type
> "Message" and I want to typecast it to the required type. Then, after
> that
> I will invoke a webservice and pass that object as thep parameter for the
> operation (think this would be RPC call). e.g. I am posting messages of
> type
> class A in the queue (here i will use jms producer), then jms consumer
> will
> retrieve the messages of type class A. No some how I want the
> onMessage(Message msg) method to be trigerred. The parameter msg will be
> type casted to type class A and then I will call a webservice (i think it
> would be RPC using service stubs) which takes this obect of type A as a
> parameter.
>
> I was looking at the Active MQ implemenattion of it. have cerating
> queries
> related to it.
>
> 1. How can I invoke the onMessage() method throgh the jms consumer service
> unit?
> 2. How can i invoke the jsr-181 service from inside the onMessage()
> method?
>
> Can I implement such a scenario with in service mix end-to-end. Plz guide.
>
> Thanks.
>
>
>
> Gert Vanthienen wrote:
> >
> > L.S.,
> >
> > OK, so you have implemented and deployed a web service using the JSR-181
> > component. This results in an internal endpoint for ServiceMix. This
> > means that the service is accessible within the ESB itself. If you want
> > to make the service available to the outside world, you'll have to add
> an
> > external endpoint (e.g. a JMS or HTTP consumer) for the same
> service. So
> > if you just want to route between your JMS queue and the JSR-181
> endpoint,
> > you create only one JMS consumer endpoint with the same service name to
> > connect the external endpoint with the internal endpoint and you don't
> > need any of the intermediary HTTP endpoint definitions. If you want to
> > have multiple external endpoints (e.g. file poller, http consumer, ftp
> > poller, ...), you can create them and specify
> targetService/targetEndpoint
> > attributes to specify the routing to the internal endpoint.
> >
> > In your example, you've also added an HTTP provider endpoint. This is a
> > way to make an external web service available in the ESB (thus resulting
> > in another internal endpoint) and that's where your code sample fails
> > (duplicate internal endpoint names).
> >
> > Does this clarify the internal/external endpoint issue for you?
> >
> > Gert
> >
> > gauravsonline wrote:
> >>
> >> Hi Gert,
> >>
> >> I have created the consumer-jms-su and the provider-http-su and SA for
> it
> >> (call it as SA_retrieve). Before that I would like to explain what I
> have
> >> done till now. I have created the bridge example in SMX for sending the
> >> messages to the queue. I have also created a JSR 181 web service for
> >> echoing some message with http-consumer-su and jsr181-wsdl-first-su.
> >>
> >> I am able to deploy the SA_retrieve and the bridge example. I am able
> to
> >> send messages to the queue and then the SA_retrieve is able to retrieve
> >> the messages. The message is displyed in the SMX console and queue
> >> encount value is checked from JMX console.
> >>
> >> Now in order to make them all work together, I am deploying the SA in
> >> order like this bridge example, echo WS, and then the SA_retrieve WS.
> >> When I deploy the SA_retrieve WS it throws exceptions saying that the
> >> "EchoService" service name and the "EchoPort" endpoint are already
> >> registered to soem internal service. As you told to give the same
> service
> >> name and the endpoint as in the wsdl. But this is creating problem. For
> >> your reference I am attaching the configuration of all the SA for your
> >> refence:
> >>
> >> SA_retrieve:
> >> =========
> >> consumer-jms-su: xbean.xml
> >> ----------------------------------
> >> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
> >> xmlns:test="http://motorola.com/test/test_amq">
> >>
> >> <!-- START SNIPPET: consumer -->
> >> <jms:endpoint service="test:MyConsumerService"
> >> endpoint="jms"
> >> role="consumer"
> >> destinationStyle="queue"
> >> jmsProviderDestinationName="bridge.output"
> >> connectionFactory="#connectionFactory"
> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> defaultOperation="test:Echo" />
> >> <!-- END SNIPPET: consumer -->
> >>
> >> <jms:endpoint service="test:MyConsumerService"
> >> endpoint="jms+soap"
> >> targetInterfaceName="test:MyConsumerInterface"
> >> role="consumer"
> >> destinationStyle="queue"
> >> jmsProviderDestinationName="bridge.output"
> >> connectionFactory="#connectionFactory"
> >> soap="true"
> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
> >>
> >> <bean id="connectionFactory"
> >> class="org.apache.activemq.ActiveMQConnectionFactory">
> >> <property name="brokerURL" value="tcp://localhost:61616" />
> >> </bean>
> >> </beans>
> >>
> >> provider-http-su: xbean.xml
> >> ----------------------------------
> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> >> xmlns:test="http://motorola.com/test/test_amq">
> >>
> >> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
> >> service="echo:EchoService"
> >> endpoint="EchoPort"
> >> role="provider"
> >> locationURI="http://localhost:9999/echo/"
> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> soap="true"
> >> wsdlResource="classpath:echo.wsdl"/>
> >>
> >> </beans>
> >> Actually I have kept the wsdl at the path, so its that way.
> >>
> >> JSR181 WS:
> >> ========
> >> jsr181-su: xbean.xml
> >> --------------------------
> >> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
> >>
> >> <classpath>
> >> <location>.</location>
> >> </classpath>
> >>
> >> <jsr181:endpoint pojoClass="com.motorola.test.echo.EchoServiceImpl"
> >> wsdlResource="classpath:echo.wsdl"
> >> style="document" />
> >>
> >> </beans>
> >>
> >> jsr181-su: echo.wsdl
> >> -------------------------
> >> <?xml version="1.0" encoding="UTF-8"?>
> >> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> >> xmlns:tns="http://motorola.com/test/echo"
> >> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
> >> targetNamespace="http://motorola.com/test/echo">
> >> <wsdl:types>
> >> <xsd:schema
> >> targetNamespace="http://motorola.com/test/echo">
> >> <xsd:element name="Echo">
> >> <xsd:complexType>
> >> <xsd:sequence>
> >> <xsd:element name="in"
> >> type="xsd:string"></xsd:element>
> >> </xsd:sequence>
> >> </xsd:complexType>
> >> </xsd:element>
> >> <!--<xsd:element name="EchoResponse">
> >> <xsd:complexType>
> >> <xsd:sequence>
> >> <xsd:element name="out"
> >> type="xsd:string"/>
> >> </xsd:sequence>
> >> </xsd:complexType>
> >> </xsd:element>-->
> >> </xsd:schema>
> >> </wsdl:types>
> >>
> >> <wsdl:message name="echoRequest">
> >> <wsdl:part element="tns:Echo" name="in"/>
> >> </wsdl:message>
> >> <wsdl:message name="echoResponse">
> >> <wsdl:part type="xsd:boolean" name="out"/>
> >> </wsdl:message>
> >>
> >> <wsdl:portType name="EchoPortType">
> >> <wsdl:operation name="echo">
> >> <wsdl:input message="tns:echoRequest"/>
> >> <wsdl:output message="tns:echoResponse"/>
> >> </wsdl:operation>
> >> </wsdl:portType>
> >>
> >> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
> >> <soap:binding style="document"
> >> transport="http://schemas.xmlsoap.org/soap/http"/>
> >> <wsdl:operation name="echo">
> >> <soap:operation
> >> soapAction="http://motorola.com/test/echo/echo"/>
> >> <wsdl:input>
> >> <soap:body use="literal"/>
> >> </wsdl:input>
> >> <wsdl:output>
> >> <soap:body use="literal"/>
> >> </wsdl:output>
> >> </wsdl:operation>
> >> </wsdl:binding>
> >>
> >> <wsdl:service name="EchoService">
> >> <wsdl:port binding="tns:EchoBinding" name="EchoPort">
> >> <soap:address
> >> location="http://0.0.0.0:9999/echo"/>
> >> </wsdl:port>
> >> </wsdl:service>
> >> </wsdl:definitions>
> >>
> >> consumer-http-su: xbean.xml
> >> ---------------------------------
> >> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> >> xmlns:test="http://motorola.com/test/echo">
> >>
> >> <http:endpoint service="test:EchoService"
> >> endpoint="EchoPort"
> >> role="consumer"
> >> locationURI="http://0.0.0.0:9999/echo/"
> >> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> >> soap="true" />
> >>
> >> </beans>
> >>
> >> So I am using the same values for http:endpoint
> >> service="test:EchoService", endpoint="EchoPort" in my echo service
> >> consumer-http-su and in the provider-http-su of SA_reteive SA which is
> >> retrieving the messages. This duplicay is giving the problem.
> >>
> >> Please help, as I am not able to figure out to define the proper
> routing
> >> of the messages beteen SU and across SA.
> >>
> >> Regards,
> >> Gaurav
> >>
> >>
> >> Gert Vanthienen wrote:
> >>>
> >>> Guarav,
> >>>
> >>> Is this the only change that is necessary in the XSL file to switch to
> >>> version 2.0?
> >>>
> >>> For what the saxon dependency is concerned:
> >>> The previous version of the page used the
> >>> servicemix-lwcontainer-service-unit archetype to create the
> >>> bridge-xslt-su. I have changed that to use
> >>> servicemix-saxon-xslt-service-unit and that one should automatically
> put
> >>> the correct dependency in there to start with.
> >>>
> >>> Gert
> >>>
> >>> gauravsonline wrote:
> >>>> Thank you so much. Would like to suggest two more small changes,
> though
> >>>> not
> >>>> important but it would make the things more concrete.
> >>>>
> >>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which
> >>>> should
> >>>> be "2.0". If not the case then servicemix gives a warning that "saxon
> >>>> engine
> >>>> is 2.0 but the stylesheet version is 1.0".
> >>>>
> >>>> Secondly, the saxon dependency has to be added in the pom.xml file
> for
> >>>> XSLT
> >>>> SU.
> >>>>
> >>>> <dependencies>
> >>>> <dependency>
> >>>> <groupId>org.apache.servicemix</groupId>
> >>>> <artifactId>servicemix-saxon</artifactId>
> >>>> <version>3.1-incubating-SNAPSHOT</version>
> >>>> </dependency>
> >>>> </dependencies>
> >>>>
> >>>> Hope this makes sense. As of know I just have these many changes
> only.
> >>>>
> >>>> Also thanks for ur reply on the second use case. I will now work on
> >>>> that.
> >>>>
> >>>> Regards....
> >>>> Gaurav
> >>>>
> >>>>
> >>>> Gert Vanthienen wrote:
> >>>>
> >>>>> L.S.,
> >>>>>
> >>>>>
> >>>>> First of all, I have changed
> >>>>>
> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
> >>>>> Could you check if all necessary changes have been done? This page
> >>>>> will
> >>>>> get replicated to the main site after a while...
> >>>>>
> >>>>> For your second use case: if you do not need any transformations on
> >>>>> the
> >>>>> message content, you can create a service assembly with two service
> >>>>> units:
> >>>>> - one SU based on servicemix-jms, defining the JMS consumer endpoint
> >>>>> to
> >>>>> read messages from a JMS queue (cfr.
> >>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
> >>>>> configuration options)
> >>>>> - the other SU based on servicemix-http, defining the HTTP provider
> >>>>> endpoint which points to your webservice (cfr.
> >>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
> >>>>> configuration options)
> >>>>>
> >>>>> Beware that the service/endpoint name of you HTTP provider endpoint
> >>>>> should match the names defined in your webservice's WSDL. You can
> >>>>> either use the same service/endpoint name on your JMS endpoint or
> use
> >>>>> the targetService/targetEndpoint attributes to do the routing.
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Gert
> >>>>>
> >>>>> gauravsonline wrote:
> >>>>>
> >>>>>> HI,
> >>>>>> Thanks for your help. Actualy just now I resolved the problem.
> >>>>>> The problem was in the xslt-su. The archtyope by default generates
> >>>>>> the
> >>>>>> servicemix.xml file and in the example code its xbean.xml file. So
> >>>>>> just
> >>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
> >>>>>> dependency
> >>>>>> was
> >>>>>> ok.
> >>>>>>
> >>>>>> Now the next step is to read the messages from the queue and call a
> >>>>>> web
> >>>>>> service. Could you please help??
> >>>>>>
> >>>>>> Also I would like to request the moderator if they could update
> this
> >>>>>> thing
> >>>>>> at :
> >>>>>>
> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
> >>>>>>
> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
> >>>>>>
> >>>>>> in the "XSLT SU" section, as this has costed me two days to
> resolve.
> >>>>>>
> >>>>>> Thanks all for your help!
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Hi Gert,
Thanks for the help. With little effort I got evertything working at my end.
Moreover the resolution was also very precise and easy to understand.
Now, suppose my queue receives a message in the object form of type
"Message" and I want to typecast it to the required type. Then, after that
I will invoke a webservice and pass that object as thep parameter for the
operation (think this would be RPC call). e.g. I am posting messages of type
class A in the queue (here i will use jms producer), then jms consumer will
retrieve the messages of type class A. No some how I want the
onMessage(Message msg) method to be trigerred. The parameter msg will be
type casted to type class A and then I will call a webservice (i think it
would be RPC using service stubs) which takes this obect of type A as a
parameter.
I was looking at the Active MQ implemenattion of it. have cerating queries
related to it.
1. How can I invoke the onMessage() method throgh the jms consumer service
unit?
2. How can i invoke the jsr-181 service from inside the onMessage() method?
Can I implement such a scenario with in service mix end-to-end. Plz guide.
Thanks.
Gert Vanthienen wrote:
>
> L.S.,
>
> OK, so you have implemented and deployed a web service using the JSR-181
> component. This results in an internal endpoint for ServiceMix. This
> means that the service is accessible within the ESB itself. If you want
> to make the service available to the outside world, you'll have to add an
> external endpoint (e.g. a JMS or HTTP consumer) for the same service. So
> if you just want to route between your JMS queue and the JSR-181 endpoint,
> you create only one JMS consumer endpoint with the same service name to
> connect the external endpoint with the internal endpoint and you don't
> need any of the intermediary HTTP endpoint definitions. If you want to
> have multiple external endpoints (e.g. file poller, http consumer, ftp
> poller, ...), you can create them and specify targetService/targetEndpoint
> attributes to specify the routing to the internal endpoint.
>
> In your example, you've also added an HTTP provider endpoint. This is a
> way to make an external web service available in the ESB (thus resulting
> in another internal endpoint) and that's where your code sample fails
> (duplicate internal endpoint names).
>
> Does this clarify the internal/external endpoint issue for you?
>
> Gert
>
> gauravsonline wrote:
>>
>> Hi Gert,
>>
>> I have created the consumer-jms-su and the provider-http-su and SA for it
>> (call it as SA_retrieve). Before that I would like to explain what I have
>> done till now. I have created the bridge example in SMX for sending the
>> messages to the queue. I have also created a JSR 181 web service for
>> echoing some message with http-consumer-su and jsr181-wsdl-first-su.
>>
>> I am able to deploy the SA_retrieve and the bridge example. I am able to
>> send messages to the queue and then the SA_retrieve is able to retrieve
>> the messages. The message is displyed in the SMX console and queue
>> encount value is checked from JMX console.
>>
>> Now in order to make them all work together, I am deploying the SA in
>> order like this bridge example, echo WS, and then the SA_retrieve WS.
>> When I deploy the SA_retrieve WS it throws exceptions saying that the
>> "EchoService" service name and the "EchoPort" endpoint are already
>> registered to soem internal service. As you told to give the same service
>> name and the endpoint as in the wsdl. But this is creating problem. For
>> your reference I am attaching the configuration of all the SA for your
>> refence:
>>
>> SA_retrieve:
>> =========
>> consumer-jms-su: xbean.xml
>> ----------------------------------
>> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
>> xmlns:test="http://motorola.com/test/test_amq">
>>
>> <!-- START SNIPPET: consumer -->
>> <jms:endpoint service="test:MyConsumerService"
>> endpoint="jms"
>> role="consumer"
>> destinationStyle="queue"
>> jmsProviderDestinationName="bridge.output"
>> connectionFactory="#connectionFactory"
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> defaultOperation="test:Echo" />
>> <!-- END SNIPPET: consumer -->
>>
>> <jms:endpoint service="test:MyConsumerService"
>> endpoint="jms+soap"
>> targetInterfaceName="test:MyConsumerInterface"
>> role="consumer"
>> destinationStyle="queue"
>> jmsProviderDestinationName="bridge.output"
>> connectionFactory="#connectionFactory"
>> soap="true"
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
>>
>> <bean id="connectionFactory"
>> class="org.apache.activemq.ActiveMQConnectionFactory">
>> <property name="brokerURL" value="tcp://localhost:61616" />
>> </bean>
>> </beans>
>>
>> provider-http-su: xbean.xml
>> ----------------------------------
>> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> xmlns:test="http://motorola.com/test/test_amq">
>>
>> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
>> service="echo:EchoService"
>> endpoint="EchoPort"
>> role="provider"
>> locationURI="http://localhost:9999/echo/"
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> soap="true"
>> wsdlResource="classpath:echo.wsdl"/>
>>
>> </beans>
>> Actually I have kept the wsdl at the path, so its that way.
>>
>> JSR181 WS:
>> ========
>> jsr181-su: xbean.xml
>> --------------------------
>> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
>>
>> <classpath>
>> <location>.</location>
>> </classpath>
>>
>> <jsr181:endpoint pojoClass="com.motorola.test.echo.EchoServiceImpl"
>> wsdlResource="classpath:echo.wsdl"
>> style="document" />
>>
>> </beans>
>>
>> jsr181-su: echo.wsdl
>> -------------------------
>> <?xml version="1.0" encoding="UTF-8"?>
>> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>> xmlns:tns="http://motorola.com/test/echo"
>> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
>> targetNamespace="http://motorola.com/test/echo">
>> <wsdl:types>
>> <xsd:schema
>> targetNamespace="http://motorola.com/test/echo">
>> <xsd:element name="Echo">
>> <xsd:complexType>
>> <xsd:sequence>
>> <xsd:element name="in"
>> type="xsd:string"></xsd:element>
>> </xsd:sequence>
>> </xsd:complexType>
>> </xsd:element>
>> <!--<xsd:element name="EchoResponse">
>> <xsd:complexType>
>> <xsd:sequence>
>> <xsd:element name="out"
>> type="xsd:string"/>
>> </xsd:sequence>
>> </xsd:complexType>
>> </xsd:element>-->
>> </xsd:schema>
>> </wsdl:types>
>>
>> <wsdl:message name="echoRequest">
>> <wsdl:part element="tns:Echo" name="in"/>
>> </wsdl:message>
>> <wsdl:message name="echoResponse">
>> <wsdl:part type="xsd:boolean" name="out"/>
>> </wsdl:message>
>>
>> <wsdl:portType name="EchoPortType">
>> <wsdl:operation name="echo">
>> <wsdl:input message="tns:echoRequest"/>
>> <wsdl:output message="tns:echoResponse"/>
>> </wsdl:operation>
>> </wsdl:portType>
>>
>> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
>> <soap:binding style="document"
>> transport="http://schemas.xmlsoap.org/soap/http"/>
>> <wsdl:operation name="echo">
>> <soap:operation
>> soapAction="http://motorola.com/test/echo/echo"/>
>> <wsdl:input>
>> <soap:body use="literal"/>
>> </wsdl:input>
>> <wsdl:output>
>> <soap:body use="literal"/>
>> </wsdl:output>
>> </wsdl:operation>
>> </wsdl:binding>
>>
>> <wsdl:service name="EchoService">
>> <wsdl:port binding="tns:EchoBinding" name="EchoPort">
>> <soap:address
>> location="http://0.0.0.0:9999/echo"/>
>> </wsdl:port>
>> </wsdl:service>
>> </wsdl:definitions>
>>
>> consumer-http-su: xbean.xml
>> ---------------------------------
>> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
>> xmlns:test="http://motorola.com/test/echo">
>>
>> <http:endpoint service="test:EchoService"
>> endpoint="EchoPort"
>> role="consumer"
>> locationURI="http://0.0.0.0:9999/echo/"
>> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
>> soap="true" />
>>
>> </beans>
>>
>> So I am using the same values for http:endpoint
>> service="test:EchoService", endpoint="EchoPort" in my echo service
>> consumer-http-su and in the provider-http-su of SA_reteive SA which is
>> retrieving the messages. This duplicay is giving the problem.
>>
>> Please help, as I am not able to figure out to define the proper routing
>> of the messages beteen SU and across SA.
>>
>> Regards,
>> Gaurav
>>
>>
>> Gert Vanthienen wrote:
>>>
>>> Guarav,
>>>
>>> Is this the only change that is necessary in the XSL file to switch to
>>> version 2.0?
>>>
>>> For what the saxon dependency is concerned:
>>> The previous version of the page used the
>>> servicemix-lwcontainer-service-unit archetype to create the
>>> bridge-xslt-su. I have changed that to use
>>> servicemix-saxon-xslt-service-unit and that one should automatically put
>>> the correct dependency in there to start with.
>>>
>>> Gert
>>>
>>> gauravsonline wrote:
>>>> Thank you so much. Would like to suggest two more small changes, though
>>>> not
>>>> important but it would make the things more concrete.
>>>>
>>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which
>>>> should
>>>> be "2.0". If not the case then servicemix gives a warning that "saxon
>>>> engine
>>>> is 2.0 but the stylesheet version is 1.0".
>>>>
>>>> Secondly, the saxon dependency has to be added in the pom.xml file for
>>>> XSLT
>>>> SU.
>>>>
>>>> <dependencies>
>>>> <dependency>
>>>> <groupId>org.apache.servicemix</groupId>
>>>> <artifactId>servicemix-saxon</artifactId>
>>>> <version>3.1-incubating-SNAPSHOT</version>
>>>> </dependency>
>>>> </dependencies>
>>>>
>>>> Hope this makes sense. As of know I just have these many changes only.
>>>>
>>>> Also thanks for ur reply on the second use case. I will now work on
>>>> that.
>>>>
>>>> Regards....
>>>> Gaurav
>>>>
>>>>
>>>> Gert Vanthienen wrote:
>>>>
>>>>> L.S.,
>>>>>
>>>>>
>>>>> First of all, I have changed
>>>>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>>>>> Could you check if all necessary changes have been done? This page
>>>>> will
>>>>> get replicated to the main site after a while...
>>>>>
>>>>> For your second use case: if you do not need any transformations on
>>>>> the
>>>>> message content, you can create a service assembly with two service
>>>>> units:
>>>>> - one SU based on servicemix-jms, defining the JMS consumer endpoint
>>>>> to
>>>>> read messages from a JMS queue (cfr.
>>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>>>>> configuration options)
>>>>> - the other SU based on servicemix-http, defining the HTTP provider
>>>>> endpoint which points to your webservice (cfr.
>>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>>>>> configuration options)
>>>>>
>>>>> Beware that the service/endpoint name of you HTTP provider endpoint
>>>>> should match the names defined in your webservice's WSDL. You can
>>>>> either use the same service/endpoint name on your JMS endpoint or use
>>>>> the targetService/targetEndpoint attributes to do the routing.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Gert
>>>>>
>>>>> gauravsonline wrote:
>>>>>
>>>>>> HI,
>>>>>> Thanks for your help. Actualy just now I resolved the problem.
>>>>>> The problem was in the xslt-su. The archtyope by default generates
>>>>>> the
>>>>>> servicemix.xml file and in the example code its xbean.xml file. So
>>>>>> just
>>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>>>>>> dependency
>>>>>> was
>>>>>> ok.
>>>>>>
>>>>>> Now the next step is to read the messages from the queue and call a
>>>>>> web
>>>>>> service. Could you please help??
>>>>>>
>>>>>> Also I would like to request the moderator if they could update this
>>>>>> thing
>>>>>> at :
>>>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>>>>
>>>>>> in the "XSLT SU" section, as this has costed me two days to resolve.
>>>>>>
>>>>>> Thanks all for your help!
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10601663
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by Gert Vanthienen <ge...@skynet.be>.
L.S.,
OK, so you have implemented and deployed a web service using the JSR-181
component. This results in an internal endpoint for ServiceMix. This means
that the service is accessible within the ESB itself. If you want to make
the service available to the outside world, you'll have to add an external
endpoint (e.g. a JMS or HTTP consumer) for the same service. So if you just
want to route between your JMS queue and the JSR-181 endpoint, you create
only one JMS consumer endpoint with the same service name to connect the
external endpoint with the internal endpoint and you don't need any of the
intermediary HTTP endpoint definitions. If you want to have multiple
external endpoints (e.g. file poller, http consumer, ftp poller, ...), you
can create them and specify targetService/targetEndpoint attributes to
specify the routing to the internal endpoint.
In your example, you've also added an HTTP provider endpoint. This is a way
to make an external web service available in the ESB (thus resulting in
another internal endpoint) and that's where your code sample fails
(duplicate internal endpoint names).
Does this clarify the internal/external endpoint issue for you?
Gert
gauravsonline wrote:
>
> Hi Gert,
>
> I have created the consumer-jms-su and the provider-http-su and SA for it
> (call it as SA_retrieve). Before that I would like to explain what I have
> done till now. I have created the bridge example in SMX for sending the
> messages to the queue. I have also created a JSR 181 web service for
> echoing some message with http-consumer-su and jsr181-wsdl-first-su.
>
> I am able to deploy the SA_retrieve and the bridge example. I am able to
> send messages to the queue and then the SA_retrieve is able to retrieve
> the messages. The message is displyed in the SMX console and queue encount
> value is checked from JMX console.
>
> Now in order to make them all work together, I am deploying the SA in
> order like this bridge example, echo WS, and then the SA_retrieve WS. When
> I deploy the SA_retrieve WS it throws exceptions saying that the
> "EchoService" service name and the "EchoPort" endpoint are already
> registered to soem internal service. As you told to give the same service
> name and the endpoint as in the wsdl. But this is creating problem. For
> your reference I am attaching the configuration of all the SA for your
> refence:
>
> SA_retrieve:
> =========
> consumer-jms-su: xbean.xml
> ----------------------------------
> <beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
> xmlns:test="http://motorola.com/test/test_amq">
>
> <!-- START SNIPPET: consumer -->
> <jms:endpoint service="test:MyConsumerService"
> endpoint="jms"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="bridge.output"
> connectionFactory="#connectionFactory"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> defaultOperation="test:Echo" />
> <!-- END SNIPPET: consumer -->
>
> <jms:endpoint service="test:MyConsumerService"
> endpoint="jms+soap"
> targetInterfaceName="test:MyConsumerInterface"
> role="consumer"
> destinationStyle="queue"
> jmsProviderDestinationName="bridge.output"
> connectionFactory="#connectionFactory"
> soap="true"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
>
> <bean id="connectionFactory"
> class="org.apache.activemq.ActiveMQConnectionFactory">
> <property name="brokerURL" value="tcp://localhost:61616" />
> </bean>
> </beans>
>
> provider-http-su: xbean.xml
> ----------------------------------
> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> xmlns:test="http://motorola.com/test/test_amq">
>
> <http:endpoint xmlns:echo="http://motorola.com/test/echo"
> service="echo:EchoService"
> endpoint="EchoPort"
> role="provider"
> locationURI="http://localhost:9999/echo/"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> soap="true"
> wsdlResource="classpath:echo.wsdl"/>
>
> </beans>
> Actually I have kept the wsdl at the path, so its that way.
>
> JSR181 WS:
> ========
> jsr181-su: xbean.xml
> --------------------------
> <beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
>
> <classpath>
> <location>.</location>
> </classpath>
>
> <jsr181:endpoint pojoClass="com.motorola.test.echo.EchoServiceImpl"
> wsdlResource="classpath:echo.wsdl"
> style="document" />
>
> </beans>
>
> jsr181-su: echo.wsdl
> -------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:tns="http://motorola.com/test/echo"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
> targetNamespace="http://motorola.com/test/echo">
> <wsdl:types>
> <xsd:schema
> targetNamespace="http://motorola.com/test/echo">
> <xsd:element name="Echo">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="in"
> type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> <!--<xsd:element name="EchoResponse">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="out"
> type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>-->
> </xsd:schema>
> </wsdl:types>
>
> <wsdl:message name="echoRequest">
> <wsdl:part element="tns:Echo" name="in"/>
> </wsdl:message>
> <wsdl:message name="echoResponse">
> <wsdl:part type="xsd:boolean" name="out"/>
> </wsdl:message>
>
> <wsdl:portType name="EchoPortType">
> <wsdl:operation name="echo">
> <wsdl:input message="tns:echoRequest"/>
> <wsdl:output message="tns:echoResponse"/>
> </wsdl:operation>
> </wsdl:portType>
>
> <wsdl:binding name="EchoBinding" type="tns:EchoPortType">
> <soap:binding style="document"
> transport="http://schemas.xmlsoap.org/soap/http"/>
> <wsdl:operation name="echo">
> <soap:operation
> soapAction="http://motorola.com/test/echo/echo"/>
> <wsdl:input>
> <soap:body use="literal"/>
> </wsdl:input>
> <wsdl:output>
> <soap:body use="literal"/>
> </wsdl:output>
> </wsdl:operation>
> </wsdl:binding>
>
> <wsdl:service name="EchoService">
> <wsdl:port binding="tns:EchoBinding" name="EchoPort">
> <soap:address
> location="http://0.0.0.0:9999/echo"/>
> </wsdl:port>
> </wsdl:service>
> </wsdl:definitions>
>
> consumer-http-su: xbean.xml
> ---------------------------------
> <beans xmlns:http="http://servicemix.apache.org/http/1.0"
> xmlns:test="http://motorola.com/test/echo">
>
> <http:endpoint service="test:EchoService"
> endpoint="EchoPort"
> role="consumer"
> locationURI="http://0.0.0.0:9999/echo/"
> defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
> soap="true" />
>
> </beans>
>
> So I am using the same values for http:endpoint
> service="test:EchoService", endpoint="EchoPort" in my echo service
> consumer-http-su and in the provider-http-su of SA_reteive SA which is
> retrieving the messages. This duplicay is giving the problem.
>
> Please help, as I am not able to figure out to define the proper routing
> of the messages beteen SU and across SA.
>
> Regards,
> Gaurav
>
>
> Gert Vanthienen wrote:
>>
>> Guarav,
>>
>> Is this the only change that is necessary in the XSL file to switch to
>> version 2.0?
>>
>> For what the saxon dependency is concerned:
>> The previous version of the page used the
>> servicemix-lwcontainer-service-unit archetype to create the
>> bridge-xslt-su. I have changed that to use
>> servicemix-saxon-xslt-service-unit and that one should automatically put
>> the correct dependency in there to start with.
>>
>> Gert
>>
>> gauravsonline wrote:
>>> Thank you so much. Would like to suggest two more small changes, though
>>> not
>>> important but it would make the things more concrete.
>>>
>>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which
>>> should
>>> be "2.0". If not the case then servicemix gives a warning that "saxon
>>> engine
>>> is 2.0 but the stylesheet version is 1.0".
>>>
>>> Secondly, the saxon dependency has to be added in the pom.xml file for
>>> XSLT
>>> SU.
>>>
>>> <dependencies>
>>> <dependency>
>>> <groupId>org.apache.servicemix</groupId>
>>> <artifactId>servicemix-saxon</artifactId>
>>> <version>3.1-incubating-SNAPSHOT</version>
>>> </dependency>
>>> </dependencies>
>>>
>>> Hope this makes sense. As of know I just have these many changes only.
>>>
>>> Also thanks for ur reply on the second use case. I will now work on
>>> that.
>>>
>>> Regards....
>>> Gaurav
>>>
>>>
>>> Gert Vanthienen wrote:
>>>
>>>> L.S.,
>>>>
>>>>
>>>> First of all, I have changed
>>>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>>>> Could you check if all necessary changes have been done? This page
>>>> will
>>>> get replicated to the main site after a while...
>>>>
>>>> For your second use case: if you do not need any transformations on the
>>>> message content, you can create a service assembly with two service
>>>> units:
>>>> - one SU based on servicemix-jms, defining the JMS consumer endpoint to
>>>> read messages from a JMS queue (cfr.
>>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>>>> configuration options)
>>>> - the other SU based on servicemix-http, defining the HTTP provider
>>>> endpoint which points to your webservice (cfr.
>>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>>>> configuration options)
>>>>
>>>> Beware that the service/endpoint name of you HTTP provider endpoint
>>>> should match the names defined in your webservice's WSDL. You can
>>>> either use the same service/endpoint name on your JMS endpoint or use
>>>> the targetService/targetEndpoint attributes to do the routing.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Gert
>>>>
>>>> gauravsonline wrote:
>>>>
>>>>> HI,
>>>>> Thanks for your help. Actualy just now I resolved the problem.
>>>>> The problem was in the xslt-su. The archtyope by default generates the
>>>>> servicemix.xml file and in the example code its xbean.xml file. So
>>>>> just
>>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>>>>> dependency
>>>>> was
>>>>> ok.
>>>>>
>>>>> Now the next step is to read the messages from the queue and call a
>>>>> web
>>>>> service. Could you please help??
>>>>>
>>>>> Also I would like to request the moderator if they could update this
>>>>> thing
>>>>> at :
>>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>>>
>>>>> in the "XSLT SU" section, as this has costed me two days to resolve.
>>>>>
>>>>> Thanks all for your help!
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10458081
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Hi Gert,
I have created the consumer-jms-su and the provider-http-su and SA for it
(call it as SA_retrieve). Before that I would like to explain what I have
done till now. I have created the bridge example in SMX for sending the
messages to the queue. I have also created a JSR 181 web service for echoing
some message with http-consumer-su and jsr181-wsdl-first-su.
I am able to deploy the SA_retrieve and the bridge example. I am able to
send messages to the queue and then the SA_retrieve is able to retrieve the
messages. The message is displyed in the SMX console and queue encount value
is checked from JMX console.
Now in order to make them all work together, I am deploying the SA in order
like this bridge example, echo WS, and then the SA_retrieve WS. When I
deploy the SA_retrieve WS it throws exceptions saying that the "EchoService"
service name and the "EchoPort" endpoint are already registered to soem
internal service. As you told to give the same service name and the endpoint
as in the wsdl. But this is creating problem. For your reference I am
attaching the configuration of all the SA for your refence:
SA_retrieve:
=========
consumer-jms-su: xbean.xml
----------------------------------
<beans xmlns:jms="http://servicemix.apache.org/jms/1.0"
xmlns:test="http://motorola.com/test/test_amq">
<!-- START SNIPPET: consumer -->
<jms:endpoint service="test:MyConsumerService"
endpoint="jms"
role="consumer"
destinationStyle="queue"
jmsProviderDestinationName="bridge.output"
connectionFactory="#connectionFactory"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
defaultOperation="test:Echo" />
<!-- END SNIPPET: consumer -->
<jms:endpoint service="test:MyConsumerService"
endpoint="jms+soap"
targetInterfaceName="test:MyConsumerInterface"
role="consumer"
destinationStyle="queue"
jmsProviderDestinationName="bridge.output"
connectionFactory="#connectionFactory"
soap="true"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out" />
<bean id="connectionFactory"
class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://localhost:61616" />
</bean>
</beans>
provider-http-su: xbean.xml
----------------------------------
<beans xmlns:http="http://servicemix.apache.org/http/1.0"
xmlns:test="http://motorola.com/test/test_amq">
<http:endpoint xmlns:echo="http://motorola.com/test/echo"
service="echo:EchoService"
endpoint="EchoPort"
role="provider"
locationURI="http://localhost:9999/echo/"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
soap="true"
wsdlResource="classpath:echo.wsdl"/>
</beans>
Actually I have kept the wsdl at the path, so its that way.
JSR181 WS:
========
jsr181-su: xbean.xml
--------------------------
<beans xmlns:jsr181="http://servicemix.apache.org/jsr181/1.0">
<classpath>
<location>.</location>
</classpath>
<jsr181:endpoint pojoClass="com.motorola.test.echo.EchoServiceImpl"
wsdlResource="classpath:echo.wsdl"
style="document" />
</beans>
jsr181-su: echo.wsdl
-------------------------
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://motorola.com/test/echo"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="echo"
targetNamespace="http://motorola.com/test/echo">
<wsdl:types>
<xsd:schema targetNamespace="http://motorola.com/test/echo">
<xsd:element name="Echo">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="in"
type="xsd:string"></xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!--<xsd:element name="EchoResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="out"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>-->
</xsd:schema>
</wsdl:types>
<wsdl:message name="echoRequest">
<wsdl:part element="tns:Echo" name="in"/>
</wsdl:message>
<wsdl:message name="echoResponse">
<wsdl:part type="xsd:boolean" name="out"/>
</wsdl:message>
<wsdl:portType name="EchoPortType">
<wsdl:operation name="echo">
<wsdl:input message="tns:echoRequest"/>
<wsdl:output message="tns:echoResponse"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="EchoBinding" type="tns:EchoPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="echo">
<soap:operation
soapAction="http://motorola.com/test/echo/echo"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="EchoService">
<wsdl:port binding="tns:EchoBinding" name="EchoPort">
<soap:address location="http://0.0.0.0:9999/echo"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
consumer-http-su: xbean.xml
---------------------------------
<beans xmlns:http="http://servicemix.apache.org/http/1.0"
xmlns:test="http://motorola.com/test/echo">
<http:endpoint service="test:EchoService"
endpoint="EchoPort"
role="consumer"
locationURI="http://0.0.0.0:9999/echo/"
defaultMep="http://www.w3.org/2004/08/wsdl/in-out"
soap="true" />
</beans>
So I am using the same values for http:endpoint service="test:EchoService",
endpoint="EchoPort" in my echo service consumer-http-su and in the
provider-http-su of SA_reteive SA which is retrieving the messages. This
duplicay is giving the problem.
Please help, as I am not able to figure out to define the proper routing of
the messages beteen SU and across SA.
Regards,
Gaurav
Gert Vanthienen wrote:
>
> Guarav,
>
> Is this the only change that is necessary in the XSL file to switch to
> version 2.0?
>
> For what the saxon dependency is concerned:
> The previous version of the page used the
> servicemix-lwcontainer-service-unit archetype to create the
> bridge-xslt-su. I have changed that to use
> servicemix-saxon-xslt-service-unit and that one should automatically put
> the correct dependency in there to start with.
>
> Gert
>
> gauravsonline wrote:
>> Thank you so much. Would like to suggest two more small changes, though
>> not
>> important but it would make the things more concrete.
>>
>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which
>> should
>> be "2.0". If not the case then servicemix gives a warning that "saxon
>> engine
>> is 2.0 but the stylesheet version is 1.0".
>>
>> Secondly, the saxon dependency has to be added in the pom.xml file for
>> XSLT
>> SU.
>>
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.servicemix</groupId>
>> <artifactId>servicemix-saxon</artifactId>
>> <version>3.1-incubating-SNAPSHOT</version>
>> </dependency>
>> </dependencies>
>>
>> Hope this makes sense. As of know I just have these many changes only.
>>
>> Also thanks for ur reply on the second use case. I will now work on that.
>>
>> Regards....
>> Gaurav
>>
>>
>> Gert Vanthienen wrote:
>>
>>> L.S.,
>>>
>>>
>>> First of all, I have changed
>>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>>> Could you check if all necessary changes have been done? This page will
>>> get replicated to the main site after a while...
>>>
>>> For your second use case: if you do not need any transformations on the
>>> message content, you can create a service assembly with two service
>>> units:
>>> - one SU based on servicemix-jms, defining the JMS consumer endpoint to
>>> read messages from a JMS queue (cfr.
>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>>> configuration options)
>>> - the other SU based on servicemix-http, defining the HTTP provider
>>> endpoint which points to your webservice (cfr.
>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>>> configuration options)
>>>
>>> Beware that the service/endpoint name of you HTTP provider endpoint
>>> should match the names defined in your webservice's WSDL. You can
>>> either use the same service/endpoint name on your JMS endpoint or use
>>> the targetService/targetEndpoint attributes to do the routing.
>>>
>>>
>>> Regards,
>>>
>>> Gert
>>>
>>> gauravsonline wrote:
>>>
>>>> HI,
>>>> Thanks for your help. Actualy just now I resolved the problem.
>>>> The problem was in the xslt-su. The archtyope by default generates the
>>>> servicemix.xml file and in the example code its xbean.xml file. So just
>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>>>> dependency
>>>> was
>>>> ok.
>>>>
>>>> Now the next step is to read the messages from the queue and call a web
>>>> service. Could you please help??
>>>>
>>>> Also I would like to request the moderator if they could update this
>>>> thing
>>>> at :
>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>>
>>>> in the "XSLT SU" section, as this has costed me two days to resolve.
>>>>
>>>> Thanks all for your help!
>>>>
>>>
>>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10444730
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: "Creating a protocol bridge" tutorial's configs are
differentfromBridgeexample's
Posted by gauravsonline <sa...@techmahindra.com>.
Hi Gert,
Sorry, I just overlooked at the wiki. I have just now created an archetype
for "servicemix-saxon-xslt-service-unit". The pom.xml file has the saxon
dependency entry and the xbean.xml file as was desired. So we need not to
add any dependency and/or rename the file servicemix.xml to xbean.xml (as
was the case for "servicemix-lwcontainer-service-unit") as far as we are
using the "servicemix-saxon-xslt-service-unit" artifact. I think no changes
are required on the wiki on this front.
But the stylesheet version has to be modified from 1.0 to 2.0; otherwise it
gives the warning as:
"Warning: at xsl:stylesheet of :
Running an XSLT 1.0 stylesheet with an XSLT 2.0 processor"
Regards,
Gaurav
Gert Vanthienen wrote:
>
> Guarav,
>
> Is this the only change that is necessary in the XSL file to switch to
> version 2.0?
>
> For what the saxon dependency is concerned:
> The previous version of the page used the
> servicemix-lwcontainer-service-unit archetype to create the
> bridge-xslt-su. I have changed that to use
> servicemix-saxon-xslt-service-unit and that one should automatically put
> the correct dependency in there to start with.
>
> Gert
>
> gauravsonline wrote:
>> Thank you so much. Would like to suggest two more small changes, though
>> not
>> important but it would make the things more concrete.
>>
>> Actually in the XSLT SU, the xsl:stylesheet version is "1.0", which
>> should
>> be "2.0". If not the case then servicemix gives a warning that "saxon
>> engine
>> is 2.0 but the stylesheet version is 1.0".
>>
>> Secondly, the saxon dependency has to be added in the pom.xml file for
>> XSLT
>> SU.
>>
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.servicemix</groupId>
>> <artifactId>servicemix-saxon</artifactId>
>> <version>3.1-incubating-SNAPSHOT</version>
>> </dependency>
>> </dependencies>
>>
>> Hope this makes sense. As of know I just have these many changes only.
>>
>> Also thanks for ur reply on the second use case. I will now work on that.
>>
>> Regards....
>> Gaurav
>>
>>
>> Gert Vanthienen wrote:
>>
>>> L.S.,
>>>
>>>
>>> First of all, I have changed
>>> http://cwiki.apache.org/confluence/display/SM/Creating+a+protocol+bridge.
>>> Could you check if all necessary changes have been done? This page will
>>> get replicated to the main site after a while...
>>>
>>> For your second use case: if you do not need any transformations on the
>>> message content, you can create a service assembly with two service
>>> units:
>>> - one SU based on servicemix-jms, defining the JMS consumer endpoint to
>>> read messages from a JMS queue (cfr.
>>> http://incubator.apache.org/servicemix/servicemix-jms.html for
>>> configuration options)
>>> - the other SU based on servicemix-http, defining the HTTP provider
>>> endpoint which points to your webservice (cfr.
>>> http://incubator.apache.org/servicemix/servicemix-http.html for
>>> configuration options)
>>>
>>> Beware that the service/endpoint name of you HTTP provider endpoint
>>> should match the names defined in your webservice's WSDL. You can
>>> either use the same service/endpoint name on your JMS endpoint or use
>>> the targetService/targetEndpoint attributes to do the routing.
>>>
>>>
>>> Regards,
>>>
>>> Gert
>>>
>>> gauravsonline wrote:
>>>
>>>> HI,
>>>> Thanks for your help. Actualy just now I resolved the problem.
>>>> The problem was in the xslt-su. The archtyope by default generates the
>>>> servicemix.xml file and in the example code its xbean.xml file. So just
>>>> renaming the file from servicemix.xml to xbean.xml. The saxon
>>>> dependency
>>>> was
>>>> ok.
>>>>
>>>> Now the next step is to read the messages from the queue and call a web
>>>> service. Could you please help??
>>>>
>>>> Also I would like to request the moderator if they could update this
>>>> thing
>>>> at :
>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>> http://incubator.apache.org/servicemix/creating-a-protocol-bridge.html
>>>>
>>>> in the "XSLT SU" section, as this has costed me two days to resolve.
>>>>
>>>> Thanks all for your help!
>>>>
>>>
>>>
>>
>>
>
>
>
--
View this message in context: http://www.nabble.com/%22Creating-a-protocol-bridge%22-tutorial%27s-configs-are-different-from-Bridge-example%27s-tf3162370s12049.html#a10429010
Sent from the ServiceMix - User mailing list archive at Nabble.com.