Maven/S-RAMP integration and its use from within Eclipse

[objectiser]

The Switchyard team have discussed the possibility of allowing a contract (wsdl + associated xsds) to be stored in a separate maven artifact (jar) and referenced from the switchyard app, thus allowing more than one switchyard app to share the same contract details without having to include them directly in their own jar.

If this is possible, then I believe the following describes how this particular feature can be used:

1) The common shared artifacts (wsdl/xsd) are defined in a maven project and deployed to the s-ramp repo.

2) Each switchyard app project that requires the contract will reference it as a dependency within their pom - thus indirectly retrieving the artifact when the switchyard app is built.

3) At runtime deployment, both the switchyard app and the shared artifacts would be retrieved from the repository and deployed into switchyard.

Question: Does maven have a role to play here? Rather than switchyard having to know what the dependencies are for a particular app - it could leverage the maven dependencies to retrieve all other artifacts of interest. (This is out of scope for the repo itself, but might provide some useful capability for switchyard's use of the repo).

The usecase above is quite straightforward, as the shared contract will have its own GAV details provided when it is deployed, and these same details can be used to retrieve it.

The more interesting usecase, which may or may not be possible, is:

1) A user develops a Switchyard app that provides a service - the contract for this service is defined by wsdl/xsd files that are contained within the app. When deployed to s-ramp via maven, the app will have its own GAV details, and the s-ramp repo will create the derived artifacts associated with the wsdl/xsd etc.

2) Another user now wishes to create an app (could be switchyard or might just be a web service client), the question is how do they (from their Eclipse environment) retrieve the contract details:

a) Straightforward answer is they would have to search the repo (using the UI) and manually download the relevant derived artifacts - Q: is it possible to download a wsdl independent of the artifact in which it is contained by reference to its derived artifact?

b) ???? - not sure if maven has a role to play here?

One possibility may be that a modified version of the containing artifact's GAV details could be used to refer to a specific contained artifact, or a class of artifacts, e.g. if the binary GAV is com.acme:orders:1.0, then possibly com.acme:orders/OrderService.wsdl:1.0 could retrieve just the wsdl - or com.acme:orders/contract:1.0 may retrieve the artifacts defined by the class 'contract'.

We also need to consider cases where client projects may or may not be able to reference the contract via a maven dependency - some projects will require the contract to be locally defined.

Thoughts?

[eric.wittmann]

First, I have some thoughts on use-case #1.  I love the idea of bundling up a contract (wsdl + schemas) into a deployment unit and releasing it separately.  Presumably it would only include the abstract parts of the WSDL.  This makes sense, and I think it would be great if the deployment also included jaxb and jax-ws generated java classes for the schemas and wsdl.  Ideally, you'd be able to have schema-only artifacts as well - deployments that included one or more schema files along with the generated Java code.  For this to work well, a custom jaxb and/or jaxws plugin might be needed. 

I've tried to structure Maven projects this way in the past, where Module A produced a JAR with schemas, generated jaxb classes, and an episode file.  Then Module B should produce a JAR with wsdl and generated jaxws *and* allow the wsdl to refer to common types found in Module A.  This seems like an ideal way to produce SOA artifacts (projects with common types, projects that consume those types and produce services).  If switchyard + maven + s-ramp + ??? can provide a SOA development experience like that, it would be powerful.

As for the role of maven and s-ramp - I think that the shared artifacts would get deployed to s-ramp (as you suggest).  The switchyard app can add a dependency to one or more of those shared artifacts.  Dependencies can be handled by the s-ramp wagon - it can query s-ramp for relationships and generate a POM that maven will use to resolve all the dependencies.  In other words - the switchyard app can simply depend on a WSDL deployed to s-ramp, and all of the XSDs and whatnot can be pulled in via standard Maven dependency management (generated by the s-ramp wagon using s-ramp relationship info).

[eric.wittmann]

Regarding use case #2 - I don't think it's necessarily materially different from use case #1.  The only difference is that the "thing" being deployed to s-ramp in #1 is a JAR (perhaps) and in case #2 is a switchyard app (not sure what file format this is).

In either case, we need to be able to extract all of the relevant artifacts from the deployment unit and explode them inside the s-ramp repo.  Possibly they will be derived artifacts so they can not be deleted or modified independently.

I think in both cases we need to figure out the mechanics of deploying a bundle of "stuff" *to* the s-ramp repository, and we need to figure out the mechanics of depending *on* one of the derived artifacts therein.  But I think the solution works for both.

What I'm fuzzy on is what form must these artifacts take when referencing them in a switchyard app?  Do the artifacts need to be in a certain location in the project?  I just don't know much about switchyard at this point.  I should go find a Getting Started with Switchyard resource.

[objectiser]

Keith documented the integration with Guvnor here: https://community.jboss.org/wiki/SwitchYardRepositoryIntegration

I'd forgotten that the "demos/multiApp" quickstart does separate out the shared artifacts into a separate jar, so this is supported now. So this quickstart might provide a good starting point to test this approach out.

[rcernich]

Hey Eric,

Eric Wittmann wrote:

First, I have some thoughts on use-case #1.  I love the idea of bundling up a contract (wsdl + schemas) into a deployment unit and releasing it separately.  Presumably it would only include the abstract parts of the WSDL.  This makes sense, and I think it would be great if the deployment also included jaxb and jax-ws generated java classes for the schemas and wsdl.  Ideally, you'd be able to have schema-only artifacts as well - deployments that included one or more schema files along with the generated Java code.  For this to work well, a custom jaxb and/or jaxws plugin might be needed. 

I've tried to structure Maven projects this way in the past, where Module A produced a JAR with schemas, generated jaxb classes, and an episode file.  Then Module B should produce a JAR with wsdl and generated jaxws *and* allow the wsdl to refer to common types found in Module A.  This seems like an ideal way to produce SOA artifacts (projects with common types, projects that consume those types and produce services).  If switchyard + maven + s-ramp + ??? can provide a SOA development experience like that, it would be powerful.

Part of the beauty of SwitchYard is that you do not need to create stubs.  It takes care of all the plumbing so WSDLs and XSDs are all you need.  (A bit of an oversell; some transformation logic may be required to convert between XML and whatever types you are using in your application, but...)

[rcernich]

What I'm fuzzy on is what form must these artifacts take when referencing them in a switchyard app?  Do the artifacts need to be in a certain location in the project?  I just don't know much about switchyard at this point.  I should go find a Getting Started with Switchyard resource.

A good place to start would be here:  https://docs.jboss.org/author/display/SWITCHYARD/Quick+Start

Should only take a few minutes to get something up and running.  That will illustrate the basics of providing a service.  The multiApp example Gary pointed you to is a more complete example of how repository integration may be supported.

Please provide feedback on the SwitchYard forums as we're working hard to make things as simple as possible.

Best,

Rob

[eric.wittmann]

Of course!  That makes perfect sense for a product like Switchyard (to provide all the plumbing).  A lot of integration frameworks do that with varying degrees of success.

I do still think that jaxb/jaxws generated classes can be valuable to provide easy to consume java based clients to web services.  It sounds like it's just not valuable in a switchyard context.

Thanks for the getting started resources - I'll run through them so I can have a more informed opinion.    Not that that has ever stopped me in the past!

[rcernich]

This describes how to install the SwitchYard tools in Eclipse: https://docs.jboss.org/author/display/SWITCHYARD/Installing+Eclipse+Tooling

I'd follow what's in the "Development Builds" section.

Good luck!