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