New user - Open Studio for ESB, ext-webservice calling int-webservice

[Anonymous]

Hey all,
Evaluating/first time user of Talend Open Studio (and ESB in general, but also trying to evaluate Mule/ServiceMix/JBossESB on-and-off).
Using 5.0.1 Talend OpenStudio for ESB on Linux (32bit).
I've gone through the same tutorial several times around setting up 'first web service', gone through the user documentation (although some of it currently doesn't make sense/click yet), but still struggling with my first usecase:
1) Take an existing (internal) webservice (with input/output)
2) create an external-facing webservice (contract-driven),
3) have the ESB host the external facing, call the internal facing, map inputs/outputs appropriately.
4) review applying security to the external-facing webservice
#3, mapping, I'm really confused/stuck on. Although I've setup the WSDL for both the external and internal, when I use things like tXMLMap (which I'm not sure if that is correct or not), all I see are 'payload document' with no nodes and nothing from the WSDL's are shared across anything. I've setup a Service, changed the property type for each ESB* from built-in to be Repository and link to the Service, the schema's seem to be something else I don't understand so are defaulted to built-in. It almost appears I need to print off the WSDL, then create the document-nodes manually again in the tXMLMap for the mappings (again, assuming that is the right approach).
ESBProviderRequest ->(tXMLMap?)-> Webservice (internal) ->(tXMLMap?)-> ESBProviderResponse
Am I completely missing something? I do not see any other relevant tutorials, and didn't see anything in the forum or external blog post, if this kind of example already exists and I missed it, great! Otherwise, lost...
EDIT: Not sure if this is the source of the problem, but I have been unable to make a 'Metadata/Schema' from the Service (right-click, 'Import WSDL Schemas' does nothing), nor creating a schema directly from the WSDL. All the Metadata folder/groups are empty, and any time I get to the 'guess schema' it does nothing there.

-D

[Anonymous]

While that should work we recommend to use the camel route builder for service to service calls as it performs better under high loads. I am not so experienced in the route builder but can tell you how to make it work in pure camel. So you just have to create a route that looks like this in source code:
from("cxf:/path?wsdlURL=wsdl/hello_world.wsdl&dataFormat=PAYLOAD").to("xslt athtostylesheet.xsl").to("cxf:http://server/service?wsdlURL=wsdl/hello_world2.wsdl&dataFormat=PAYLOAD").to("xslt athtostylesheet2.xsl")
The drawback of this aproach is that we currently have no visual component for building the xsl style sheet. We are working on that though so that may change soon. I will provide a tutorial on how to develop and deploy such a route in Karaf or TESB on my blog during the next week.
So look out for this on: http://www.liquid-reality.de/

[Anonymous]

Hello,
I think it's a bug. Could you please validate your WSDLs. Double click on Service node, there you can do right click on the WSDL editor and select 'Validate'. If your WSDLs are invalid then you need to fix issues before you can proceed, otherwise please create a JIRA on that. WSDL is overcomplicated and hard to use standard therefore I'm there is very hard to guarantee that our tooling would work with 100% WSDLs out there. Our main assumptions right now are WS-I Basic profile compliance and single service/port/portType.
Renat

[Anonymous]

BTW to what Christian said above. It is indeed recommended to use camel-based ESB services for mediation use-cases. It's not only a performance issue (which is indeed higher for camel-based solution so far) but also the abstraction level. Since camel-based ESB routes work based on Exchange and not only on payload it is more convenient to do the routing and mediation implementations based on it. Sweet spot of Data Services is connectivity to foreign/legacy systems.
It is however indeed also true that Camel Route Builder right now lack the graphical data mapping capabilities, we are working on that.
Renat

[Anonymous]

thanks christian, renat,
I confirmed the WSDL's (two different ones from two different services tested) were both valid. I've opened a ticket here:
http://jira.talendforge.org/browse/TESB-4425
I'm also evaluating other ESB's at this moment and a little disappointed at the raw Camel approach. Talend was looking quite good until I came to this task (opposed to XML/script/coding that is error-prone/testable only during runtime in the other open source ESB's). The use of compile-time checking, and being able to 'run' within the IDE is great in Talend!
Note: I definitely appreciate the experience provided, where Camel has been tested to be a higher performant for this type of task.

-D

[Anonymous]

Hello Darren,
I appreciate your JIRA issue, but the way it is described is too general, could you please attach your WSDL files to reproduce your issue?
Renat
P.S. The reason behind that such functionality (Import Schemas) works on many WSDLs we tested so far.

[Anonymous]

First of all, thanks for this post. I'm trying to discover services manually published in a GREG 4.1.0 from a ESB 4.0.2 installation. All these services have namespace, version, WSDL and an endpoint filled in. After configuring and testing the WS-Discovery URL, the ESB only retrieves the Service UUID and Version ID from the GREG, but no scope or endpoint information. There is no "Create Proxy Services" panel either. If I register the same service in the GREG through the DiscoveryProxyHttpSoapEndpoint (with SoapUI for instance) then all the information is shown on the ESB Discovery screen and I can create ESB Endpoints and Proxy Services. Should WS-Discovery work with manually registered services?. Regards.

[Anonymous]

Hi, we have the same issue with importing our own wsdl's. Rewriting the wsdl's is not an option as these are defined by an third party.
Very often you will need to use and external defined WSDL, as there are several WSDL styles possible:
- RPC/encoded
- RPC/literal
- Document/encoded
- Document/literal
I think that Talend as an integration framework should be able to cope with a lot of the WSDL styles, as rewriting existing services inside the Talend IDE is time consuming and not very practical.
I also noticed that when removing an existing operation from a service, the WSDL data still contains the removed messages and elements?
We are currently doing an evaluation of Talend to be used as an ESB in our architecture, using external wsdl's is very importend for us,
what kind of fix will Talend provide for this? can we expect a broader wsdl formatting import?
Also is there some kind of work around possible, some custom Java code maybe? to get the external wsdl working?

[Anonymous]

I agree arjenvanharen,
My original webservices were RPC/literal and it appeared the Studio provided no support around these. Unfortunately, even after the effort of going DOCUMENT/literal, the tooling does not appear to be there at all. (in my testcase, jboss6 and jboss7 default setup webservices via EJB).
These exact same WSDL's, which are internal so I can not share unfortunately, work fine in other ESB's, and I've had to move to one of the other open source ESB's for my solution.
The tooling was fantastic in Talend Studio when it worked, but with Mule now working it's own studio (which hopefully will be superior to Jboss ESB's IDE integration, if not reach Talend's level) there are slowly other options appearing and I hope the lead that Talend got will not lag behind research and fixing of these kinds of issues.
p.s. if anyone has WSDL's that are not proprietary but are having similar issues, please post to the JIRA ticket above.