Client-side Service Composition Using Generic Service Representative

I’m back for a second day at CASCON, attending the technical papers session focused on service oriented systems.

First of the three papers was Client-side Service Composition Using Generic Service Representative by Mehran Najafi and Kamran Sartipi of McMaster University; this concept is presented to prevent the possible privacy and bandwidth problems that can occur when data is passed to a server-side composition. This relies on a client-side stateless task service and service representative, and doing whatever processing can be done locally before resorting to a remote web service call. Using the task services approach rather than a Javascript or RIA-based approach provides more flexibility in terms of local service composition. McMaster has a big medical school, and the example that he discussed was based on clinical data, where privacy is a big concern; being able to maintain the patient data only on the client rather than having it flow through a server-side composition reduces the privacy concerns as well as improving performance.

I’ve been seen this paradigm in use in a couple of different BPM systems that provide client-side screen flow (usually in Javascript at the client or in the web tier) within a single process activity; I’ve seen this from TIBCO AMX/BPM’s Page Flow, Salesforce’s Visual Process Manager and Outsystems. Obviously, the service composition presented in the paper today is a more flexible approach, and is true client-side rather than on the web tier, but the ideas of local process management are already appearing in some BPM products.

There were some interesting questions about support for this approach on mobile platforms (possible as the mobile OS’s become more capable) and a discussion on what we’re giving up in terms of loose coupling by having a particular orchestration of multiple services bound to a single client-side activity.