Nowadays, when SOA is a standard across many enterprise systems and it is a relatively intuitive way do describe the domain of the enterprise it is still not enough. The standard, sequential RPC request response SOA operation model does not integrate well with concept of business processes which very often besides being request/response driven, they tend to act more naturally in event based enviroment. Because of that Advanced SOA was introduced which adds the notion of a business event and event-driven architecture (EDA).
1. The RPC request/response style is about a chain of requests based on previous requests. A common way to represent this style according to buisness processes is to use directed graph or finite automata of states of the process and transitions between them. To describe this behaviour we can use an example of an architecture where each service is activated only by other service or client. Particular ativation is time based on set of rules which define the flow of entire execution of the process involving set of services belonging to the architectur. In relation to our finite automata example, in request/response based architecture client defines and directs the execution of the automata.
2. The Event Driven Architecture (EDA) in cotrast to request/response SOA defines a series of events that may overlap and dependence on previous events is not required. However, still included in the EDA, there is one special case known as 'complex event' which is ordinary event but triggered by by other set of events in particular order or combination. The data structure which suits EDA is a 'paraller graph'. Each node represents the sate of buisness process and is attached to certain event(s) which may or may not trigger exectution of certain service, execution timing is undefined. To examplify the EDA we can imagine events as some buisness occurrences (employee starts the work, the inventory is empty, new offer placed etc.) which will alert all interested subscribers of any changes. Events are sent to event handlers in form of a message what results in event handlers calling right service to handle the event. In this approach, events occur if they need to and handlers and services simply wait to be notified of the events about which they care of.
1. The RPC request/response style is about a chain of requests based on previous requests. A common way to represent this style according to buisness processes is to use directed graph or finite automata of states of the process and transitions between them. To describe this behaviour we can use an example of an architecture where each service is activated only by other service or client. Particular ativation is time based on set of rules which define the flow of entire execution of the process involving set of services belonging to the architectur. In relation to our finite automata example, in request/response based architecture client defines and directs the execution of the automata.
2. The Event Driven Architecture (EDA) in cotrast to request/response SOA defines a series of events that may overlap and dependence on previous events is not required. However, still included in the EDA, there is one special case known as 'complex event' which is ordinary event but triggered by by other set of events in particular order or combination. The data structure which suits EDA is a 'paraller graph'. Each node represents the sate of buisness process and is attached to certain event(s) which may or may not trigger exectution of certain service, execution timing is undefined. To examplify the EDA we can imagine events as some buisness occurrences (employee starts the work, the inventory is empty, new offer placed etc.) which will alert all interested subscribers of any changes. Events are sent to event handlers in form of a message what results in event handlers calling right service to handle the event. In this approach, events occur if they need to and handlers and services simply wait to be notified of the events about which they care of.
The article tries to answer the question of which approach event or request based should be taken into special consideration when implementing the Business Processes using SOA and how to make the best of it ?
Almost always it is necessary to create explicit business process model associated with events. When all events are identified and are used, services may be used through event handlers as responders to the events. When may responses of the service are tided to related business events the result is another business process. These processes should be extracted from the main model and request based model should be built for them.
Event based systems are uncoupled in contrast to request driven system which means that events , handlers and services are not part of one common implementation, rather connected logically during the design process and physically when system goes on-line. Because of that it good to formally define relations between particular events and services.
Services are reusable , easy discoverable and well described. When using services as event handlers, they may be subscribed to events which represents business actions. This approach helps to maintain modularity of SOA system and ensure that data facing business logic will not be duplicated. Last but not least, the approach to increase performance of the system especially event driven it is recommended to build services as multi instance services which allows the service to be executed concurrently when some events in the business process model may intersect. 
In this case special attention for providing synchronization, data
consistency and performance in case when runing many instances is required.
The title of summarized article: BPM Design Guidelines for a Request-Driven SOA vs. an Event-Driven SOA @ http://www.gartner.com/
Services are reusable , easy discoverable and well described. When using services as event handlers, they may be subscribed to events which represents business actions. This approach helps to maintain modularity of SOA system and ensure that data facing business logic will not be duplicated. Last but not least, the approach to increase performance of the system especially event driven it is recommended to build services as multi instance services which allows the service to be executed concurrently when some events in the business process model may intersect. In this case special attention for providing synchronization, dataconsistency and performance in case when runing many instances is required.
The title of summarized article: BPM Design Guidelines for a Request-Driven SOA vs. an Event-Driven SOA @ http://www.gartner.com/
No comments:
Post a Comment