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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/
