Services Life Cycle - Production Point of View

A service life cycle may be expressed from various points of view. Here I am trying to explain life cycle of a service based upon its running conditions. I call this point of view as “Production point of view”. The other point of view could be based upon development life cycle which is more concerned with management aspects.

A service life cycle can be expressed in the state transition diagrams below. There are two separate transition paths:
– service itself
– request processing

• Service
– To be used, a service must be realized by a concrete provider agent.



A service may live in two states:


• UP — the provider agent is capable of accepting and processing requests (i.e. the service is available).
• DOWN — the provider agent is not capable of accepting any requests (i.e. the service is not available).

Naturally service will also transition between these two states. Transition states might be:

Birth: Start of current life  Service starts its current life in Up State
Death: End of current life  Service ends current life from Down State

• Activate — the service can become available which transitions it from Down to Up state.
• Suspend — the service can become unavailable which transitions it from Up to Down state.

Now let us elaborate details of each state

Sub States of Up State




• States
• Idle — the provider agent is not processing any requests currently.
• Busy— the provider agent is processing requests currently.

• Transitions
• Birth with Work: A service may start its life with work in hand and enters into BUSY sub-state of UP state
• Birth without Work: A service may start its life without work in hand and enters into IDLE sub-state of UP state
• Got Work: A service transitions from IDLE sub-state to BUSY sub-state of UP state.
• Work Finished: A service transitions from BUSY sub-state to IDLE sub-state of UP state.
• Retiring: A service leaves UP state (from BUSY or IDLE sub-state) and enters into DOWN state.

Sub States of Down State



• States
• Paused: The service is intentionally paused (e.g. for administrative purposes).
• Stopped: The service is intentionally stopped (e.g. for administrative purposes).
• Over whelmed: The provider agent has exhausted its resources and cannot accept any new requests.
• Crashed: The service is unavailable because of an internal malfunction of the provider agent (e.g. environmental problem).

• Transitions
• A service enters DOWN state in a PAUSED, STOPPED, CRASHED or OVER WHELMED sub-state.
• Stopping - A service may be stopped from any UP or DOWN sub-state except from CRASHED sub-state.
• Crashing: A service may be crashed from any UP or DOWN sub state except from STOPPED sub-state.
• Pausing: A service may be paused from any sub-state of UP state.
• Hanging: A service may be over whelmed from any sub-state of UP state.
• Activate: A service may enter into UP state from OVER WHELMED & PAUSED sub-state of DOWN state.
• Dying: A service may be dead from STOPPED and CRASHED sub-state of DOWN state.


Reference:

http://www.w3.org/TR/wslc/

Use case Template

I have developed a use case template. This template is in continuation of the process template which one can use in SOA and/or EPM/BPM projects.

This template is slightly different from other templates which you will find at various sites. This template have provision to specify navigation details. I understand that purist will certainly be against this approach but in practical world most of the us find visualizing a software which has some kind of user interface easier.

Let me know any comments from your side.

Document is at scribd.com

Service in eGovernment

Definition:

Service can be defined as system or organization that provides stakeholders with some thing that they need/ask for or and consequence of execution of it.

Stakeholders involved may be people, organizations or systems.

Stakeholders:

1. Client
a. Citizen
b. Business
c. Public Administration Organization
2. Service Organization
a. Service Provider
b. Evidence Verifier
c. Evidence Provider
i. Primary
ii. Auxiliary
d. Consequence (Auxiliary Outputs) Receiver
e. Primary Output Receiver
3. Service Broker
a. Service Repository
b. Interoperability Agent

Service Interaction:

The Client contacts a Service Provider (Public Administration Organization) and asks for a service that requires for its execution input from organizations located in national/states/municipalities across India. The Service Provider, after gathering from these countries all evidences needed for Service execution, executes the Service based on predefined Rules and provides Client with an output (Primary Output) and all organizations with the consequences (Auxiliary Outputs) of the Service.

Preconditions:

A client identifies service organization and ensures that potential service exists. Client provides minimum set of evidences (primary inputs) needed for initiating the service identification. Client may also supply Auxiliary inputs ( in form of evidences and references to evidences) as required by service contract.

Post conditions:

Client receives the Output (primary output) of service execution and participatory organizations receive consequences (Auxiliary Outputs).


Interaction Model:



Description:

Participating Roles

Client
Primary Output Receiver
Service Provider
Broker (Service Repository, Interoperability Agent)
Evidence Provider
Evidence Verifier
Consequence Receiver

Description of Steps

Step 1. A client requests for service. He/she supplies some evidences and some references to evidences. Evidence supplied by client may be categorized as:
1. Evidence required for identification purpose
2. Evidences needed to fetch more evidences from evidence providers
3. Evidences needed to execute service

Less evidences supplied by client to Service Provider, transparent is the service. Of course number and type of evidences required are service specific.

Step 2. Service provider supplies the evidences/credentials of client Broker that in turn passes the same to Evidence Verifier. Evidence Verifier verifies credentials of Client and accordingly supplies the results to Service provider via Broker. Now Client has an Identity.

Step 3. Service Provider looks up for more evidences on the based of identity established for client and references provided by client with the help of Evidence Providers via Broker.

Step 4. Evidences collected from Client, Evidence Suppliers are passed to Evidence Verifiers via Broker.

Step 5. On positive out come of Evidence Verifiers, Service is executed. The outcomes of service are passed to Primary and Auxiliary Output Receivers.

Class Model:

The interaction model can be depicted in class model in two parts

1. The Operational (Transactional) Part
2. The Knowledge (Planning) Part

The Operational Part



The Knowledge Part



Reference:

1. Fowler, M., Analysis Patterns. Object Technology Series, 1997: Addison-Wesley

Inter Service Dependency Model

In any SOA ecosystem, there are bound to be numerous services. Some of the services in will be core services which will be used by most of the services. If this interdependency is not maintained, it may result in spaghettiof services. To have an ordered SOA architecture, one must rely on proven layered architecture which ensures robustness and independence of non adjacent layers.

To measure inter dependence of services, I have developed a simple but effective model, which I call Inter Service Dependency Model. This model is inspired by DSM (Design Structured Matrix.

In this model, services are viewed from provider and consumer perspective and emphasis is on maintaining layered based architecture principles in SOA ecosystem.



The matrix is divided into three distinct areas. The Solid BLACK region is the demarcation between RED and GREEN. One should fill value in GREEN and RED region cells to illustrate inter dependency of services. This dependency strength generically can be defined as



In a well designed SOA eco system following conditions should exist:

1. Matrix is populated only with Zero and Positive numbers
2. RED region is populated with Zero
3. Black region must not be populated ( pretty obvious)
4. GREEN region should be populated with positive numbers.

Above mentioned conditions still not address adjacent layer dependency only. To address that one should be able to figure out structure of GREENs and may also club services into layers.

Reference:

1. http://www.dsmweb.org/
2. http://ausweb.scu.edu.au/aw08/papers/edited/mehboob/paper.html
3. http://www.stsc.hill.af.mil/crosstalk/2005/11/0511SangalWaldman.html
4. http://www.lattix.com/technology/whatisdsm.php
5. http://en.wikipedia.org/wiki/Dependency_Structure_Matrix

Composite Services Complexity Measure

While evaluating a service complexity, I developed few of the measure. One of the measures is Complexity Measure which considers depth of service or we can say composition depth of service.

For this measure composite services were divided into four types:

1. Sequential Composite Services
2. Co-ordination Composite Services
3. Recursive Composite Services
4. Complex Composite Service



So Complexity Measure for:

Sequential Composite Service:

Composite Service Depth, CSD = Distance to the farthest service in sequence

Co-ordination Composite Service:

Composite Service Depth, CSD = Arm Count

Recursive Composite Service:

Composite Service Depth, CSD = (Optimistic recursion count + Pessimist recursion count)/2

Complex Composite Service:

Composite Service Depth, CSD = Sum of (Composite Service Depth in terms of Sequential, Recursion and Co-ordination manner)

For a good implementation CSD should not be more than 3 to 5. But in reality, most of the time consumer of a service is not aware of complete service tree.

Recursive composite service must be avoided.

As a good practice, each service should publish its CSD count.

Process Catalogue Template

Few posts back I have published a process template. In continuation here is now Template for process catalogue. Use it as you wish. Also let me know any changes you require.

Get this doc from:

Software Production

Recently I was at conference by leading software service provider from USA. Service provider making claims that they have developed a methodology which converts development of software is like any product in a factory. Before critical assessment of this claim let us see how production is carried out is a real factory.

In today’s world there are two dominant production methodologies:

1. Stationary Platform methodology
2. Assembly Line methodology

Stationary platform methodology is used only in highly complex and huge products like airplanes, space shuttle, etc.



Assembly line methodology is widely used and approximate covers all type of products – automobiles, household appliances, etc.



Stationary platform methodology also takes advantage of Assembly Line methodology via manufacturing of components in assembly line and then assembling on a stationary platform.

There is also third methodology which is followed by craftsmen, fabricators, highly customized goods, etc. I called it Craftsmen Approach.

Now come to software development. What approach does today’s software industry follows? My reasoning says Craftsmen Approach. In software industry we have lot of automation and sophisticated tools but still they just assist in fasten the process and managing the complexity of product (which is software). These tools do not bring any paradigm change in software development methodology. These tools are like replacing manual chisel and hammer by electrical driven tool set.

If you see both pictorial representations of Stationary and Assembly line methodologies, process is preexisting. It just gets applied during manufacturing. But software development results in formalization of process itself which has to be very flexible so that it can be changed in future if need arises. Also every production cycle of software results in unique product. This very similar to unique end product created by craft man.

Thirdly Assembly Line Methodology is good for mass production. Do we do mass production in Software development?

So do we still in pre industrialization phase viz a viz software development or software development will always be crafts man domain till machine intelligence is capable enough for creativity and innovation?

Process Design

In most of the cases BPM deals with existing process where process designer picks up the existing process, optimize it as per the given mandate and finish off his/her work. Does this expose him/her to best practices of process design?

So the steps of process design are:

1. Concept: The Idea  what do you want to do?
2. Form: The Process  The process and the result of process(product)
3. Content: The Meaning  Does form satisfies the concept?

In a well designed process cater to following class of changes:

1. Change in State: Transition to one state to another during the course of execution of process. For example in Quote to Cash process change in state of Quote to Order.
2. Internal Changes: Changes in other processes which are within the realm of enterprise/s to whom process is catering. For example change in price of an item while a Quote to Cash process is in middle of execution. Price change is another process.
3. Environmental Changes: These changes are most of time beyond control of participating enterprises. For example change in tax structure while a Quote to Cash process is in middle of execution.

In any process Class 1 changes are accounted for because they form the normal exertion path of a process. Class 2 changes are also accounted in most of well designed process either as Class 1 changes or exceptions or via versioning path. Class 3 changes are not taken care in most of the process design due to resultant complexity and thin chances of occurrence of these changes. Class 3 changes can be accounted either as Exception, using versioning or catastrophe. If Class 3 changes are not accounted in process design this may result in chaos.

To design a process following models can be used by various players of game.

1. Value Stream Mapping: This mapping technique is widely used by Six Sigma and Lean professionals.
2. Event Modeling: This technique is widely used by Process Reengineering professionals.
3. Object Modeling: This technique is widely used by software professionals to model software as real life objects. For details you can refer to OOPS and OOAD literature.
4. Data Modeling: This is one more technique which is widely used by software professionals to design data intensive software.
5. Process Interaction Model: This is the models which caters to intra and inter process interaction. This model is borrowing concepts from Control engineering and ARIS methodology. This model is under development and soon I will release more details about it.

Business and System Analysts use Value Stream Mapping, Event and Process Interaction Models to define, refine and model a process. Technical Architects and Designers use Object Model, Data and Process Interaction Models to come out with technical specifications and actual design.

Process Design Good Practices

1. Design for present but do not loose sight from future.
2. Take account of Class 1 events and Class 2 events.
3. Manage Class 3 events keeping complexity in full view.
4. Balance between automation and manual tasks to keep process simple.
5. Strive for perfection but watch out for complexity, so balance.

Reference
1. http://en.wikipedia.org/wiki/Value_Stream_Mapping
2. http://www.isixsigma.com/dictionary/Value_Stream_Mapping-413.htm
3. http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
4. http://www.ooad.org/
5. http://en.wikipedia.org/wiki/Data_flow_diagram
6. http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm
7. http://en.wikipedia.org/wiki/Dataflow
8. http://en.wikipedia.org/wiki/Event_model
9. http://msdn.microsoft.com/en-us/library/ms533023(VS.85).aspx
10. http://www.actiontech.com/BPM/BIM.cfm
11. http://process-interaction-models.info/

Book Review: SOA Cookbook: Design Recipes for Building Better SOA Processes by Michael Harvey

ISBN #: 978-1-847195-48-7

SOA Cookbook may be considered one of the few books in SOA world which talk SOA as Process and further the argument with support of real life SOA platforms from leading vendors, namely IBM, Oracle, BEA and TIBCO.

SOA Cookbook is divided into nine chapters which encompass preliminary as well as complex aspects of SOA in seamless fashion. This book exposes architects and designers various aspects of SOA and BPM like Orchestration, Choreography, Event Handling, Change Management and services and processes, etc. It is advisable to understand basics of BPEL before hand. Chapter 4 onward, BPEL plays major role in understanding of the book.

With its entire good things book leaves some loopholes to be covered, like distinction between BPM and workflow, usage of B2B in inter enterprise integration, difference in EAI and process integration, etc.

This book is must in any software architects’ book collection to keep reminding basics of SOA and its practical implementations.

SOA Cook book is available here.

Book certainly gives lot of pointers for new thoughts.

Orchestration & Choreography

I generally encounter discussions and questions from various Architects, Designers and Business Persons discussing Orchestration and Choreography. It seems to me that these two topics hotly debated and misunderstood in the context of SOA. I also want to add my voice to the noise.

I understand Orchestration and Choreography from their dictionary meanings.

Orchestration:

1. Noun: To arrange something carefully, and sometimes unfairly, so as to achieve a desired result (Cambridge Advanced Learner's Dictionary)

2. Noun: The arrangement of a musical composition for performance by an orchestra; also: orchestral treatment of a musical composition (Merriam-webster’s online dictionary)

Orchestration Examples:

1. In a concert conductor is giving instructions to players of violin, piano and other instruments to modulate pitch and volume to create music. Conductor is essentially passing instructions at the time of actual performance.
2. A road crossing at which vehicles are following traffic rules in the presence of traffic police personnel. In real time depending upon traffic flow in different directions, traffic policeman takes action and ensures smooth flow of traffic.

In both the cases there is a central body which controls the performance of participants (performers and vehicles) for successful execution of a task

Choreography:

1. Noun: the skill of combining movements into dances to be performed (Cambridge Advanced Learner's Dictionary)
2. Noun: the composition and arrangement of dances especially for ballet (Merriam-webster’s online dictionary)

Choreography Examples:

1. Sandeep Soparkar choreographed a dance sequence Britney Spears stage performance. In this scenario Sandeep has defined every step of dance well ahead of the performance so Britney and her stage co-performers are just enacting the same.
2. A road crossing at which vehicles are following traffic rules without presence of traffic light or traffic police. These rules are defined in advance. Each vehicle is just following them for smoother and safer movement.

In both cases the participants (performers and vehicles) are following some predefined rules for successful staging of drama.

In SOA context, I will carry forward the argument and define the Orchestration and Choreography on same lines.

Orchestration:

1. It is done at run time.
2. There must be some central body, which controls the flow of the message and behavior of each participating service. This central body may be logical entity or set of rules/protocol.

Participating services are not aware of each other and even they are not aware of their involvement in orchestration.

Choreography:

1. It is done at design time
2. There is no logical entity to control the behavior of participating services but a set of rules/protocol exists which controls interaction of services.
3. Participating services are aware of each other and know when to execute their operations



So, how in real life Orchestration and Choreography played out in SOA universe.

In real life SOA implementation of services are done in the form of small business processes, which are state aware. In these processes services remain stateless but not the whole process. Individual services are not aware of their involvement in any process. This is the case for Orchestration. The central hub/rules/protocol decides how different services will interact. Most of the routing is content aware and depends upon result of execution of participating services.

Choreography can be thought of integration of small business processes, which are directly made up of services. The resultant grand business process might involve workflow. So in this grand process smaller constituent business process need not to expose all of its functionality beyond boundaries of itself. Small business processes have some private functionality and some of publicly exposed. Publicly exposed functionalities are exploited to integrate them and reach at grand business process where no central hub is defined so no run time decision. All decisions have been made at design time.