One Star

Multiple endpoints in tESBRequest

Hi all,
I am facing an issue with multiple web service endpoints of a web service. I have a web service with two bindings and I need to have two endpoints within one service. The sample bellow is very simplistic, however, we aim more sophisticated scenarios consisting of SOAP11 and SOAP12 bindings, HTTP and JMS bindings etc.
...
<wsdl:binding name="aaaBinding" type="tns:aaaPortType">
  <soap:binding transport="" style="document"/>
  <wsdlSmiley Surprisedperation name="aaaOperation">
    <soapSmiley Surprisedperation soapAction=""/>
      <wsdl:input>
        <soap:body use="literal"/>
      </wsdl:input>
    <wsdlSmiley Surprisedutput>
      <soap:body use="literal"/>
    </wsdlSmiley Surprisedutput>
  </wsdlSmiley Surprisedperation>
</wsdl:binding>
<wsdl:binding name="aaaBinding2" type="tns:aaaPortType">
  <soap:binding transport="" style="document"/>
  <wsdlSmiley Surprisedperation name="aaaOperation">
    <soapSmiley Surprisedperation soapAction=""/>
     <wsdl:input>
       <soap:body use="literal"/>
     </wsdl:input>
     <wsdlSmiley Surprisedutput>
       <soap:body use="literal"/>
     </wsdlSmiley Surprisedutput>
  </wsdlSmiley Surprisedperation>
</wsdl:binding>
<wsdl:service name="aaa">
  <wsdlSmiley Tongueort name="aaaPort" binding="tns:aaaBinding">
    <soap:address location=""/>
  </wsdlSmiley Tongueort>
  <wsdlSmiley Tongueort name="aaaPort2" binding="tns:aaaBinding2">
    <soap:address location=""/>
  </wsdlSmiley Tongueort>
</wsdl:service>
</wsdl:definitions>
After implementation of a Talend ESB flow and service in Open Studio using tESBRequest and creating a KAR file, only one port becomes active and live, whereas the other is still present in WSDL but not bound to any particular URL. The reason is, when you open the blueprint.xml file in the control-bundle JAR packaged in KAR, it contains a single endpoint only (it seems it is the last one):
    <jaxws:endpoint xmlns:jaxws=""
            id="aaa"
            implementor="#genericServiceProvider"
            xmlns:tns=""
            serviceName="tns:aaa"
            endpointName="tns:aaaPort2"
            address="/aaa2"
            wsdlLocation="classpath:/aaa_0.1.wsdl">
        <jaxwsSmiley Tongueroperties>
            <entry key="use.service.registry" value="false" />
        </jaxwsSmiley Tongueroperties>
        <jaxws:features>
        </jaxws:features>
    </jaxws:endpoint>
 
I found out that by manually editing of the control-bundle's blueprint.xml file, one can add another JAXWS endpoint and assign another URL to it. It seems the two endpoints cannot share the same URL (e.g. SOAP11 and SOAP12 bindings on the same URL), which is probably a limitation of CXF framework, however, that is a minor problem. For the HTTP and JMS binding scenario, this is sufficient.
    <jaxws:endpoint xmlns:jaxws=""
            id="aaa"
            implementor="#genericServiceProvider"
            xmlns:tns=""
            serviceName="tns:aaa"
            endpointName="tns:aaaPort"
            address="/aaa"
            wsdlLocation="classpath:/aaa_0.1.wsdl">
        <jaxwsSmiley Tongueroperties>  
            <entry key="use.service.registry" value="false" />
        </jaxwsSmiley Tongueroperties>
        <jaxws:features></jaxws:features>
    </jaxws:endpoint>
    <jaxws:endpoint xmlns:jaxws=""
            id="aaa2"
            implementor="#genericServiceProvider"
            xmlns:tns=""
            serviceName="tns:aaa"
            endpointName="tns:aaaPort2"
            address="/aaa2"
            wsdlLocation="classpath:/aaa_0.1.wsdl">
        <jaxwsSmiley Tongueroperties>
            <entry key="use.service.registry" value="false" />
        </jaxwsSmiley Tongueroperties>
        <jaxws:features></jaxws:features>
    </jaxws:endpoint>
Now the question: Is there any way to convince Open Studio to include both/all JAXWS endpoints into the control-bundle's blueprint.xml? As of now, the process described above works but it is very inconvenient to modify the blueprint each time we compile the service into a KAR file. Or, is there any other way to easily expose a single tESBRequest over multiple transport types or bindings?
Thanks Michal
7 REPLIES
One Star

Re: Multiple endpoints in tESBRequest

Michal ,
You schould use cCXF component of the ESB suite.
Much much much (and much) more powerfull then tESBrequest...
https://help.talend.com/search/all?query=cCXF&content-lang=en
Have fun! Smiley Wink
One Star

Re: Multiple endpoints in tESBRequest

Dear Morgan,
thanks for your response. Initially I was not too much happy about this solution, because we strongly prefer using Talend flows rather than Camel routes. But then we were facing other challenges such as throttling and again cCXF this seems to be a more flexible approach.
So there is a lot of space for improvements in order to make tESBRequest as powerful as cCXF.
Michal
One Star

Re: Multiple endpoints in tESBRequest

May I ask why you prefer Talend flows? instead of routes? You can call flows from a route..
One Star

Re: Multiple endpoints in tESBRequest

Well, this could easily be a topic of a new thread, but anyway…
It is a matter of using right tools for right things. So, if the aim is to expose a web service on ESB using proxy pattern (no data mapping, no orchestration), or to route an async message from one queue to another, then a Camel route seems to be an optimal solution. However, if we want to create an orchestrated service on ESB, or map request and response message from the common integration data model to an application specific data model and back, then using a Talend flow seems to be more appropriate. This is especially true when the web service contains more operations.
You may argue that it is possible to call a Talend flow from a Camel route. But what is the benefit of creating a Camel-based web service wrapper, do a fork based on operation name and call Talend flows from there, if you can create a Talend service directly?
Michal
One Star

Re: Multiple endpoints in tESBRequest

Michal,
It's true that Camel is maybe not needed if only mapping is required but what about scalability?
If in the future you need to do other things then just map data? You could easily go ahead and expand the route because making it in a job you will be restricted to palette components.
But this stays your own choice.
One Star

Re: Multiple endpoints in tESBRequest

Hi Morgan,
I did not get the point about scalability. How does Camel route in Karaf scale better than Talend flow in Karaf, when we consider SOAP/HTTP web services?
In terms of custom components, you can always create a new Talend component, as well as a Camel one, even if Camel is probably easier. Non-reusable requirements can be addressed by tJavaRow component easily, we have already done it. In addition, there is TalendForge Exchange where you can download 3rd party products as well. Also, Talend offers a number of adapters, such as to SAP, and those are missing in pure Camel.
You see we are not Camel fans, when it comes to more complex services, however, we recognize it as an efficient way of solving easy tasks.
@Talend support, back to the original question - is there a chance that tESBRequest would offer as much options and functionality as cCXF?
Michal
One Star

Re: Multiple endpoints in tESBRequest

Michal,
When I talk about scalability I talk about the design/dev phase , this has nothing to do with Karaf.

In terms of custom components, you can always create a new Talend component, as well as a Camel one, even if Camel is probably easier.

Easier, I hope you're talking abour calling an URI and not making a new component yourself in the Camel project because otherwise you don't know what you're talking about.
And sure everything can be done in Java (tJavaRow), since it's all Java..
Btw I don't have any problem about you or your team not being Camel fans , you just miss something that's all Smiley Happy
Hope you will get another response from Talend! (Even if a month passed without any answer Smiley Wink)