Ayanthi has published the presentation done by Dr. Sanjiva Weerawarana at the SOA symposium on cloud computing.
I'd like to add this presentation done by Dr. Rajkumar Buyya from the Grids Lab to it. This was presented today at the university and it brought a very interesting discussion.
The presentation discusses the evolution of Cloud Computing and how is it different from other paradigms such as Cluster and Grid. Further it discusses about certain case studies that used the Gridbus middleware.
And some interesting definitions for "Cloud Computing can be found here. [Beware 21 of them]
Friday, April 17, 2009
Wednesday, April 15, 2009
Workflow management systems. A liability or an asset?
Today more workflow systems appear to assist the business process management. The usual procedure is to draw a business process as a workflow diagram using a notation such as BPMN which will be converted to a code or more preferably to a process execution language script such as WS-BPEL (aka BPEL4WS).
This works fine until there is a requirement for a change in the process flow. The change can be a permanent one or it can be an ad-hoc one that caters for an exceptional situation. In the first case the process definition is changed which is known as an evolutionary change/adaptation. Where all the future instances of the process definition adhere to the new one. In the case of ad-hoc change only a particular process instance is changed which is known as momentary change thus would not affect the future instantiations.
One solution for this is to include all the possibilities into the process definition. For example BPEL switch statement. But some run time changes cannot be predicted during the design time. And even it could, the plethora of possibilities can make the design a very messy and complicated one.
Thus a running business implementation may have a business process but the frequent ad-hoc change might make it a liability than an asset. Making the stakeholders to by-pass the workflow definition rather than adhering to it. Thus it is required to find more flexible ways to design business processes that facilitate the frequent adaptation or change.
This will be my first post on this and will be followed by a series of discussion that will discuss the possible strategies to face the above challenge.
This works fine until there is a requirement for a change in the process flow. The change can be a permanent one or it can be an ad-hoc one that caters for an exceptional situation. In the first case the process definition is changed which is known as an evolutionary change/adaptation. Where all the future instances of the process definition adhere to the new one. In the case of ad-hoc change only a particular process instance is changed which is known as momentary change thus would not affect the future instantiations.
One solution for this is to include all the possibilities into the process definition. For example BPEL switch statement. But some run time changes cannot be predicted during the design time. And even it could, the plethora of possibilities can make the design a very messy and complicated one.
Thus a running business implementation may have a business process but the frequent ad-hoc change might make it a liability than an asset. Making the stakeholders to by-pass the workflow definition rather than adhering to it. Thus it is required to find more flexible ways to design business processes that facilitate the frequent adaptation or change.
This will be my first post on this and will be followed by a series of discussion that will discuss the possible strategies to face the above challenge.
Subscribe to:
Posts (Atom)
