Marc Fiammante #ibmaot

From archive: July 2010

Sixth of Seven practices for Dynamic Process: Implement Service Variability

fiammante Tags: bpm business_process service variability polymorphism soa ‎ 6,541 Views

Variable Services or Service Polymorphism, in the context of object oriented programming, is the ability of one type, A, to appear as and be used like another type, B.

When applied to service invocation, we are talking about the ability to invoke one single service facade F, but actually invoke other services A, B, C etc, without the caller being aware.

Proxy Service
Intelligent Service
Business Service
etc.

So for an "open account" service we might have:

This may look simple for Object Oriented Practictionners but Web Services Interoperability standard WS-I states that "Operation name overloading in a wsdl:portType is disallowed by the Profile".
The consequence is that we have to find service variability techniques that use Enterprise Service Bus mediations or other dynamic endpoint resolutions to solve the problem.

This enables the consumer to interact consistently with a generic service, and abstracts the many possible implementations, or specific services, which may ultimately handle the request.

It is a key technique in maintaining flexible business processes
Implies that the business data is made flexible to hold variations without changing message structures.

In my book I have a full chapter on service variability and my colleague Scott Glen has written detailed articles in IBM DeveloperWorks address ways to implement service polymorphism.

Seventh of Seven practices for Dynamic Process: Use Information & Event Centric Processes where appropriate

fiammante Tags: business_process bpm soa eda event ‎ 6,217 Views

There are many processes that are information or business object centric. In such cases the entities have their own lifecycle and interact with the external world using services. Process analysts must however be careful on ensurign that they are now mixing business ownernship and separate the correctly the facettes that are owned by different owners in an organization. As an example the Telco standard information model clearly differentiates "the Customer Order" owned by customer facing organization from the "Service Order" and "Resource Orders" owned by other organizations in the enterprise.

Then the approach analyzes the state charts for each entity.

This approach can also be taken when different organization have to share a common entity such as a customs manifest declaration. The public entity and its public life cycle can be passed as an SCXML State Chart XML W3C SCXML Standard document. A reference implementation of SCXML available from Apache SCXML project.

The following picture describes such document bei exchanged between different organization and agencies, each with its own IT infrastructure. The only requirement is that each of those organization is able to interpret the SCXML standard to make out how the entity should be handled. It addition the document can carry the history of events that enables each stakeholder to reconstruct a monitoring view.

Feed for Blog Entries Feed for Blog Comments

Blogs