How to import WSDLs deployed in s-ramp into a BPEL ?

[simplex-software]

Hello,

In a switchyard project I have a BPEL which needs to orchestrate two services built in a different non-switchyard project. For example, I have a "services" project including schemas, wsdl and the required interfaces and implementation classes as well as the JAX-B stuff generated by the wsdl2java goal of the CXF maven plugin. The resulting jar gets deployed on the application server and in the s-ramp repository. Now, in a different project I need to orchestrate these two services in a BPEL using partner links. But these partner links are required at the BPEL design time such that, once imported, to be able to use JBDS wizard for BPEL to define variables based on the wsdl parts, types, etc. So, the WSDLs have to be accessible to the BPEL at its design time. I treid to use the import wizard and to import the wsdl into the BPEL using an URL like s-ramp://localhost:8080/... but unsuccessfuly.

So how is one supposed to deal with this case ?

Many thanks in advance,

Nicolas

[simplex-software]

Does anybody feel concerned ?

[jorgemoralespou_2]

Hi Nicolas,

As of now, and as far as I know, you have to embed the wsdl into your application (or make it accesible in a referenced app). There is no way to reference S-Ramp repository directly from within your app, or from within your JBDS, although has been requested.

I would recommend you to search Switchyard and JBTIS JIRAs and if you feel this is something that need to be done and there is none, create the JIRA and be the most explicit with your Enhancement Request, as then could be done in a future release.

I also think the feature is interesting, and there has been some talk on this before: Tutorial on referencing a SOAP Web Service in another Composite

[simplex-software]

Hi Jorge,

Many thanks for your reply to my question. As far as I understood, looking also at the link you've provided, the current design-time repository cannot be used to store shared artifacts. Even if I can create in it, say my WSDLs, XSDs and, purhaps, my BPELs, in order to use them at the design time, I need to download them from the centralized repository in each using project. Meaning that I'm not sharing them since each using project is having its own copy. Now, if I create a new version of an artifact, I need to download it again in each using project. Which leads me to the following question: what would be the purpose of a centralized, enterprise-wide design-time repository since it doesn't allow developers to share artifacts at the design time ?

Is there anything I got wrong here ?

Many thanks in advance,

Nicolas

[simplex-software]

Looking in the multiApp project, I'm seeing things like

	<artifacts>
	<artifact name="OrderService" url="http://localhost:8080/guvnorsoa/rest/packages/OrderService"/>
	</artifacts>

The documentation says:

"SwitchYard projects are capable of referencing artifacts stored in an external repository (e.g. when using a SOA governance solution).  These references can be declared in the SwitchYard application configuration using the tooling."

Using tooling means design-time so this means that SwitchYard projects are capable to reference at design-time artifacts stored in repositories. In the example the repository is Guvnor. I'm more and more confused as I thought that s-ramp is supposed to replace guvnor. But if tooling is able to reference artifacts in guvnor and not in s-ramp, then it means that s-ramp cannot replace guvnor as it doesn't provide the same functionalities. So, one needs to use guvnor and s-ramp ? What's the point to have two kind of repositories ?

[jorgemoralespou_2]

Hi Nicolas,

I think that it is no longer valid for SwitchYard 1.1, as a comment on the integration wiki suggests, but let's a SwitchYard developer answer this question, as I'm not one of them :-(

I only pointed you to that discussion, and nobody said anything there at that time :-(

[jorgemoralespou_2]

Hi again,

I guess that the problem lies in that guvnor feature for producing the artifact to be downloaded by the applications was not yet ported to S-Ramp, so this feature, when SwitchYard was integrated with Overlord got lost in the middle. Probably it is good to ask also in overlord forums (Overlord) and see what people says, and the raise the JIRA so this can be addressed, if there is none already.

[kcbabo]

Guvnor is simply an example of a repository that was used at the time that example application was put together.  Maven could have been used for the same purpose.  The artifact reference in switchyard.xml is purely informational and is not used to resolve any external resources at runtime.

There is no need to individually download artifacts stored in S-RAMP and duplicate them in multiple projects.  I would consider that an anti-pattern.  If you have artifacts shared across multiple applications, I would recommend isolating those into a distinct maven module and uploading/deploying that to the S-RAMP repository.  The S-RAMP repository is compatible with Maven, so you can use the S-RAMP repository to resolve the shared artifact module at development-time in any projects that consume it.  At runtime, you will want to deploy the shared artifact module separately or create an EAP module for it and then reference that as a dependency (in MANIFEST.MF or jboss-deployment-structure.xml) in any deployments that use it.

[simplex-software]

Hi Keith,

Many thanks for these explanations. However, I'm not sure I fully understand the way that s-ramp is supposed to be used at the design-time. Yes, as a matter of fact, downloading artifacts from the repository and hosting them in each project needing them would be an anti-pattern and a very important constraint that no any other equivalent SOA/SCA tool presents nowadays. And maven would help at the build-time while the MANIFEST.MF references, or EAP modules, or the jboss-deployment-structure.xml will help at the run-time. But what about the design time ?

Let me come back to my previous case. I will isolate in a separate JAR, a non-switchyard project, several XSDs and WSDLs, as well as the Java classes generated from them via wsd2java. Now, in another WAR, another non,-switchyard project, I will host the web services implementation classes which interfaces and model is hosted in the previous project. Finally, in a third switchyard project I will design a BPEL which orchestrates the web-services in the previous mentioned WAR. These web services and their associated WSDLs and XSDs are stored in the repository and deployed on the EAP/FSW server.

In this case, in order to be able to design my BPEL, the partner links the invocation of the web-services, etc. I need the WSDLs and the XSDs. If it is true that the tooling doesn't let me access the WSDLs/XSDs neither in the repository, nore on the EAP/FSW server via their URL, as it would have been the case of Oracle SOA Suite and other concurrent tools, how could I design my BPEL if not by separately downloading and hosting locally, in the project, the WSDLs and XSDs and reference them from inside the project ? On the reverse, if the tooling allows me to directrly reference the required WSDLs/XSDs from the repository or from the EAP/FSW server via their URL, then how could I do that ?

Many thanks in advance for clarifying this points.

Nicolas 

[simplex-software]

I'm still waiting for a solution or sugestion for this case.

[kcbabo]

I'm still waiting for a solution or sugestion for this case.

Sorry, forum notifications have been really flaky the last several weeks.  I just realized today there a number of threads waiting for replies.

It seems like there is one thing missing at this point and it's configuring the tooling to allow resources to be loaded from the project class path vs. only local resources.  Everything else needed to address this scenario is in place :

- You can store shared artifacts in the repository as a jar (deployed through maven or uploaded manually).

- You can resolve an artifact jar stored in S-RAMP via Maven.  This means the resources in that jar are available in the class path and should be able to be resolved via the tooling.

The one thing I'm not sure about is whether you can view a class path resource within the editor if it's only available through a Maven dependency.  It's one thing if you simply want to reference the name of WSDL file to include within a config, but it's another thing if you want the ability to view/edit that resource (which is a reasonable expectation).

One of the candidate features for the next major version of the tooling is integration with S-RAMP, which should smooth out many/all of these issues.

[simplex-software]

Hi Keith,

Many thanks for the update. Yes, it's clear that one can store artifacts in the S-RAMP repository and can resolve them with maven, for build and deploy purposes. But, please correct me if I'm wrong, it doesn't seem to exist at this stage any provision for using these artifacts at the design time. If I take again my case, designing a BPEL requires access to the WSDLs and XSDs in the S-RAMP repository. Meaning that that tooling should let the user to browse the S-RAMP repository, to select the required artifacts from it and to base on them the new artifact, as all the other similar tools do.

Concretely speaking, again  in the context of BPEL design/development, when a new partner link is created, the developer should be able to browse and select the associated WSDL and XSD not only from the project and the workspace, but also from the S-RAMP repository and from an URL. Also, the XML import statements, should they appear in XSDs, WSDLs or BPELs, should accept a special form such that to import WSDLs, XSDs, etc. from the S-RAMP repository, something like :

<import namespace="..." location="s-ramp://..." />

Anyway, tooling still needs to make a lot of progress in order to become usable for professional, high productivity development. Expession builders, mappers, support for graphical assignments and transformations, XPath/XQuery editors, are only a few missing functionalities.

Probably in future releases.

Kind regards,

Nicolas DUMINIL

[kcbabo]

Your interpretation is correct - at present, the tooling does not support design-time resolution of artifacts stored in the S-RAMP repository.