Dynamic invocation of Switchyard services

[prasenjit.d]

Hi,

I'm building a dynamic service delivery and invocation platform. On one side, people will create and deploy new services. And, on the other side, people will define business processes and invoke these services from these processes. I've decided to use jBPM and Switchyard on JBoss 7.1.1.Final.

The services are created as Bean service and they are getting deployed without any problems. I'm also able to use these services from other applications using @Reference injection. But this is a static scenario. Switchyard scanners can create appropriate configurations during build.

Now my question is...

Is it possible to do this dynamically? How can I invoke a Bean service given the qualified name, service parameters and anything else? Or, in more simpler terms, if I have the complete code of the invoker (which has @Reference annotation and a wrapper method which actually invokes the service operation), can I compile, deploy and invoke the wrapper in the runtime?

As a last resort, I'm thinking of invoking the services using standard ws invocation mechanism.

Any help, or pointers is highly appreciated.

Thanks,

Prasenjit

[kcbabo]

No problemo.  If you are using a BPMN 2 based process, then it's already using service name to address a service.  You can update this to call a different service or even change your process to call new services.  Both options would require a new version of the process, but you can get that by using a knowledge agent + package URL in your SY deployment.  Basically, the app points to a process definition that lives outside the deployment (e.g. in Guvnor).  If you update the package containing the process definition, the knowledge agent can be configured to refresh.

An even more dynamic solution would be to use the DynamicRouter EIP inside a Camel route.  That would give you the ability to dynamically assign the name of the service being called without a redeploy/restart.  Here's an example of what that looks like:

http://camel.apache.org/dynamic-router.html

One thing to keep in mind is that even in the dynamic case, you are required to document all the possible services you may call as references.  This is a core design principle of SY and it allows us to track dependencies for your application.

[prasenjit.d]

Hi Keith,

Thank you for your responce.

DynamicRouter should solve my problem. I can define a hornetq binding for a camel service in SY. The service uses DynamicRouter to redirect to appropriate service based on the message input. I can send appropriate message to the queue from my jBPM task using custom task handler to invoke the routing service. This way, the bpm engine and the SY runtime can remain completely decoupled.

I'm not sure about the other option. My jBPM system is somewhat isolated and is not available to SY. I mean, The processes are not configured as SY services and they are executed separately. Can I still use "Switchyard Service" task? If I register SY task handler to the knowledge session, will it be able to locate the SY services? Is there a way to access the SY task handler instance from SY runtime? As the bpm process is not a SY service, documenting the references is not relevant, I guess.

I have one more question. It is possible to have multiple implementations for some of the services. Only one implementation can remain active at one time. Is it possible to change the implementation without redeploying? I'm thinking of using separate deployment units for such services, modify the SY xml, and redeploy. Is there is a way to interact with SY runtime service resolution to point to a specific implementation?

Thanks again,

Prasenjit

[rcernich]

I'm going way out on a limb here, but...

If your process is part of a SwitchYard project, you may be able to reference services using the SwitchYard task (assuming you have the SwitchYard task handler configured for your process).

As for dynamically specifying the process, if you can dynamically configure service name and operation name on the SwitchYard service task, you should be able to select which service you want to invoke.

As for selecting different implementations of a particular service, you do have the capability of having multiple components implement the same interface.  Just make sure you use a unique name for the service.  You can then delegate to whichever service you want.  So, the service names are different, but they are implementing the same interface.

Hope that helps a bit.

Rob

[prasenjit.d]

The problem is my process is not part of SY project. The processes are defined and executed at runtime. So, I guess, I cannot make them available as SY bpm service. My understanding is, the service should be available during development to make it available as SY service. Please correct me if I'm wrong.

If I configure a new instance of SY task handler for my knowledge session, will it be able to resolve the services at runtime? Does SY runtime supports multiple instances of the task handler? I think, only one instance (managed by SY) is the logical conclusion.

As for multiple implementation of a service, if I use different names for different implementations, aren't they becoming different services? At invocation point, I still need to know which one to use. In this case, I cannot rely on default name resolution for the references, I need to use fully qualified names in @reference annotation to make SY resolve the reference. I think, DynamicRouter can also be used to solve this. The actual implemenations can use same interface, but different service names. The router can decide what is the actual service to call.

I'm new to EE, but not to Java :-). All the pointers are actually openning new areas for exploration for me. Thank you all for helping me out.

Prasenjit

[kcbabo]

If your process is deployed in SY, then you can use the SY task handler to invoke SY services.  If your process is deployed separately, you'll need to find a way to invoke the SY services independently.  You can expose your services hosted in SY over a variety of protocols (e.g. JMS, HTTP/SOAP, TCP, etc.), so if you can call out from your business process over one of those protocols then you should be good.

The SY task handler needs to wire into our application domain (where services are registered), so it's unlikely that you will be able to create one on your own and wire it up outside of our deployment infrastructure.

What's your goal for multiple implementations of a service?  Strictly speaking, this is possible today in SY.  Multiple service providers can register a service at runtime using the same name.  What's not clear to me is what you hope to accomplish here, since as a consumer you won't be able to differentiate between the multiple providers - consumers address services by name only.  If you follow Rob's suggestion of using different names and the same service contract, then you have a lot more power in your dynamic routing logic to address a specific implementation of a service while using the same interface.

[dward]

Keith is correct regarding the SY task handler (of which there is only ever one registered per bpm component instance, btw).  For the SY task handler to work:

1. It needs to know both the service name and service operation name of what it should be invoking.  This is configured in the bpmn process definition.
2. A service reference with that service name needs to be specified in the SY configuration for the component the bpm implementation is specified in, so that the SY task handler has visibility to invoke it.

[prasenjit.d]

1. I am sending the name of the service to be invoked (and other parameters) to JMS from my process. The JMS queue is bound to a SY camel service. This service implements DynamicRouter which is routing to appropriate SY service based on the message. I hope this will work for me.

2. I'll follow Rob's suggestion. Multiple implementation of the same interface, but with different service names. I can control which service to call using other means (say, DynamicRouter).

Thank you all for your valuable suggestions.

Prasenjit

[edevera]

This topic is quite interesting to me. I have the requirements to support different service instances that can be discovered at runtime all of which satisfy the same interface.

The question is, does Switchyard allow me to choose the endpoint to call dynamically at runtime?