Developer and runtime integration with S-RAMP artifacts

[jorgemoralespou_2]

Hi,

I was thinking on a functionality that has been requested many times by the people I talk to about Governance and S-Ramp, and I wanted to discuss it here, whether is valuable, it will be implemented, if there is any though around it, or whatever you think.

I'll describe the steps in the image above:

• Developer A, creates a wsdl and deploys to S-RAMP.
• Developer B opens JBDS and creates a new project
• Developer B needs to use the wsdl deployed into S-RAMP, so browse in the S-RAMP repository browser in JBDS (NOT EXISTING) and selects the wsdl/schemas to include
• JBDS will virtually include the artifacts in developer's B source code but will use an S-RAMP url in the composite definition (NOT EXISTING).
• Developer B will build the artifact and include fetched wsdl in the META-INF/S-RAMP folder with the same path as the S-RAMP original artifact. (IMPLEMENTATION EXAMPLE)
• Developer B will deploy to S-RAMP the generated APP artifact.
• DTGov will trigger the deployment of the app artifact to a SY cluster.
• SY will start deployment. While parsing the composite definition, will find an S-RAMP url, and will fetch real artifact (THE REAL WSDL) from S-RAMP.
• SY deployer will overwrite the embedded S-RAMP directory in META-INF with the up-to-date artifact, fetched from the repo on the "data" dir (IMPLEMENTATION EXAMPLE)
• SY deployer will build the domain and runtime representation based on this "latest" artifact.
• SY will start the application

This is something that should be doable as an "S-RAMP" SOA REPOSITORY METADATA, as people would love to have the SOA artifacts deployed centrally. It looks like a first step to more complex integration. Right now, DTgov governs the push/deploy of the artifacts to runtime servers, but some artifacts/metadata should be kept external to the artifact for sharing.

The problem is that this approach goes against maven, and how we build our artifacts, and it is far more complex to manage than it seems.

Just wanted to see if there has been thought on this, and if I can fin answers to some of the questions I get.

Cheers,

[brmeyer]

Hey Jorge, apologies for not responding sooner.  In general, the idea of JBDS-based tooling is extremely desirable and something we hope to focus on soon.  This idea sounds great, but I'd limit it solely to the tooling.  JBDS would simply facilitate browsing and downloading the WSDL, then placing the physical file in Dev B's project.  S-RAMP artifacts should not be used during runtime at all.  I'd lump the SwitchYard deployer in with that.  Is there a specific usecase where delaying the file download would be beneficial?

[eric.wittmann]

I think the S-RAMP + IDE integration is a no-brainer.  It's something we've discussed in the past but i'm not sure where it currently lives in terms of priorities. 

However, S-RAMP is not intended to be in the runtime loop.  It's not a registry of information, but rather a repository.  For runtime capabilities S-RAMP should provision out to some other system such as, for example, UDDI for runtime endpoint lookup.  If a user wanted to lookup the actual WSDL at runtime then it should get pulled from some other system designed to be a runtime component.  S-RAMP could publish to such a system at appropriate times in the lifecycle.

That said, I'm not sure I see what problem that solves.  What is the use-case for *not* bundling the WSDL resource in the app?  Normally I would expect an app to bundles its WSDL resources specifically because they *can* change, and swapping out an important resource like that at runtime could be a disaster for the code using it.  There clearly must be a use-case I'm not seeing though.