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/

Reply via email to