Embedding SwitchYard inside Eclipse Runtime?

[ceefour]

Is it possible to embed SwitchYard inside Eclipse Runtime?

Specifically, so that deployed services can be Eclipse plugins, in the sense that required bundles use the OSGi classloading mechanism.

Thank you.

[rcernich]

I think this should be possible, however it would probably require some work to integrate the existing runtime into an OSGi environment.  Once you've done that, you'd have to think about a deployment model for the applications.  For this, I'm guessing, at a minimum, you'd need to OSGi-ify the applications so they could be identified by the SwitchYard runtime.

You should look at switchyard-as7-build to see how the runtime is configured and packaged for AS7.  Specifically, look at the module files which describe the core components and dependencies.  You'd have mimic that in your OSGi manifests.  That would get you a runtime that should load within an OSGi container.

For the components (e.g. SOAP), you'll need to make sure the binding activators are registered with the runtime.  For this, you'll probably need to create an OSGi activator to register the service or you could use declarative services.  Either way, there will be some plumbing changes in the runtime to use OSGi services instead of Java services.  The following blog details the differences:  http://jbossosgi.blogspot.com/2010/01/suns-serviceloader-and-how-it-relates.html  Refer to org.switchyard.deploy.internal.Deployment to see how these are used.  You would need to use an OSGi service lookup method to find the SwitchYard Activator implementations.

That should get a SwitchYard runtime, including components.  The trickiest part will be to get the SwitchYard applications registered with the runtime.  For that, you can reference switchyard-deploy-jboss-as7 to see how applications are deployed in AS7, specifically SwitchYardDeploymentProcessor.  I don't have any good ideas, at the moment, on how best to tackle this.  You may have to create and start the deployment from within the application bundle itself.

Not sure if that helps much or not.

Rob

[ceefour]

Thank you very much Rob.

You've already provided valuable pointers.

I have another question on creating gateways, I'll create another thread.

[kcbabo]

We will do this as part of 0.3.  Shouldn't be too hard.  If you would like to contribute, we can provide help on how to implement it.  A few more details can be found in the following JIRA:

https://issues.jboss.org/browse/SWITCHYARD-340

SwitchYard applications can be detected using the extender pattern in OSGi, so all we need to do is add a bundle which listens for bundle installation events, looks for META-INF/switchyard.xml, then triggers deployment through our platform-neutral Deployment class.

[rcernich]

Hey Hendy,

I was doing a bit more thinking on the application deployment bit last night.  You may be able to create a basic deployment implementation as part of your core OSGi runtime integration.  This would be an OSGi service implementation (although not a service in and of itself).  From there, you could use declarative services to define the deployment within the application.  The service would use the implementation from the core runtime (which your bundle should already have a dependency on).  Barring any classloader issues, the deployment implementation _should_ be able to pick out the switchyard.xml file from the application bundle, process it and register itself.  If that works, all you would need to do is OSGi-ify the application's manifest and add the deployment service config into the archive.  (The thought here is that since the service is being instantiated from within the application bundle, it should have access to the application bundle's classloader so it can find the resource.)  The deployment service config should be the same for all applications since it is implemented using the same class from the core bundle and simply processes the switchyard.xml file (not sure if you'd need to change the name or anything, been a while since I've done anything OSGi).

Hopefully, that gives you a bit more to go on.

Rob

[ceefour]

Thank you Rob & Keith. That's indeed helpful.

(Also note to self). For processing META-INF/services aka ServiceLoader, perhaps can reuse Apache Aries SPI-Fly: http://aries.apache.org/modules/spi-fly.html

I presume that you suggested that because SwitchYard components currently use META-INF/services to register its implementation(s), is this correct?

About applications deployment, I am thinking of (as a start) deploying "directly" to the OSGi runtime. This is similar to the approach taken by ServiceMix. There is a deploy/ folder where we can deploy any OSGi bundle, or a format supported by ServiceMix.

First the bundle should be able to use SwitchYard services by itself (aka OSGi HttpService style).

And then create the extender so no need for "SwitchYard programming".

And then support for non-bundle deployments. Like ServiceMix is able to (hot-)deploy Camel XML files directly. Not sure if it's supported by SwitchYard at the moment or if it's in future plan...