Though Cloud gaining currency across the globe and across the industry. But if one carefully observe, he will find slow adoption of cloud in big enterprises. From a Software Architect perspective one should be aware of the legal challenges while evaluating cloud platforms for a solution.
1. Intellectual Property Rights
a. Is application and data protected under intellectual property rights?
b. If cloud provider gives access to your application, data, log etc to third party then what legal responsibility cloud provider assumes?
2. Trade Secrets
a. How secure are the trade secrets?
b. How far cloud provider can go to protect data, log, etc. in case of court summons and/or quasi legal requests/pressure?
c. How long cloud provider keeps application data and logs even after application is deleted from cloud and/or log deleted from cloud?
3. Privacy
a. What responsibility cloud provider assumes to protect Application Owner’s privacy?
b. What responsibility cloud provider assumes to protect Application users’ privacy?
c. Is there any liability coverage for privacy breach?
d. How behavioral tracking is maintained?
4. Data Centre
a. What legal responsibility does cloud provider assume in case of disaster?
b. What legal responsibility does cloud provider assume in case of hacking?
5. Jurisdiction
a. In case of any legal dispute which law apples – location of application provider, location of end user, location of cloud provider, location of server farm or any other?
b. In case of data breach who will send the notice of data breach – application provider or cloud provider?
c. How trans-border laws will be handled?
d. How do reputational risks covered?
e. How long data will be retained for legal and taxation purpose?
f. What is damage policy (say total dames are capped by amount of fee)?
g. Does the flow of data meet the regulatory requirements of each jurisdiction it flows through?
h. Does the cloud provider provides solutions for de-identifying data for transboarder data flow?
i. Where will the data and processes be stored? Can a commitment be obtained?
j. Are there multiple cloud platforms/parties involved?
k. Can the movement of data be controlled?
l. Should/can the data be encrypted?
6. Service Level Agreement
a. What are the SLA’s for cloud provider?
b. What matrices will be used to measure performance of cloud provider?
c. In case of dishonoring of SLA, what are the penalties and they will be enforced?
7. Licensing
a. Do libraries, components, services, servers, etc used in application creation, deployment, etc have cloud compatible licenses?
b. Do libraries, components, services, servers, etc used in application creation, deployment, etc licenses cover upgrade and maintenance as well?
c. How application’s license is structured for end users?
8. Physical Location of Data and processes
a. What is the location of data?
b. What is the location of processes?
c. Is any point of time, location of data and process be ascertained?
9. E-discovery
a. What are the evidentiary issues when client data is in cloud?
b. What are the SLA’s of e-discovery?
c. Who is responsible for e-discovery?
10. Termination
a. In case of contract termination, how data will be moved from cloud to in agreed upon format?
b. Who is responsible to move data?
c. If cloud provider goes out of business then how termination will be handled?
d. If application provider goes out of business then how termination will be handled – data, intellectual property.
e. Is there any lock in?
11. Change in Terms and conditions
a. How change in terms and conditions to be handled?
b. Does cloud provider change terms and condition by inserting URL?
12. Audit
a. Can application provider do audit of facilities and processes/procedures and how extensive are these audits?
b. Can application provider do audit of logs and how extensive are these audits?
13. Miscellaneous
a. What insurance cover cloud provider has?
b. In case of emergencies how data be accesses and who will be responsible?
c. Use of application provider’s name and logo for publicity by cloud provider?
d. Use of cloud provider’s name and logo for publicity by application provider?
e. How service renewal will be handled?
Showing posts with label Service Oriented Architecture. Show all posts
Showing posts with label Service Oriented Architecture. Show all posts
Tuesday, December 28, 2010
Thursday, October 8, 2009
EAI & SOA Development & Maintenance: Centralized or Distributed
Centralized Development & Maintenance
1. Knowledge is at one place, difficult to assemble but once accumulated easy to manage
2. EAI and SOA workforce needs exposure to respective systems under lens and specialized knowledge about EAI &/or SOA. In case of centralized development effort manpower can be channelized in effective way and team members develop cross application skills.
3. Better architectural control
4. Better design time security due to centralized policy enforcement.
5. It need more coordination on part of EAI/SOA team but reusability of services will offset that.
Distributed Development & Maintenance
1. Knowledge is distributed across islands of applications, so difficult to manage
2. Cross application skills are not developed but application specific specialists get developed with little exposure to EAI or/& SOA.
3. EAI Workforce may not be utilized if EAI/SOA work is not in sufficient quantity.
4. In distributed development environment, EAI/SOA may loose focus and deviate from Enterprise architecture which may:
a. Jeopardize BPM initiative at later stage;
b. Duplication of services/functionality
5. Increased cost of maintaining and establishing development environment
6. Governance issues may crop up, like ownership of services
7. Difficult to enforce security policies
1. Knowledge is at one place, difficult to assemble but once accumulated easy to manage
2. EAI and SOA workforce needs exposure to respective systems under lens and specialized knowledge about EAI &/or SOA. In case of centralized development effort manpower can be channelized in effective way and team members develop cross application skills.
3. Better architectural control
4. Better design time security due to centralized policy enforcement.
5. It need more coordination on part of EAI/SOA team but reusability of services will offset that.
Distributed Development & Maintenance
1. Knowledge is distributed across islands of applications, so difficult to manage
2. Cross application skills are not developed but application specific specialists get developed with little exposure to EAI or/& SOA.
3. EAI Workforce may not be utilized if EAI/SOA work is not in sufficient quantity.
4. In distributed development environment, EAI/SOA may loose focus and deviate from Enterprise architecture which may:
a. Jeopardize BPM initiative at later stage;
b. Duplication of services/functionality
5. Increased cost of maintaining and establishing development environment
6. Governance issues may crop up, like ownership of services
7. Difficult to enforce security policies
Friday, September 18, 2009
Services vs. Components
Services are mistaken as components. This post emphasizes the difference between services and components.
1. Components are the concrete form which realizes service.
2. Components can be reused in two ways:
a. Binary reuse
b. As distributed object
While service reuse is only through composition.
1. Components are the concrete form which realizes service.
2. Components can be reused in two ways:
a. Binary reuse
b. As distributed object
While service reuse is only through composition.
Thursday, September 17, 2009
Services vs. Distributed Objects
Even after fairly large implementations of web services and wide spread adoption of services, services still compared with distributed objects. This entry is dedicated to highlight differences between services and distributed objects.
1. Distributed objects are designed to operate in corporate intranet environment while services are for internet.
2. Distributed objects boasts object’s life cycle which can be summarized as:
a. Upon request, a factory instantiates the object;
b. The consumer who requested the instantiation performs operations on the object instance; and
c. Later, either the consumer releases the instance or the runtime system garbage-collects it.
A special case is the singleton object, which does not go through this cycle. In both the cases, the object is identified through a reference that can be passed between processes to provide a access mechanism for it. Objects often contain references to other objects, and distributed object technology comes with exhaustive reference-handling techniques to manage objects’ lifecycle.
Service does not feature object like lifecycle, factory, garbage collection, etc.
3. The flow of information among distributed objects is very closed and only understood by objects of same type (say RMI, DCOM, CORBA, etc). But in services information exchange is done using XML or some derivative of XML.
1. Distributed objects are designed to operate in corporate intranet environment while services are for internet.
2. Distributed objects boasts object’s life cycle which can be summarized as:
a. Upon request, a factory instantiates the object;
b. The consumer who requested the instantiation performs operations on the object instance; and
c. Later, either the consumer releases the instance or the runtime system garbage-collects it.
A special case is the singleton object, which does not go through this cycle. In both the cases, the object is identified through a reference that can be passed between processes to provide a access mechanism for it. Objects often contain references to other objects, and distributed object technology comes with exhaustive reference-handling techniques to manage objects’ lifecycle.
Service does not feature object like lifecycle, factory, garbage collection, etc.
3. The flow of information among distributed objects is very closed and only understood by objects of same type (say RMI, DCOM, CORBA, etc). But in services information exchange is done using XML or some derivative of XML.
Service vs. Process
The services in any SOA ecosystem must demonstrate following traits:
• Compose-ability
• Statelessness
• Context unawareness
• Discoverability over network
• Reusability
• Decoupling of service implementation and contract/interface
• Adherence to standards
The driver of SOA ecosystem is creating application with fast pace. This driver is achieved exploiting above mentioned traits. With maturity, process also exposed as services to realize bigger and complex processes. This usage forces exposed processes to loose statelessness, context unawareness with varying degree. Now the dilemma creeps in, is architecture deviating from basic tenants of service design.
• Compose-ability
• Statelessness
• Context unawareness
• Discoverability over network
• Reusability
• Decoupling of service implementation and contract/interface
• Adherence to standards
The driver of SOA ecosystem is creating application with fast pace. This driver is achieved exploiting above mentioned traits. With maturity, process also exposed as services to realize bigger and complex processes. This usage forces exposed processes to loose statelessness, context unawareness with varying degree. Now the dilemma creeps in, is architecture deviating from basic tenants of service design.
Wednesday, September 16, 2009
Service Design Principles
Service is a computational functionality exposed over network. So any computational resource which can expose its functionality over network can be treated as service. But do we need such type of services in SOA ecosystem. Definitely NOT. In SOA ecosystem, service must demonstrate some traits:
• Compose-ability
• Statelessness
• Context unawareness
• Discoverability over network
• Reusability
• Decoupling of service implementation and contract/interface
• Adherence to standards
To make sure that a service demonstrates outlined traits, following design principles must be followed while designing a service in any SOA ecosystem.
1. Standard Service Contract/Interface
2. Optimal Service Granularity
3. Service Re-usability
4. Stateless Service
5. Context Unaware Service
6. Compose-ability of Service
7. Service discover-ability
8. Service Autonomy
9. Service context abstraction
10. Externalization of non core aspects
11. Service versioning
12. Multi contract/interface availability
13. Idempotent Service
14. Coupling Management
1. Standard Service Contract/Interface: Service in a defined inventory must have standardized contract for availing the intended business functionality. Standardization keeps needs of data transformation minimal and also brings in predictability and increases comfort level of calling party.
2. Optimum Service Granularity: Service granularity is one of the joint decisions of Business and Technical teams with respect to service design. On the basis of granularity services can be classified as:
a. Atomic: Service which can enforce transaction related features to its exposed operations.
b. Molecular: Services which can not enforce transaction related features but can have compensatory features. This type of services is composition of underlying atomic and molecular services. Some time it is very difficult to differentiate between a molecular service and a process because process can also be exposed as service.
3. Service Re-usability: Service re-usability is one of the driving forces of SOA ecosystem. Service re-usability is function of granularity, contract/interface standardization, compose ability, context abstraction, idempotent nature, context unawareness and versioning. In SOA ecosystem, re-usability of service is big driver of molecular composite service.
4. Stateless Service: In a SOA ecosystem, services must be stateless whether atomic or molecular. Stateless of service facilitates compose-ability. But as service moves from pure service to process keeping statelessness become difficult but it is always desirable.
a. Current result of service execution must not be affect by any of previous result.
5. Context Unaware Service: Context unawareness of a service is contributing factor for statelessness. Context unawareness essentially about two main concepts:
a. Who is calling? (may be negated in serving versioning, testing/training mode)
b. Who is called me earlier? ( Make sure that service behavior must not change depending upon previous calling party)
6. Compose-ability of Service: for an SOA ecosystem, one of the important metric is number of services reused. This reuse of service may be of three types:
a. Consuming a service in an application
b. Consuming a service in process
c. Consuming a service in creation of another service
Last two type of service consumption is mainly result of compose-ability of a service.
While designing a service pay attention to following aspects:
a. Ability to compose other services
b. Ability of to be composed
c. How deep composition should be?
7. Service Discover-ability: In a SOA ecosystem, service are discovered in following manner:
Consumer discovers a provider at design time:
i. Developer/Designer refer some list manually
ii. IDE presents pre-listed ( with IDE or pre-configured Registry)
d. Consumer discovers a provider at run time:
i. Consumer discovers a provider while looking at repository where provider is listed. This process happens at first call to provider. Discovery process gets repeated if consumer lost the information about provider. Discovery process also happens if provider becomes unavailable.
ii. Consumer discovers provider with each call via trip to repository.
Each discovery scheme has its own pro and cons. Most of the time discover-ability of service is not only function of service interface/contract design but also infrastructure capability of SOA ecosystem.
8. Service Autonomy: For any atomic service, the implementation is in some component and some persistence layer to hold data. In spirit of component re-usability, one can reuse components in two or more services. This reuse of components can be of two types:
a. Different installations of same component ( different binaries) are utilized
b. Same installation of a component is used in two or more services
At persistence layer services can again utilize one or multiple instances of same data. While deciding what type of persistence layer is shared also raises difficult question of integration (EAI).
In Molecular services, services composed also constitute big role while deciding Service autonomy.
9. Service context abstraction: Service context abstraction idea is borrowed from encapsulation of object oriented world. In Bjarne Stroustrup's words - expose minimal but complete. On the lighter side “Exposed contract/interface is like Bikini. What does it reveal is sufficient to arouse, but what it conceals is vital”. The service contract/interface should consider exposing following aspects:
a. Functional aspects
b. Technical aspects
c. Non Functional and non technical ( abilities) aspects
10. Externalization of non core aspects: In any good software design non core aspects of that software must be externalize to keep focus on business logic and keeping the code simple. The concept of externalization can also be understood from Aspect Oriented Programming perspective.
If we move into conventional software design, following considerations must be in mind:
a. Configuration parameters ( generally technical attributes)
b. Rules ( generally business rules/attributes)
c. Hot deploy-able vs. non hot deploy-able
d. Design time vs. run-time change in attributes.
11. Service versioning: Service must be able to support versioning to cater its evolution. The versioning support for a service level can be handled at platform level or at service level or at deployment level. All schemes of versioning support have their own pros and cons.
While catering for service versioning need, pay attention to:
a. Context unawareness of service
b. Multi version contract/interface
c. Multi version deployment of service
12. Multi contract/interface availability: In some cases, especially when SHE (Service Hosting) is not used, service is made available at multiple channels. If this is the need then pays attention to availability of multi channel interface/contract.
13. Idempotent Service: If service to be called by same consumer, its response must not be affected in any way. This is one of the important design aspect while realizing context unawareness and statelessness.
14. Coupling Management: In any software system one of the important goals is reduced coupling. But in real life coupling can not reach to zero it can be minimized or transferred from one face to another. In SOA ecosystem, coupling with respect to service can be understood as:
a. Semantic coupling: Coupling between consumer and producer with respect to data structure passed while service is called for consumption.
b. Ontological coupling: Coupling between consumer and producer with respect to nomenclature of service operation/method/function.
c. Temporal Coupling: Coupling between consumer and producer with respect to time and calling sequence.
d. Spatial Coupling: Coupling between consumer and producer with respect to address and addressing scheme
e. Stamp Coupling: Where two services modify common data.
• Compose-ability
• Statelessness
• Context unawareness
• Discoverability over network
• Reusability
• Decoupling of service implementation and contract/interface
• Adherence to standards
To make sure that a service demonstrates outlined traits, following design principles must be followed while designing a service in any SOA ecosystem.
1. Standard Service Contract/Interface
2. Optimal Service Granularity
3. Service Re-usability
4. Stateless Service
5. Context Unaware Service
6. Compose-ability of Service
7. Service discover-ability
8. Service Autonomy
9. Service context abstraction
10. Externalization of non core aspects
11. Service versioning
12. Multi contract/interface availability
13. Idempotent Service
14. Coupling Management
1. Standard Service Contract/Interface: Service in a defined inventory must have standardized contract for availing the intended business functionality. Standardization keeps needs of data transformation minimal and also brings in predictability and increases comfort level of calling party.
2. Optimum Service Granularity: Service granularity is one of the joint decisions of Business and Technical teams with respect to service design. On the basis of granularity services can be classified as:
a. Atomic: Service which can enforce transaction related features to its exposed operations.
b. Molecular: Services which can not enforce transaction related features but can have compensatory features. This type of services is composition of underlying atomic and molecular services. Some time it is very difficult to differentiate between a molecular service and a process because process can also be exposed as service.
3. Service Re-usability: Service re-usability is one of the driving forces of SOA ecosystem. Service re-usability is function of granularity, contract/interface standardization, compose ability, context abstraction, idempotent nature, context unawareness and versioning. In SOA ecosystem, re-usability of service is big driver of molecular composite service.
4. Stateless Service: In a SOA ecosystem, services must be stateless whether atomic or molecular. Stateless of service facilitates compose-ability. But as service moves from pure service to process keeping statelessness become difficult but it is always desirable.
a. Current result of service execution must not be affect by any of previous result.
5. Context Unaware Service: Context unawareness of a service is contributing factor for statelessness. Context unawareness essentially about two main concepts:
a. Who is calling? (may be negated in serving versioning, testing/training mode)
b. Who is called me earlier? ( Make sure that service behavior must not change depending upon previous calling party)
6. Compose-ability of Service: for an SOA ecosystem, one of the important metric is number of services reused. This reuse of service may be of three types:
a. Consuming a service in an application
b. Consuming a service in process
c. Consuming a service in creation of another service
Last two type of service consumption is mainly result of compose-ability of a service.
While designing a service pay attention to following aspects:
a. Ability to compose other services
b. Ability of to be composed
c. How deep composition should be?
7. Service Discover-ability: In a SOA ecosystem, service are discovered in following manner:
Consumer discovers a provider at design time:
i. Developer/Designer refer some list manually
ii. IDE presents pre-listed ( with IDE or pre-configured Registry)
d. Consumer discovers a provider at run time:
i. Consumer discovers a provider while looking at repository where provider is listed. This process happens at first call to provider. Discovery process gets repeated if consumer lost the information about provider. Discovery process also happens if provider becomes unavailable.
ii. Consumer discovers provider with each call via trip to repository.
Each discovery scheme has its own pro and cons. Most of the time discover-ability of service is not only function of service interface/contract design but also infrastructure capability of SOA ecosystem.
8. Service Autonomy: For any atomic service, the implementation is in some component and some persistence layer to hold data. In spirit of component re-usability, one can reuse components in two or more services. This reuse of components can be of two types:
a. Different installations of same component ( different binaries) are utilized
b. Same installation of a component is used in two or more services
At persistence layer services can again utilize one or multiple instances of same data. While deciding what type of persistence layer is shared also raises difficult question of integration (EAI).
In Molecular services, services composed also constitute big role while deciding Service autonomy.
9. Service context abstraction: Service context abstraction idea is borrowed from encapsulation of object oriented world. In Bjarne Stroustrup's words - expose minimal but complete. On the lighter side “Exposed contract/interface is like Bikini. What does it reveal is sufficient to arouse, but what it conceals is vital”. The service contract/interface should consider exposing following aspects:
a. Functional aspects
b. Technical aspects
c. Non Functional and non technical ( abilities) aspects
10. Externalization of non core aspects: In any good software design non core aspects of that software must be externalize to keep focus on business logic and keeping the code simple. The concept of externalization can also be understood from Aspect Oriented Programming perspective.
If we move into conventional software design, following considerations must be in mind:
a. Configuration parameters ( generally technical attributes)
b. Rules ( generally business rules/attributes)
c. Hot deploy-able vs. non hot deploy-able
d. Design time vs. run-time change in attributes.
11. Service versioning: Service must be able to support versioning to cater its evolution. The versioning support for a service level can be handled at platform level or at service level or at deployment level. All schemes of versioning support have their own pros and cons.
While catering for service versioning need, pay attention to:
a. Context unawareness of service
b. Multi version contract/interface
c. Multi version deployment of service
12. Multi contract/interface availability: In some cases, especially when SHE (Service Hosting) is not used, service is made available at multiple channels. If this is the need then pays attention to availability of multi channel interface/contract.
13. Idempotent Service: If service to be called by same consumer, its response must not be affected in any way. This is one of the important design aspect while realizing context unawareness and statelessness.
14. Coupling Management: In any software system one of the important goals is reduced coupling. But in real life coupling can not reach to zero it can be minimized or transferred from one face to another. In SOA ecosystem, coupling with respect to service can be understood as:
a. Semantic coupling: Coupling between consumer and producer with respect to data structure passed while service is called for consumption.
b. Ontological coupling: Coupling between consumer and producer with respect to nomenclature of service operation/method/function.
c. Temporal Coupling: Coupling between consumer and producer with respect to time and calling sequence.
d. Spatial Coupling: Coupling between consumer and producer with respect to address and addressing scheme
e. Stamp Coupling: Where two services modify common data.
Saturday, September 12, 2009
Friday, September 11, 2009
Thursday, September 10, 2009
Friday, September 4, 2009
Services Elements
In any enterprise class SOA implementation, services form back bone. To understand SOA, back bone has to be understood in comprehensive manner. To simplify the understanding of SOA, I have tried classifying elements of services in Business and Technical categories.
Thursday, September 3, 2009
SOA Deployment Challenges
The challenges of deploying SOA can be categorized as: technical and operational.
Major technical challenges are:
• Debugging and tracing
• Efficient caching of requests and sessions
• Security, monitoring and notification
• Compliance with multiple computing standards
• Support for internal and external clients with different needs
• Quality of service and management of service-level agreements
• Availability and scalability
• Decomposition of existing applications and migration of legacy services
Major operational challenges are:
• Version control
• Learning curve for deployers
• Effects on existing operational tools and environments
• Pressures for timely releases
• Governance, especially in the face of constant changes
• Consistency in development, test and prod environments
Resolving the challenges is an ongoing battle. These challenges can be faced with the help of following:
• Lightweight, composite, layered and high-performance SOA platform
• A unified testing framework
• Decomposition of model-driven services
• An extensive authentication and authorization process for security ( such as eXtensible Access Control Markup Language (XACML)-based)
• A strong yet flexible governance process through a service registry and repository
• Business rules are in Rule engine
• Robust forensic (monitoring, audit, logging and notification) framework
• Change management for dependencies and backward compatibility
Major technical challenges are:
• Debugging and tracing
• Efficient caching of requests and sessions
• Security, monitoring and notification
• Compliance with multiple computing standards
• Support for internal and external clients with different needs
• Quality of service and management of service-level agreements
• Availability and scalability
• Decomposition of existing applications and migration of legacy services
Major operational challenges are:
• Version control
• Learning curve for deployers
• Effects on existing operational tools and environments
• Pressures for timely releases
• Governance, especially in the face of constant changes
• Consistency in development, test and prod environments
Resolving the challenges is an ongoing battle. These challenges can be faced with the help of following:
• Lightweight, composite, layered and high-performance SOA platform
• A unified testing framework
• Decomposition of model-driven services
• An extensive authentication and authorization process for security ( such as eXtensible Access Control Markup Language (XACML)-based)
• A strong yet flexible governance process through a service registry and repository
• Business rules are in Rule engine
• Robust forensic (monitoring, audit, logging and notification) framework
• Change management for dependencies and backward compatibility
Saturday, June 27, 2009
One measure for a Service
Customer view the interface part of service. But from architecture and design perspective apart from interface quality of code is very important. Keeping in mind this picture I have developed one measure:
Quality of Code (in percentage) =100* (Volume of code implementing business logic of service)/ (total volume of code for service)
Here the basic question arises how to measure volume of code. The traditional approach is LoC. But in OO world this is one of the biggest problems.
The measure, Quality of Code is not measure of Quality of service but one of the several measure which gives indication on frameworks used to realize a service. In ideal case the peripheral code to create a service should come from the framework/platform.
Quality of Code (in percentage) =100* (Volume of code implementing business logic of service)/ (total volume of code for service)
Here the basic question arises how to measure volume of code. The traditional approach is LoC. But in OO world this is one of the biggest problems.
The measure, Quality of Code is not measure of Quality of service but one of the several measure which gives indication on frameworks used to realize a service. In ideal case the peripheral code to create a service should come from the framework/platform.
Saturday, May 16, 2009
SOA Pattern - Division of Labour
This first of SOA patterns I like to share.
This Pattern is have named as Division of Labour which essentially states that a service should do what it supposed to do.
Pattern - Division of Labour - V 1.0 Dated May 16 2009
This Pattern is have named as Division of Labour which essentially states that a service should do what it supposed to do.
Pattern - Division of Labour - V 1.0 Dated May 16 2009
Wednesday, May 6, 2009
Random Thoughts about SOA: Part 1
1. Attribute of Successful SOA implementation
2. Design Operators of “Modular” SOA
3. Lean SOATM
- Rate of increase in Technological Complexity should be less than rate of increase in Business Complexity
- Continual siloed Changes
- Conservation of familiarity for technical and business persons
- Feedback based continuous learning and un-learning
- Trap business and technical event and then take action
- Be disruptive as whole but not in incremental fashion.
- Adhere to Standards for benefits not for sake of adherence
2. Design Operators of “Modular” SOA
- Splitting: Services can be made independent
- Substituting: Services can be substitutes and interchanges
- Excluding: Existing services can be removed to build a usable solution
- Augmenting: New Services can be added to create new Composite services and/or processes
- Inverting: Hierarchical and composition dependencies among services can be rearranged ( most difficult)
- Porting: Called Service is independent of calling service.
3. Lean SOATM
- Eliminate Waste: Spend time and resources only what add real customer value
- Amplify Leaning: Tougher the problem, increasing the feedback
- Decide as Late as Possible: Keep options open as long as practical (not possible)
- Fail early, fail frequent: Use increment development & deployment
- Deliver as fast as possible: Deliver value to customer as soon as customer asks
- Empower the team: People are intelligent, encourage them to contribute
- Build Integrity: Most of the time, shortest route is not the best route
- See the Whole: Beware of the temptation to optimize parts at the expense of whole.
Friday, April 24, 2009
Provisioning - Follow up
Sunny Agarwal: no thanks boss.. I would like to have a discussion
tushar Jain: sure
tushar Jain: any time
Sunny Agarwal: in fact, just wrote the comment
Sunny Agarwal: but, forgot to ask one thing
tushar Jain: which
Sunny Agarwal: in which scope r u trying to explore provisioning
Sunny Agarwal: provisioning is a generic term.
tushar Jain: agree provisioning is generic terms
tushar Jain: but in SOA parlance we always talk provisioning of services
tushar Jain: but most of people do not understand meaning of this term
tushar Jain: and most of the information available on net talks provisioning in terms of Telecommunication
tushar Jain: and little bit of identity management
tushar Jain: Even Tivoli provisioning manager does not explain what is provisioning
Sunny Agarwal: u said u r writing in context of Telcos
Sunny Agarwal: if u wishes to explore provisioning in a larger scope then may be i can give u some points
tushar Jain: sure
Sunny Agarwal: Cloud computing and utility computing r emerging areas
Sunny Agarwal: where these provisioning concepts will come
tushar Jain: I love to know
Sunny Agarwal: Ok, so there are 3 pillars:
Sunny Agarwal: 1. Grid Computing
Sunny Agarwal: 2. Utility Computing
Sunny Agarwal: 3. Cloud Computing
Sunny Agarwal: where service provider is agnostic to service requester
Sunny Agarwal: typical SOA arena
tushar Jain: ok
Sunny Agarwal: but at the same, time we need light governance in order to facilitate transactions
tushar Jain: ok
tushar Jain: so here u have to provision a service for an entity
Sunny Agarwal: one interesting area is scalable provisioning
Sunny Agarwal: where u scale up systems dynamically
tushar Jain: what is that
Sunny Agarwal: to provide dynamic service levels
Sunny Agarwal: here virtual systems and virtualized hardware systems also come in picture
Sunny Agarwal: again, I am just talking to u... what I have read across and seen...
Sunny Agarwal: trying to know, how u want to move ahead on this topic now
Sunny Agarwal: u wants to lay out a framework for delivery, solution, or a business process...
Sunny Agarwal: or an Infrastructure setup
tushar Jain: wait
tushar Jain: I see provisioning as subset of SOA because Cloud, Utility and Grid and SOA at different level and extension of SOA
tushar Jain: the essential feature of all these three pillars is service
tushar Jain: so service should be provisioned in respective environment
tushar Jain: which need some sort of provisioning engine
Sunny Agarwal: ok
Sunny Agarwal: so would it be something like a BPM engine, where this engine would maintain identity or service instance details
tushar Jain: I see provisioning engine will be an be an essential part of SOA stack just like ESB and UDDI
Sunny Agarwal: ok, then how does u differentiate Service Registry products from provisioning
Sunny Agarwal: engine
Sunny Agarwal: something like Active Matrix Service grid
Sunny Agarwal: which provides all this?
tushar Jain: I see service registry as mere listing of available service which may also indicate QoS. But not essentially as tool which can make service available to an entity - human & m/c.
tushar Jain: This thought encompasses identity management systems into provisioning system
tushar Jain: provisioning engine and registry in conjunction will lay down the governance system.
Sunny Agarwal: hmm.. Seems I need to read on this then. Identity management is a new word to me
tushar Jain: sure
Sunny Agarwal: so, this Provisioning system will come in between any service requester and service grid
Sunny Agarwal: as a receptionist
tushar Jain: perfect
Sunny Agarwal: and yet, I have a flexibility to call the office boy or grid directly
tushar Jain: once you are introduced to office boy
Sunny Agarwal: yeah.. So that would be something like
Sunny Agarwal: one enterprise service grid
Sunny Agarwal: internal business domains can call office boy directly
Sunny Agarwal: and external entities who wish to use these services better come thru receptionist
Sunny Agarwal: hmmmm..... Here we can have a relation of telco's..... N/W bulk providers and Virtual Service providers...
tushar Jain: it should be true but trusted partners can call office boy directly, if system is desined in this way to enhance performance and reduce overhead
Sunny Agarwal: yep
Sunny Agarwal: so , what r the business drivers for this concept
tushar Jain: Ant just be clear, I have tried to define provisioning g in dependent of domain - Telco or ISP
Sunny Agarwal: like for SOA, main driver is reuse
Sunny Agarwal: and inter opp
Sunny Agarwal: what is for provisioning?
tushar Jain: I have used mention of these domain to just start the conversation
Sunny Agarwal: yeah... i got that... and it’s new to me too... something broader
tushar Jain: main driver is governance
Sunny Agarwal: broader
Sunny Agarwal: I will talk abt it with my mentors in wipro also
tushar Jain: sure any time
tushar Jain: and I am available on mail and messenger
Sunny Agarwal: hmm...interesting
Sunny Agarwal: i hope u r on my linked in
Sunny Agarwal: and ur blog is there now..
tushar Jain: my bog is there in my profile
tushar Jain: and I have started a group on linkedin
Sunny Agarwal: gr8 gr8
tushar Jain: Now I need a favor
Sunny Agarwal: bolo sir
tushar Jain: can I publish this conversation as blog entry
tushar Jain: if you permit
Sunny Agarwal: why not.
Sunny Agarwal: would only make me feel better.
tushar Jain: thanks
Sunny Agarwal: my objective is to have authentic info and understanding
tushar Jain: me too
Sunny Agarwal: and especially in SOA world, it’s very deceptive
Sunny Agarwal: terms r so misused
Sunny Agarwal: OK, Tell me where does provisioning fits in OSS /BSS solutions
Sunny Agarwal: at what level
tushar Jain: ok, first you tell me what do u understand by BSS and OSS
Sunny Agarwal: well, OSS is operational support system and BSS is business support systems..
Sunny Agarwal: if u forgets about backend n/w infra
Sunny Agarwal: u r left with services and products plus all management around it
Sunny Agarwal: BSS would be more centric to business systems...
tushar Jain: ok
Sunny Agarwal: and OSS for operational.. Following the basic FAB stack
Sunny Agarwal: levels would be customer / internal / backend n/w
Sunny Agarwal: yes, there is a point.
tushar Jain: what
Sunny Agarwal: if u looking at unified OSS solution, then not much integration and services....
Sunny Agarwal: if u follow best of breed COTS prods and then integrate them for OSS
Sunny Agarwal: then SOA would also come in
Sunny Agarwal: ab u punch in
tushar Jain: so what BSS and OSS are doing
Sunny Agarwal: nothing...
tushar Jain: with integrated approach or as compartments
tushar Jain: they are just offering services
Sunny Agarwal: that’s it
tushar Jain: Suuny I have to go in meeting
tushar Jain: we will again chat on Monday
tushar Jain: sure
tushar Jain: any time
Sunny Agarwal: in fact, just wrote the comment
Sunny Agarwal: but, forgot to ask one thing
tushar Jain: which
Sunny Agarwal: in which scope r u trying to explore provisioning
Sunny Agarwal: provisioning is a generic term.
tushar Jain: agree provisioning is generic terms
tushar Jain: but in SOA parlance we always talk provisioning of services
tushar Jain: but most of people do not understand meaning of this term
tushar Jain: and most of the information available on net talks provisioning in terms of Telecommunication
tushar Jain: and little bit of identity management
tushar Jain: Even Tivoli provisioning manager does not explain what is provisioning
Sunny Agarwal: u said u r writing in context of Telcos
Sunny Agarwal: if u wishes to explore provisioning in a larger scope then may be i can give u some points
tushar Jain: sure
Sunny Agarwal: Cloud computing and utility computing r emerging areas
Sunny Agarwal: where these provisioning concepts will come
tushar Jain: I love to know
Sunny Agarwal: Ok, so there are 3 pillars:
Sunny Agarwal: 1. Grid Computing
Sunny Agarwal: 2. Utility Computing
Sunny Agarwal: 3. Cloud Computing
Sunny Agarwal: where service provider is agnostic to service requester
Sunny Agarwal: typical SOA arena
tushar Jain: ok
Sunny Agarwal: but at the same, time we need light governance in order to facilitate transactions
tushar Jain: ok
tushar Jain: so here u have to provision a service for an entity
Sunny Agarwal: one interesting area is scalable provisioning
Sunny Agarwal: where u scale up systems dynamically
tushar Jain: what is that
Sunny Agarwal: to provide dynamic service levels
Sunny Agarwal: here virtual systems and virtualized hardware systems also come in picture
Sunny Agarwal: again, I am just talking to u... what I have read across and seen...
Sunny Agarwal: trying to know, how u want to move ahead on this topic now
Sunny Agarwal: u wants to lay out a framework for delivery, solution, or a business process...
Sunny Agarwal: or an Infrastructure setup
tushar Jain: wait
tushar Jain: I see provisioning as subset of SOA because Cloud, Utility and Grid and SOA at different level and extension of SOA
tushar Jain: the essential feature of all these three pillars is service
tushar Jain: so service should be provisioned in respective environment
tushar Jain: which need some sort of provisioning engine
Sunny Agarwal: ok
Sunny Agarwal: so would it be something like a BPM engine, where this engine would maintain identity or service instance details
tushar Jain: I see provisioning engine will be an be an essential part of SOA stack just like ESB and UDDI
Sunny Agarwal: ok, then how does u differentiate Service Registry products from provisioning
Sunny Agarwal: engine
Sunny Agarwal: something like Active Matrix Service grid
Sunny Agarwal: which provides all this?
tushar Jain: I see service registry as mere listing of available service which may also indicate QoS. But not essentially as tool which can make service available to an entity - human & m/c.
tushar Jain: This thought encompasses identity management systems into provisioning system
tushar Jain: provisioning engine and registry in conjunction will lay down the governance system.
Sunny Agarwal: hmm.. Seems I need to read on this then. Identity management is a new word to me
tushar Jain: sure
Sunny Agarwal: so, this Provisioning system will come in between any service requester and service grid
Sunny Agarwal: as a receptionist
tushar Jain: perfect
Sunny Agarwal: and yet, I have a flexibility to call the office boy or grid directly
tushar Jain: once you are introduced to office boy
Sunny Agarwal: yeah.. So that would be something like
Sunny Agarwal: one enterprise service grid
Sunny Agarwal: internal business domains can call office boy directly
Sunny Agarwal: and external entities who wish to use these services better come thru receptionist
Sunny Agarwal: hmmmm..... Here we can have a relation of telco's..... N/W bulk providers and Virtual Service providers...
tushar Jain: it should be true but trusted partners can call office boy directly, if system is desined in this way to enhance performance and reduce overhead
Sunny Agarwal: yep
Sunny Agarwal: so , what r the business drivers for this concept
tushar Jain: Ant just be clear, I have tried to define provisioning g in dependent of domain - Telco or ISP
Sunny Agarwal: like for SOA, main driver is reuse
Sunny Agarwal: and inter opp
Sunny Agarwal: what is for provisioning?
tushar Jain: I have used mention of these domain to just start the conversation
Sunny Agarwal: yeah... i got that... and it’s new to me too... something broader
tushar Jain: main driver is governance
Sunny Agarwal: broader
Sunny Agarwal: I will talk abt it with my mentors in wipro also
tushar Jain: sure any time
tushar Jain: and I am available on mail and messenger
Sunny Agarwal: hmm...interesting
Sunny Agarwal: i hope u r on my linked in
Sunny Agarwal: and ur blog is there now..
tushar Jain: my bog is there in my profile
tushar Jain: and I have started a group on linkedin
Sunny Agarwal: gr8 gr8
tushar Jain: Now I need a favor
Sunny Agarwal: bolo sir
tushar Jain: can I publish this conversation as blog entry
tushar Jain: if you permit
Sunny Agarwal: why not.
Sunny Agarwal: would only make me feel better.
tushar Jain: thanks
Sunny Agarwal: my objective is to have authentic info and understanding
tushar Jain: me too
Sunny Agarwal: and especially in SOA world, it’s very deceptive
Sunny Agarwal: terms r so misused
Sunny Agarwal: OK, Tell me where does provisioning fits in OSS /BSS solutions
Sunny Agarwal: at what level
tushar Jain: ok, first you tell me what do u understand by BSS and OSS
Sunny Agarwal: well, OSS is operational support system and BSS is business support systems..
Sunny Agarwal: if u forgets about backend n/w infra
Sunny Agarwal: u r left with services and products plus all management around it
Sunny Agarwal: BSS would be more centric to business systems...
tushar Jain: ok
Sunny Agarwal: and OSS for operational.. Following the basic FAB stack
Sunny Agarwal: levels would be customer / internal / backend n/w
Sunny Agarwal: yes, there is a point.
tushar Jain: what
Sunny Agarwal: if u looking at unified OSS solution, then not much integration and services....
Sunny Agarwal: if u follow best of breed COTS prods and then integrate them for OSS
Sunny Agarwal: then SOA would also come in
Sunny Agarwal: ab u punch in
tushar Jain: so what BSS and OSS are doing
Sunny Agarwal: nothing...
tushar Jain: with integrated approach or as compartments
tushar Jain: they are just offering services
Sunny Agarwal: that’s it
tushar Jain: Suuny I have to go in meeting
tushar Jain: we will again chat on Monday
Saturday, March 28, 2009
Is SOA Dead! Nope.
Year 2009 started with bang, SOA is Dead; Long Live Services by Anne Thomas Manes. In her blog and subsequent interview in IT Business Edge she emphasized that SOA is dead in business parlance due to it is failed to deliver its promises of aligning IT with business in real time. She advises not to use SOA word while asking for funding in today’s recessionary economy.
But I have simple question, do we as analysts, architects (not as business person) have analyzed why this phenomena is happening. I don’t think so.
When I read her blog entry in starting of year, I thought of protesting. But, then I though of analyzing the whole story wearing multiple hats – IT Service Company, Tool/Platform Provider, Business Person, Analyst and finally as Architect. Nearly a quarter long conscious analysis, has given me few insights:
1. Most of the SOA initiatives started as integration project where services were used as integration medium in stead of MOM. To maximize reach (in terms of market capture and revenue) Tool/Platform Providers and IT Service Companies have added fuel to fire.
2. Most of the established Tool/Platform Providers saw SOA as new business opportunity, so re-branded their Integration Tools/Platforms as SOA one.
3. To maximize their revenue Tool/Platform Provider created grandiose Tools/Platforms which have resulted bleeding IT departments.
4. As usual, Analysts are folks who can offer criticism on every thing. So they provided argument on both sides. They provided criticism on Tools/Platforms, Methodologies and frameworks but sadly, never on SOA independent of vendors.
5. Architects are greatly influenced by Tools/Platforms to which they were conversant. That’s why we see Java Architect, WebLogic Architect, WebSphere Architect, .Net Architect etc in Architects’ resume and at monster.
6. Business persons wanted quick return on their investment (essentially, they want their investment should be like expense) due to business compulsion which prevented them justifying long term investment.
7. Nobody paid any attention to business process restructuring and operation restructuring which are essential foundations of successful SOA.
So, SOA is dead or just acronym SOA has become dirty. Certainly SOA is not dead but we have to work for its acceptance with business people. Business persons sanction budget not IT ones. Whether, acronym SOA remain in vogue or not, it does not matter. So, the core question is how to keep alive SOA and not only alive but healthy and thriving.
1. Understand SOA philosophy (SOA stands for Service Oriented Architecture) independent of Tool/Platform Providers offerings.
2. Technical folks have to understand business realities. Due to present economic conditions business wants quick returns. So, it is time of tiny SOA (not even small), which should fit into grandiose Enterprise Architecture. This world in not perfect.
3. Businesspersons also have to understand that there is no silver bullet; Architecture requires time, money and humans.
4. If acronym SOA has become dirty, change it or clean it. I leave this choice to analysts; it is their job to invent new acronyms.
Underlying fact is, SOA is not dead and will not be dead but morphing itself as Web 2.0/3.0, SaaS, PaaS, BPM, EPM, Cloud computing, etc (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/03/service-orientation.html).
Further reading:
1. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
2. http://blog.dhananjaynene.com/2009/01/soa-aint-dead-but-it-certainly-is-transforming/
3. http://blogs.progress.com/soa_infrastructure/2009/01/goodbye-soa-we-hardly-knew-you.html
4. http://technoracle.blogspot.com/2009/01/soa-is-not-dead-but-complexity-is.html
5. http://www.andrejkoelewijn.com/wp/2009/01/06/soa-is-not-dead-were-still-in-the-early-adaptor-fase/
6. http://blog.dhananjaynene.com/2009/01/stop-making-soa-complex/
7. http://rasmussenreport.wordpress.com/2009/02/16/the-death-of-soa-maybe-later/
8. http://soa-today.blogspot.com/2009/02/big-soa-is-dead-little-soa-is-thriving.html
9. http://samisa-abeysinghe.blogspot.com/2009/02/soa-is-dead.html
10. http://broadcast.oreilly.com/2009/01/soa-is-dead-its-about-time.html
11. http://tardate.blogspot.com/2009/02/soa-is-dead-was-it-ever-alive.html
12. http://www.theenterprisearchitect.eu/archive/2009/01/26/soa-is-dead-long-live-model-driven-soa
13. http://www.glaucoreis.com.br/is_soa_dead_i.html
14. http://www.arisblog.com/2009/01/07/technical-soa-is-dead/
15. http://drjbutler.wordpress.com/2009/01/06/soa-in-good-eternal-company/
16. http://havemacwillblog.com/2009/01/13/the-people-who-think-soa-is-dead-are-dead/
17. http://blogs.progress.com/soa_infrastructure/2009/01/soa-wanted-dead-or-alive.html
18. http://www.itbusinessedge.com/cm/blogs/byron/even-if-soa-is-dead-sca-and-sdo-alive-and-well/?cs=30222
19. http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-soa-should-be-dead-to-the-business-but-alive-and-well-in-it/?cs=30407
20. http://www.ecommercetimes.com/rsstory/66104.html?wlc=1237532051
21. http://www.thinkovation.com/blog/index.php/2009/01/14/soa-dude-its-alive-and-kicking/
22. http://jshurwitz.wordpress.com/2009/02/09/yes-virginia-there-is-a-soa/
23. http://www.eweek.com/c/a/Web-Services-Web-20-and-SOA/SOA-Wanted-Dead-or-Alive/
But I have simple question, do we as analysts, architects (not as business person) have analyzed why this phenomena is happening. I don’t think so.
When I read her blog entry in starting of year, I thought of protesting. But, then I though of analyzing the whole story wearing multiple hats – IT Service Company, Tool/Platform Provider, Business Person, Analyst and finally as Architect. Nearly a quarter long conscious analysis, has given me few insights:
1. Most of the SOA initiatives started as integration project where services were used as integration medium in stead of MOM. To maximize reach (in terms of market capture and revenue) Tool/Platform Providers and IT Service Companies have added fuel to fire.
2. Most of the established Tool/Platform Providers saw SOA as new business opportunity, so re-branded their Integration Tools/Platforms as SOA one.
3. To maximize their revenue Tool/Platform Provider created grandiose Tools/Platforms which have resulted bleeding IT departments.
4. As usual, Analysts are folks who can offer criticism on every thing. So they provided argument on both sides. They provided criticism on Tools/Platforms, Methodologies and frameworks but sadly, never on SOA independent of vendors.
5. Architects are greatly influenced by Tools/Platforms to which they were conversant. That’s why we see Java Architect, WebLogic Architect, WebSphere Architect, .Net Architect etc in Architects’ resume and at monster.
6. Business persons wanted quick return on their investment (essentially, they want their investment should be like expense) due to business compulsion which prevented them justifying long term investment.
7. Nobody paid any attention to business process restructuring and operation restructuring which are essential foundations of successful SOA.
So, SOA is dead or just acronym SOA has become dirty. Certainly SOA is not dead but we have to work for its acceptance with business people. Business persons sanction budget not IT ones. Whether, acronym SOA remain in vogue or not, it does not matter. So, the core question is how to keep alive SOA and not only alive but healthy and thriving.
1. Understand SOA philosophy (SOA stands for Service Oriented Architecture) independent of Tool/Platform Providers offerings.
2. Technical folks have to understand business realities. Due to present economic conditions business wants quick returns. So, it is time of tiny SOA (not even small), which should fit into grandiose Enterprise Architecture. This world in not perfect.
3. Businesspersons also have to understand that there is no silver bullet; Architecture requires time, money and humans.
4. If acronym SOA has become dirty, change it or clean it. I leave this choice to analysts; it is their job to invent new acronyms.
Underlying fact is, SOA is not dead and will not be dead but morphing itself as Web 2.0/3.0, SaaS, PaaS, BPM, EPM, Cloud computing, etc (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/03/service-orientation.html).
Further reading:
1. http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html
2. http://blog.dhananjaynene.com/2009/01/soa-aint-dead-but-it-certainly-is-transforming/
3. http://blogs.progress.com/soa_infrastructure/2009/01/goodbye-soa-we-hardly-knew-you.html
4. http://technoracle.blogspot.com/2009/01/soa-is-not-dead-but-complexity-is.html
5. http://www.andrejkoelewijn.com/wp/2009/01/06/soa-is-not-dead-were-still-in-the-early-adaptor-fase/
6. http://blog.dhananjaynene.com/2009/01/stop-making-soa-complex/
7. http://rasmussenreport.wordpress.com/2009/02/16/the-death-of-soa-maybe-later/
8. http://soa-today.blogspot.com/2009/02/big-soa-is-dead-little-soa-is-thriving.html
9. http://samisa-abeysinghe.blogspot.com/2009/02/soa-is-dead.html
10. http://broadcast.oreilly.com/2009/01/soa-is-dead-its-about-time.html
11. http://tardate.blogspot.com/2009/02/soa-is-dead-was-it-ever-alive.html
12. http://www.theenterprisearchitect.eu/archive/2009/01/26/soa-is-dead-long-live-model-driven-soa
13. http://www.glaucoreis.com.br/is_soa_dead_i.html
14. http://www.arisblog.com/2009/01/07/technical-soa-is-dead/
15. http://drjbutler.wordpress.com/2009/01/06/soa-in-good-eternal-company/
16. http://havemacwillblog.com/2009/01/13/the-people-who-think-soa-is-dead-are-dead/
17. http://blogs.progress.com/soa_infrastructure/2009/01/soa-wanted-dead-or-alive.html
18. http://www.itbusinessedge.com/cm/blogs/byron/even-if-soa-is-dead-sca-and-sdo-alive-and-well/?cs=30222
19. http://www.itbusinessedge.com/cm/community/features/interviews/blog/why-soa-should-be-dead-to-the-business-but-alive-and-well-in-it/?cs=30407
20. http://www.ecommercetimes.com/rsstory/66104.html?wlc=1237532051
21. http://www.thinkovation.com/blog/index.php/2009/01/14/soa-dude-its-alive-and-kicking/
22. http://jshurwitz.wordpress.com/2009/02/09/yes-virginia-there-is-a-soa/
23. http://www.eweek.com/c/a/Web-Services-Web-20-and-SOA/SOA-Wanted-Dead-or-Alive/
Services Orchestration Design Principles & Best Practices
In real life SOA implementation services collaborate and executes in a particular fashion to perform a process. Process implementation uses Orchestration and Choreography of services. In this blog entry, I would like to focus on services orchestration.
From my experience on Oracle Fusion, TIBCO, Aqualogic and WebMethods I have collected some Services Orchestration Design Principle & Best Practices. I am listing those, independent of Tools/Platforms:
1. Keep Orchestration depth to manageable limit. (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/composite-services-complexity-measure.html)
2. Keep service dependency in manageable limit (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/inter-service-dependency-model.html)
3. Keep granularity of services under predefined criteria. Visit this criterion regularly.
4. Avoid recursive service calls.
5. Classify services as technical and business
6. Avoid complex and huge service contracts
7. Handle anticipated Faults and Exceptions
8. Keep Fault handling and Exception logic out of main process flow
9. Develop compensatory processes
10. Pay attention to Quality of Service (QoS) of services involved in Orchestration
11. Pay governance policies to services involved in Orchestration
12. Remember Separation of concerns
13. Validate messages flowing in a process – in process, and in out of the process
14. Pay heed to vendor specific best practices and design principles
15. Last but not least: Test, test, test, …
From my experience on Oracle Fusion, TIBCO, Aqualogic and WebMethods I have collected some Services Orchestration Design Principle & Best Practices. I am listing those, independent of Tools/Platforms:
1. Keep Orchestration depth to manageable limit. (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/composite-services-complexity-measure.html)
2. Keep service dependency in manageable limit (Refer: http://architecture-soa-bpm-eai.blogspot.com/2009/01/inter-service-dependency-model.html)
3. Keep granularity of services under predefined criteria. Visit this criterion regularly.
4. Avoid recursive service calls.
5. Classify services as technical and business
6. Avoid complex and huge service contracts
7. Handle anticipated Faults and Exceptions
8. Keep Fault handling and Exception logic out of main process flow
9. Develop compensatory processes
10. Pay attention to Quality of Service (QoS) of services involved in Orchestration
11. Pay governance policies to services involved in Orchestration
12. Remember Separation of concerns
13. Validate messages flowing in a process – in process, and in out of the process
14. Pay heed to vendor specific best practices and design principles
15. Last but not least: Test, test, test, …
Service Orientation
In one of recent discussions, I developed a diagram to understand SOA key concepts.
I am interested in knowing your views.
I am interested in knowing your views.
Tuesday, March 24, 2009
SOA Evolution
We talk a lot about SOA but we seldom pay attention on its evolution - past, present and future. I have tried to map SOA evolution in terms of increasing complexity.
Service Misconceptions
As the SOA is maturing so the web service, one of the most common way to implement SOA. But misconceptions about Web service are still prevalent among developers, architects and business persons. Here I have listed some of them and giving arguments for them. This list is comprehensive but far from complete.
1. Web services are not distributed objects
2. Web services are RPC of internet
3. Web services need http/s
a. Have you think of JMS, SMTP, UDP etc based services
4. Web services are not for large amount of data transfer
Please refer:
MTOM specification
5. Debugging of web services is impossible
Please refer:
a. Progress Actional Diagnostics
b. XMLSpy® 2009
6. Web service do not support transaction
Please refer:
a. http://www.ibm.com/developerworks/library/specification/ws-tx/
b. http://www.ibm.com/developerworks/webservices/library/ws-comproto/
c. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx
7. Web service security is sketchy
Please refer:
a. http://en.wikipedia.org/wiki/WS-Security
b. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
1. Web services are not distributed objects
2. Web services are RPC of internet
3. Web services need http/s
a. Have you think of JMS, SMTP, UDP etc based services
4. Web services are not for large amount of data transfer
Please refer:
MTOM specification
5. Debugging of web services is impossible
Please refer:
a. Progress Actional Diagnostics
b. XMLSpy® 2009
6. Web service do not support transaction
Please refer:
a. http://www.ibm.com/developerworks/library/specification/ws-tx/
b. http://www.ibm.com/developerworks/webservices/library/ws-comproto/
c. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx
7. Web service security is sketchy
Please refer:
a. http://en.wikipedia.org/wiki/WS-Security
b. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
Subscribe to:
Posts (Atom)
Posts
