Your comments will make this book useful and valuable.
Friday, May 16, 2014
BPEL PM 11g Performance Tuning - Final installment
Your comments will make this book useful and valuable.
Thursday, May 15, 2014
BPEL PM 11g Performance Tuning - 8
Your comments will make this book useful and valuable.
Wednesday, May 14, 2014
BPEL PM 11g Performance Tuning - 7
Your comments will make this book useful and valuable.
Friday, December 9, 2011
Sunday, May 9, 2010
Monday, February 8, 2010
Monday, January 12, 2009
Book Review: SOA Cookbook: Design Recipes for Building Better SOA Processes by Michael Harvey
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.
Friday, January 9, 2009
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:
- 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.
- 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:
- Noun: the skill of combining movements into dances to be performed (Cambridge Advanced Learner's Dictionary)
- Noun: the composition and arrangement of dances especially for ballet (Merriam-webster’s online dictionary)
Choreography Examples:
- 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.
- 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:
- It is done at run time.
- 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.
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.
Sunday, December 7, 2008
Enterprise SOA Reference Architecture
Reference Architecture is independent of platforms offered by various vendors. It is also possible that none of the vendors in market provide complete solution to realize this reference architecture.
Data Persistent Layer is primarily consists of Enterprise Data - Master, Transaction and Meta. It may also include Datamart and Data driven reporting infrastructure.
In most of the large enterprises Data Persistent Layer consists of relational (RDBMS), hierarchical (LDAP, IMS), unstructured (Emails, chat sessions, file systems, etc) and any other type. These variations in data characteristics warrant unique data handling and treatment technologies.
This Layer consists of different business applications. These applications may be packaged (e.g. SAP, Reteck, etc) or may be custom developed in various technologies (e.g. Java, .Net, etc). Again application in this layer may be service enabled or legacy once, which do not expose their functionalities as service.
At this layer EAI exist. Some may argue that SOA is one form of integration then how EAI can exist at this layer. I will discuss this argument in one of my future posting but not now.
Services Layer
This layer is consists of multiple sub layers which encapsulate different class of services. It encompasses Connectivity Services, Data Services, Business Activity Services and Business Process Services. Each layer in turn consists of other sub-types of services.
This layer exposes different aspects of business - functional and infrastructural aspects. Connectivity and Data services are consisting of Infrastructural services while Business Activity and Process services expose functional Services.
These services though in layers but still breach layered architecture to expose these services independent of layers and for better performance. These services can also be exposed to multiple ESBs if situation warrants.
1. Connectivity services primarily cater to accessing system level functionalities, any adapter & connector services and partner (B2B) integration services.
2. Data services comprises of services, which caters to Business, Technical and Meta data related services.
3. Business Activity Services consist of Atomic business/functionalities and any custom business logic developed by combing one or more Data & Connectivity services.
4. Business Process Services primarily consist of Process integration, Machine and Human centric services. These services primarily comprise of Business Activity services.
Orchestration
Routing
Mediation
Enrichment
Some ESBs may provide one more functionality - Choreography. This functionality is associated with BPM systems and currently none of Commercially available ESB provides the same.
Enrichment may be of two types: Data Transformation and Channel Transformation. Most of the analysts & architects keep Data Transformation & Channel Transformation separate functionality.
Human
- Thin Client
Browser clients: May be based on traditional HTML based or AJAX based
Portable devices: May be based on open standards (WAP) or propitiatory (device or carrier specific)
- Thick Client
Alway Connected: These clients connect to service providers and consume the services in real time. Traditional think client falls in this category
Offline Clients: These clients do not connect to service providers in Always On fashion but an actor can work in offline mode and when ever connectivity available, services consumed. Java WebStart and Adobe AIR are two most widely used technologies in this field.
Voice Based Client
Voice based clients are gaining popularly to reduce load on contact center. To facilitate this type of user interface, IVR plays great role.
Machine
These types of interfaces are not very obvious but very prevent at enterprise level. Application level interaction (Software to software) and interaction with various devices like RFID tags, Bar code readers, etc (Hardware to Software or vice versa) are part of this type of interfaces.
Most of the large enterprises also get integrated with external world. This integration is both ways - information flow is in both directions. To further complicate the scenario, enterprises increasingly using SAAS. This situation requires special attention and tools. In case of integration with business partners B2B Engine plays major role in conjunction with Partner services. SAAS services may be consumed directly or via B2B engine. In case of Human interaction (CRM - Salesforce.com) B2B Engine should be bypassed but for m/c interaction or substantial data transfer (Document management for insurance companies) B2B engine should be engaged.
Security in SOA is one of the biggest concern due to distributed & heterogeneous systems interacting with each other. The security related aspects should be handled at each level of enterprise. In the proposed model security is considered from physical and virtual perspective. It also takes into account security from network and application view.
At monitoring front it take care of Technical - For support staff, Process & Managerial - For business process owners & managers and Executive - for top rung of business leadership requirements.
Governance is one of the burning issues in SOA environment. To discuss SOA Governance's Technical architecture, it is necessary to understand SOA Governance model.
Following figure depicts the SOA Governance Model.
The picture below intends to depict SOA Governance Technical Architecture.
Service Life Cycle Management essentially helps in managing service life cycle from its conception to decommission. This is one of the vital components, which determine the success of SOA initiative in any enterprise and also its long-term viability.
Rule/Policy Repository contains various Business Rules and Governance & Security Policies. The engine part of the same will help in execution of Rules and Policies as and when demanded.
Service directory essentially consists of UDDI, which facilitates consolidated listing of services.
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.
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
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
Web services 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:
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.
In SOA ecosystem Security, Governance, Operations, Quality are closely related. Each face of SOA ecosystem affects other.
Saturday, December 6, 2008
Book Review: SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects
Book Review: SOA Approach to Integration XML, Web services, ESB, and BPEL in real-world SOA projects by Matjaz, Ramesh, Pooranchandra and Frank (ISBN: 978-1-904811-17-6)
At first glance this would appear to be another "me too" title, and while in some ways that may be true. However there are a couple of things that set this book apart and it can be of value to those experienced in Integration & SOA as well as those new to the subjects.
Those who are new to the book I will recommend read as much as possible and this book must be one those. This book covers basic essentials of Integration, SOA, WebServices and BPEL in very simple and lucid language, which can help any greenhorn.
The most important part of this book is its language. The most glaring lapse in this book is assuming SOA means web services.
It has explained concepts of EAI in very concise & to the point in first chapter. While explaining Integration Infrastructure authors have drawn nice picture, which covers almost all aspects of integration tool stack. But in the section of Integration Technologies section, it fails to mention that MoM, TPM, ORB, App Server and ESB are various generations of the same and no word about “Several hybrid and proprietary products”.
The second chapter covers SOA in technology agnostic as well as Java &. Net specific way. This chapter nicely covers basic concepts of SOA, which include not only ESB but also web services and its Java and .Net implementation. This chapter also tries to cover process-based architecture in the end, which makes things little bit clumsy.
The third chapter covers XML, Schema, XML document security, and XML parsing. This chapter covers a lot but also leaves behind a lot. It totally neglects non Java XML parsers.
The forth chapter seems to be inspired from IBM’s eBusiness patterns. This chapter also touches Web Services Interoperability (WS –I) stuff, which is pretty elaborated.
The fifth chapter covers BPEL and integration with emphasis on process orientation. This chapter is good reference for BPEL and especially Oracle way of BPEL in its Fusion Middleware.
The last chapter covers ESB in detail. The name of the chapter and content of it does not match.
The most wanted but missing part in this book is references for each chapter in particular and for book in general.
In summary I would suggest that this is a good book for anyone involved in SOA and integration project. It will provide a good introduction for those new to the discipline of Integration and SOA. While acting as a useful refresher for those with more experience
go and grab the book at packtpub.com