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.
