Monday, November 10, 2008
Relationship -1
In SOA ecosystem Security, Governance, Operations, Quality are closely related. Each face of SOA ecosystem affect other.
Remediation Framework
Remediation framework plays very important role in any SOA ecosystem. It can be though of extension of Error & Exception Management and Transaction Management frameworks. Remediation framework leverages Error & Exception Management Framework by utilizing logged error & exceptions. It also supplement Transaction Management Framework via helping to implement relaxed ACID where human intervention might be needed. Remediation framework also makes whole of SOA ecosystem robust via utilizing compensatory services.
Tuesday, November 4, 2008
Exception & Error Management
Exception & Error Management is consist of
Exception & Error Handling
Exception & Error Logging
Exception & Error Notification
In any enterprise under SOA ecosystem Exception & Error Management poses following challenges:
Exception & Error Handling
No predefined format for passing exception information among participating services
Webservices do not have capability of maintaining stack trace
Lack of common exception vocabulary across enterprise
Exception & Error Logging
Scattered logs across services/applications
Varying formats of logs across services/applications
Toggling logs at run time is service/application dependent
Exception & Error Notification
Every enterprise/LOB has its own unique notification requirement
Toggling Notification at run time is necessity
SLA and exceptions are coupled
To counter these challenges there must be a comprehensive Exception and Error Management framework which can manage at enterprise level and form the foundation for Remediation framework.
On the high level, Exception and Error Management framework’s architecture can be depicted as follows:
Exception & Error Handling
Exception & Error Logging
Exception & Error Notification
In any enterprise under SOA ecosystem Exception & Error Management poses following challenges:
Exception & Error Handling
No predefined format for passing exception information among participating services
Webservices do not have capability of maintaining stack trace
Lack of common exception vocabulary across enterprise
Exception & Error Logging
Scattered logs across services/applications
Varying formats of logs across services/applications
Toggling logs at run time is service/application dependent
Exception & Error Notification
Every enterprise/LOB has its own unique notification requirement
Toggling Notification at run time is necessity
SLA and exceptions are coupled
To counter these challenges there must be a comprehensive Exception and Error Management framework which can manage at enterprise level and form the foundation for Remediation framework.
On the high level, Exception and Error Management framework’s architecture can be depicted as follows:
Monday, November 3, 2008
Transaction Management
Transaction Management is one of the most difficult aspects of any enterprise architecture due to varying level of understanding among stakeholders, various technological platforms involvement and spread of transactions – intra & inter enterprise.
In general any enterprise grade transaction framework follows ACID but due to presence of long running business processes and involvement of asynchronous communication traditional ACID becomes irrelevant. To accommodate long running business processes and asynchronous communication relaxed ACID is used which allows violation of ACID but with capability of correcting the violations in reasonable time period and with little business impact.
SOA capable enterprise grade Transaction Framework should have following features:
· Multi level undo/redo
· Coalescing of transactions
· Automatic aggregation of nested transactions
· Supports batching of transactions (Aggregation)
· Rollback of aggregated transactions for error recovery
· Listener support
· Synchronous and Asynchronous Transaction
· Compensatory Service
· Transaction Propagation
In general any enterprise grade transaction framework follows ACID but due to presence of long running business processes and involvement of asynchronous communication traditional ACID becomes irrelevant. To accommodate long running business processes and asynchronous communication relaxed ACID is used which allows violation of ACID but with capability of correcting the violations in reasonable time period and with little business impact.
SOA capable enterprise grade Transaction Framework should have following features:
· Multi level undo/redo
· Coalescing of transactions
· Automatic aggregation of nested transactions
· Supports batching of transactions (Aggregation)
· Rollback of aggregated transactions for error recovery
· Listener support
· Synchronous and Asynchronous Transaction
· Compensatory Service
· Transaction Propagation
Friday, October 31, 2008
Event Management
To exploit SOA to its full extent event handling plays crucial role. In SOA environment Events can be classified into three categories
1. Generic Event
Event fired/raised in response of event or interaction with other service/s.
2. Time Based Event
Event fired/raised at particular moment of time to perform certain task
3. Heart Beat Event
Event fired/raised by services at regular interval to announce its existence and may be level of throughput it is working.
Generic Event Handling
These are events which fire/raise other events or results due to interaction of services in ecosystem.
1. Event Generator generates events with minimal data set.
2. These events should be formatted as per the event protocol defined in ecosystem, so that theses event are available to entire ecosystem for further processing.
Ø Event Pre-processing: Check that mandatory attributes are present in the incoming events
Ø Event Refinement: Introduce the other system-generated attributes like start time etc.
Ø Situation Refinement: Check the target status on which action would be performed
Ø Impact assessment: Required result assessment after that impact applies on the target
3. Event factory determine the specific type of action, which the given event have.
4. Event listener executes the specific action, which stated at the specific action code. There we have some general action apply to all type of system is present in generic action code and specific to specific action is present in the specific action listener
5. Event listener executes the action and calls the required system to complete it.
6. Some event, which completed their actions, and no further support needed from any other services are terminated
7. Some events which need further processing from some other services or may be generate other event in response of event is send back to the event engine
8. Event in response of event is again run as a new event and again it initiates its processing cycle in the event engine
Time Based Event Handling
Scheduled event delivered to a service at specific time in the future. Event deliveries can be deferred for short periods of time (such as seconds or minutes) or for long stretches of time (for example, hours later for batch processing). Until that delivery time, the Event is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.
Heart Beat Event Handling
Heartbeats, a common software construct, verify the continual operation of a specific service. With heartbeats, a targeted service continually broadcasts a signal across its environment. System works normally when client services can detect a targeted service's heartbeat signals
There is number of interdependent services in SOA ecosystem such that, if one failed, others will also fail.
Heartbeat generally propagated across SOA ecosystem using publish/subscribe paradigm.
1. Generic Event
Event fired/raised in response of event or interaction with other service/s.
2. Time Based Event
Event fired/raised at particular moment of time to perform certain task
3. Heart Beat Event
Event fired/raised by services at regular interval to announce its existence and may be level of throughput it is working.
Generic Event Handling
These are events which fire/raise other events or results due to interaction of services in ecosystem.
1. Event Generator generates events with minimal data set.
2. These events should be formatted as per the event protocol defined in ecosystem, so that theses event are available to entire ecosystem for further processing.
Ø Event Pre-processing: Check that mandatory attributes are present in the incoming events
Ø Event Refinement: Introduce the other system-generated attributes like start time etc.
Ø Situation Refinement: Check the target status on which action would be performed
Ø Impact assessment: Required result assessment after that impact applies on the target
3. Event factory determine the specific type of action, which the given event have.
4. Event listener executes the specific action, which stated at the specific action code. There we have some general action apply to all type of system is present in generic action code and specific to specific action is present in the specific action listener
5. Event listener executes the action and calls the required system to complete it.
6. Some event, which completed their actions, and no further support needed from any other services are terminated
7. Some events which need further processing from some other services or may be generate other event in response of event is send back to the event engine
8. Event in response of event is again run as a new event and again it initiates its processing cycle in the event engine
Time Based Event Handling
Scheduled event delivered to a service at specific time in the future. Event deliveries can be deferred for short periods of time (such as seconds or minutes) or for long stretches of time (for example, hours later for batch processing). Until that delivery time, the Event is essentially invisible until it is delivered, allowing you to schedule work at a particular time in the future.
Heart Beat Event Handling
Heartbeats, a common software construct, verify the continual operation of a specific service. With heartbeats, a targeted service continually broadcasts a signal across its environment. System works normally when client services can detect a targeted service's heartbeat signals
There is number of interdependent services in SOA ecosystem such that, if one failed, others will also fail.
Heartbeat generally propagated across SOA ecosystem using publish/subscribe paradigm.
Service Life Cycle Management
Service Life Cycle Management essentially help in managing service life cycle from its conception to decommission. This is one of the vital component which determine the success of SOA initiative in any enterprise and also its long term viability.
Rule/Policy Repository & Engine
Rule/Policy Repository contain various Business Rules and Governance & Security Policies. The engine part of the same will help in execution of Rules ans Policies as and when demanded.
Subscribe to:
Posts (Atom)
Posts
