Operations in a Service Interface v 6.0

Traditionally, we think of only CRUD operations for a service on technical front. Are they sufficient? I have tried listing few more (:-)).

What do you think of?

Varity of Type Definition in a Web Service

In most of WSDLs of enterprise class one finds very simple definitions of types.

But this approach has one serious flaw, if source like to change (generally add) type system, service has to change. To manage changes at source system, multiple versions of a service crop up in enterprise environment. But the good part of this approach is that one looking at types in WSDL can understand the types easily and least documentation is required for attribute/parameters.

To overcome the changing number of attributes/parameters and containing changes in source and target systems only (not in the system which facilitates exposure of functionality as service – web service) one can follow one of the following approaches:

Approaches 2 and 3 have their own set of challenges. Understanding of types is not intitutive and needs documentation with greater details.

Operations in a Service Interface v 4.0

Now the fourth version

Operations in a Service Interface v 3.0

I have listed the operations a service should exposes in my earlier post. I have revised the list. The latest is:

A Small Step for Service Governance

While talking about SOA Governance, one visualizes big fat software and tools which costs millions of dollars and a platoon of support staff to “govern” SOA Governance platform.
In my experience, I noticed that small baby steps always more helpful and governance should be embedded in architecture and design. Instead of SOA Governance, I like it to be service governance first.
Recently, talking to one of my counterpart at my client place, I encountered a classic case of mis governance in services space. Once service is created and deployed, its contract ( wsdl in case of web service) is freely available across enterprise which makes unknowns its customer (sic) without any controlling authority. This uncontrolled distribution and usage of contract leads to nightmares and fights when service performance decreases or new version of service need to be releases and older version to be retired.

How to avoid such dogfight!

Simply create a registry (not UDDI) of service and make sure that this registry contains the information that who is calling whom and authentication has to pass through this registry. I understand this suggestion violets purist form of SOA but in this world nothing is perfect.

Operations in a Service Interface v 2.0

I have listed the operations a service should exposes in my earlier post. I have revised the list. The latest is:

Operations in a Service Interface

In a service interface various operations are exposed. These operations can be grouped in few categories. I have tried listing these categories as:

Book Review: Service - Oriented Modeling by Michael Bell

Book Review: Service - Oriented Modeling by Michael Bell: Publisher- John Wiley: ISBN- 13: 978-0-470-14111-3

Though book is published in 2008, I got the chance to real this book now. Before reading the book I had impression that this book is about SOA modeling and will be helpful in my modeling task. But its reading was quite disappointing. Book tryies to cover too many things and looses the context very frequently.

Book is highly theoretical and targeted to academics. It virtually holds no practical advice to practitioners.

The modeling part of SOA starts from chapter 8 onwards but again author looses the track very frequently.

If Michael likes to develop a language for SOA modeling he should approach some industry consortium or community so wider acceptability can be developed.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: Related information at Wikipedia: http://en.wikipedia.org/wiki/Service-oriented_modeling and at IBM http://www.ibm.com/developerworks/library/ws-soa-design1

One can get more information about book and related topics from:

1. Amazon http://www.amazon.com/Service-Oriented-Modeling-SOA-Analysis-Architecture/dp/0470141115
2. Publisher -- Wiley http://as.wiley.com/WileyCDA/WileyTitle/productCd-0470141115.html
3. Wikkipedia: http://en.wikipedia.org/wiki/Service-oriented_modeling

Book Review: Successful Service Design for Telecommunications - A comprehensive guide to design and implementation

Book Review: Successful Service Design for Telecommunications - A comprehensive guide to design and implementation: Publisher- Wiley: ISBN- 13: 978-0-470-75393-4

During course of designing a Telecom/ISP product architecture and design product, I encountered Successful Service Design for Telecommunications – A comprehensive guide to design and implementation by Sauming Pang. Before starting the book my impression was that this book will talk about details of Telecom specific service design and implementation. But After reading the book I realized that this book is not confined to Telecom vertical. The principles outlined in this book are universally applicable across industry vertical.

Though book does not mention any of the frameworks but it seems that book is highly influenced by USBOK .

The book is divided into twelve chapters which very clearly depict considerations of design and implementation. The book not only covers technical considerations but also business which are generally overlooked by technical folks.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A complementary book is Telecom Management Crash Course : A Telecom Company Survival Guide (Crash Course) by P.J Louis http://www.amazon.com/Telecom-Management-Crash-Course-Survival/dp/0071386203

One can get more information about book and related topics from:

1. Amazon: http://www.amazon.com/Successful-Service-Design-Telecommunications-implementation/dp/0470753935
2. Publisher -- Wiley http://as.wiley.com/WileyCDA/WileyTitle/productCd-0470753935.html
3. Purchase at Flipkart: http://www.flipkart.com/successful-service-design-telecommunications-sauming/0470753935-0xw3f9w0fq
4. Purchase at A1Books: http://www.a1books.co.in/searchdetail.do?a1Code=booksgoogle&itemCode=0470753935

Pattern Service Discovery - ESB

Pattern Service Discovery - ESB v 1.0 dated Oct 06 2009

Pattern Service Discovery - Registry

Pattern Service Discovery - Registry v 1.0 dated Sep 30 2009

Pattern: Service Discovery - Direct

Pattern Service Discovery-Direct v 1.0 Dated Sep 22 2009

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.

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.

SOA Pattern - Service Invocation – Asynchronous - PubSub

Pattern Service Invocation-Asynchronous-PubSub v 1.0 Dated Sep 13 2009

SOA Pattern - Service Invocation – Asynchronous - Queue

Pattern Service Invocation-Asynchronous-Queue v 1.0 Dated Sep 11 2009

SOA Pattern - Service Invocation - Synchronous

Pattern Service Invocation-Synchronous v 1.0 Dated Sep 10 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.

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

Build, Buy or Reuse: Services

The one of the most flaunted benefit of SOA is reuse of services. But it is one of the least used aspects of SOA. But Why so?

In enterprises there is no framework exist which can evaluate a service/service requirement which help in reach a decision of Build, Buy or Reuse. To fill up this gap, I have developed a framework. This framework has three aspects:

1. Appraisal Structure
2. Evaluation Criteria
3. Influencers

Appraisal Structure

The Appraisal Structure offers a classification for the types of considerations within the context of the business. The considerations and decision to build, buy or reuse fall into the following categories:

a. Strategic
b. Tactical
c. Operational
d. Business
e. Technical

Strategic considerations deal with the long-term vision and direction of an enterprise. These include:

• Market Share and Differentiation
• Growth
• Strategic Change Management

Tactical considerations deal with the short-term decisions and direction of an enterprise. These include:

• Current Project Portfolio
• Cash flow considerations
• Time consumption considerations

Operational considerations deal with the operational aspects of a project or a portfolio of enterprise. These include:

• Governance
• Change Management
• Skills
• Support and Maintenance

The business considerations are the ones that support the short- to medium-term objectives of the business. These include:

• Contract Management
• Depreciating of Assets
• Internal or External Provision

Enterprise have a technical strategy—one that states what technologies can be used and for what purposes. Considerations in this category include:

• Technology Considerations
• Technology Choice
• Interoperability/Integration
• Repository of Assets

Evaluation Criteria

There are eight Evaluation criteria identified eight attributes that affect Build, Buy or Reuse decision of services.

• Delivery Time
• Complexity
• Investment
• Expense
• Maturity
• Requirements compromise/match
• Maintenance
• Support




Influencers

There are five influencers. Each influencer has attractive and repulsive force field. Which force field will be more effective depends upon particular scenario – internal and external environmental conditions.

• Investment: It has one of the strongest force field – attraction as well as repulsive. This influencer has numerous aspects such as remaining cost-neutral RoI, profitability, affordability, and finally the cost implications of not doing it.

• Expenses: This influencer affect any decision on continuous basis. Investment and expenses in combination cover financial aspect of Build, Buy or Reuse decision. Like Investment, Expense also has multiple views – Cash Flow, ToC, etc.

• Quality: In market one with right quality wins keeping other parameters constant. Therefore Quality of Service (QoS) plays major role while making Build, Buy or Reuse decision. This influencer is also multi facet. Most of the abilities or non functional requirements are covered under Quality head.

• Time: In fast changing environment time is very critical. Time to market is one of the important parameter which affects Build, Buy or Reuse decision.

• Sustainability: Due to fast pace of technological and business environment evolution, obsolesce of a particular service and effort needed to keep it updated drives Build, Buy or Reuse decision.

The framework is very general in nature. It must be tweaked to a particular enterprise business environment, vision, goal, objectives and tactical needs.

Reference: The Architectural Journal (Microsoft) 20