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.
