This post will discuss the various types of activity information that we may want to record from applications executing in an SOA environment. At this stage we are not concerned with how these events will be described in the activity event schema. We will also want to allow for extensibility, to enable users to define their own additional event types - so this thread is simply aimed at defining the initial scope of events that we should consider supporting.
The first set I want to deal with are the ones related to interactions between distributed components in the SOA:
1) Service Invocation
The invocation of a service, and any subsequent response can be viewed in terms of four separate events:
sending the request
receiving the request
returning a response or fault
receiving a response or fault
As these events are representing the RPC pattern, there would only be expected a single receive event for each send. These events will be associated with a service interface and operation, and therefore are distinguished from the following more general message passing events ....
2) Message Exchange
These can be described using two activity event types:
In this situation, there is no RPC style constraint, and therefore it will be possible to support other message oriented patterns, such as broadcast/multicast - so each send may result in zero or more receives.
Although service invocations can be viewed more generically as simply message exchanges, when analysing activity patterns, it would be useful to have some additional understanding of the interaction semantics. Its possible this could be encoded in the activity event information, but given that we are primarily targetting an SOA environment, then this distinction seems appropriate?
The main reason for initially focusing on interaction based events, is that they will be used to tie together the activities that occur within each of the services, to provide an overall view of the activity associated with a business transaction.
Other activity events, such as those that might be generated by components in an ESB, or processes within a BPM, will be discussed in subsequent entries on this thread. When considering what are suitable events, we need to have a view on how the information will be used. Generally we need to be looking for information that can help an organisation understand how often business relevant tasks are performed, and how long they take to perform, as this can be used to tune how the overall business transaction is executed.