Razorbills - What and How of Service Consumption
Razorbills
What and How of Service Consumption
Why did the razorbill raise her bill?
Because the sea urchin would see her chin!
Less than five years ago, I read a Microsoft internal memo called “Sea Urchins”. This paper pushed for using XML as the communication mechanism between services. Since the “Sea Urchins” memo, we have made great progress in describing the how of services. With “Razorbills”, I propose putting a similar effort behind providing a description of the what of services.
I propose standardizing on a description of this what based on Entities, Views, Actions, References and Relationships. Service Oriented Architecture is as much, if not more, about consuming services as it is about building services. To enable better consumption I believe we need infrastructure that allows people that may be less technical but do have domain expertise (the so called business analysts) to design and build solutions. We need infrastructure that allows users of any application, structured forms as well as free form documents, to really use the functionality offered by services. Standardization on a way of describing services in business terminology will help do that. It will help business analysts and users to better bridge the gap between the structured and the unstructured, the formal and informal, both in content and in process.
How
Current service descriptions such as WSDL and the WS-Standards describe how to access functionality. Once the caller has decided which functionality to invoke, the WSDL describes how to encode the message, how to route the message, how to secure the message, how to authenticate the caller etc. It does not describe what should be called. For any dedicated client or consumer of a service that knows what to call, this is great. The infrastructure and the description are based on standards, so that there is much code reuse and many technologies can interoperate. A web of communication, based on a single infrastructure, can be created.
However, this implies that the logic of what is being called is coded in the application. When organizations want to be flexible, they may want to access services to get information, aggregate information, reorder information or they may want to change process flows. In order to do this, they need to rely on developers. This may make the desired changes expensive and, in many cases, too expensive. Organizations facing this problem would like to have these changes made by business analysts and even business users rather than developers. It would make change cheaper and it would shorten the cycle of change and make them more agile.
If our software could communicate this what to the business people, then they could define new aggregation of information, change or create the flow of processes.
If we describe what the business wants to do and we describe this in terms understood by both business people and software, we would not only have a description of the how, but also of the what.
This information is available today, but it is in the heads of the designers and developers at worst and in some design documents at best. The consuming applications are being written using this knowledge. However, it is not available to tools and other software that could be used by analysts and users to solve their challenges. We need to find a standard way of describing this information.
In the following I will explain the fundamental idea of such a description of what services expose and then I will highlight possible usage of such description. I believe and I hope that I will be incomplete; going down this road will undoubtedly provide us with more insight and more ideas.
What
Services expose business functionality to their consumers. Business analysts and business users often prefer to think in terms of the entities they use. They understand the relationships between these entities and the actions that can be taken on those entities.
Entities: Most services encapsulate entities. However concrete these entities were for the designers of the service, for the consumer of the service they are abstract. The consumer cannot touch them or manipulate them; the consumer does not know whether they are stored in a single table or in a set of files. The consumer however does understand what they represent: Customer, Order, Problem report, etc.
Views: The service exposes views on these entities. The consumer may obtain an address view, or a financial view, or a historical view on the customer. These views are snapshots of the entity, taken from a specific viewpoint. The views are concrete. They have a well defined schema.
Actions: The service also exposes methods or actions. Many of the actions are related to an entity. E.g., release order or upgrade customer are clearly related to specific entities.
Entities, views and actions are artifacts that we can describe, that a user can understand and that may help us describe services in ways that can be understood by business analysts.
I want to mention other artifacts that are less often used.
References: Many entities can be identified using key attributes. However, they can often also be uniquely identified using other attributes. The customer can be identified using his social security number, the tax number or the DUNS number. A list of customers can be retrieved via the zip code, the region or the account manager. We can formalize this through the concept of reference. A reference defines either a unique instance or a list of instances. A reference, like a view, has a schema.
The actions exposed by the service accept references to identify the entities they operate on. The references are a more formal way of defining possible input.
Relationships: Now, if we have a view of one entity, an order say, it should not be too hard to build a reference to the customer. In other words, we can build relationships that transform a view into a reference. These relationships can be defined using the schemas of views and references and these relationships are not constrained to a single service; they can define relationships between entities encapsulated in different services.
If we are able to describe these entities, the views on these entities, the relationships between these entities and the actions on these entities in terms that are understood both by the business people and the software, we would have a description of the what. This description can easily be linked to the existing description of the how.
Much of this information can be provided by the designer of the service interface in a similar fashion WSDL is currently provided. However, an extension to WSDL cannot solve all our needs. Relationships between entities offered by different services should not be stored in either, but would require storage external to these services. Instance specific information, such as the current availability of relationships and actions, as well as information created at run-time, such as tasks in a collaborative workflow, require run-time interrogation of the service and thus a run-time description. This is very much related to service contracts and the required infrastructure for providing run-time information about the state of a specific conversation.
Since views are what the designer exposes of the entities, much of the information is available in the systems today. Every service that was designed around entities provides most of the information needed and many other systems the analysis has been done and has been captured in some form of metadata.
Entities and Views in SOA
The differentiation between entities and views is important in a distributed environment. Data is copied between the systems and whenever the consumer of a service retrieves data, it will get a copy. When I request information about an entity, I will receive a copy. This copy is a view on, or a snapshot of, the state of the entity from a particular angle. I may receive the customer’s financial view, or the customer’s satisfaction view, or the customer’s contact view. These views depend on what I want to do and what I am allowed to see. When I receive that information only a few milliseconds later, the service may already have moved on and changed its internal state. The view may be stale even when I receive it, and the chance of it being stale increases the longer I hold on to it. The differentiation between View and Entity is an important recognition of the fact that the consumer has an outside view on the entity and that there is a time difference between creating that view and receiving it. It’s like taking a picture; the picture is frozen in time, whereas the subject of the picture may move on. If you take a picture of a building, you will only see the building from one angle. The building will not change after the picture has been taken, but the people on the picture, the clouds on the picture and even the trees on the picture will move. The snapshot is taken from a particular angle or viewpoint and frozen in time.
Because views are copies of data and may be or become stale, the concept of references is important. They provide access to the source o the information, to the entity itself. They allow us to convey and store information and let the service that encapsulates the entity deal with the concurrency issues. References are less likely to become stale. They will become stale only if the entity ceases to exist. Views and References are the carriers of the information. They are the basis for information integration and entity aggregation. Understanding their relationships to entities, their behavior and capturing their schemas should form one of the fundamentals of any distributed architecture and thus of any Service Oriented Architecture.
Comments
Anonymous
May 26, 2008
Razorbills What and How of Service Consumption Why did the razorbill raise her bill? Because the sea urchin would see her chin! Less than five years ago, I read a Microsoft internal memo called “ Sea Urchins ”. This paper pushed for using XML as the communicatioAnonymous
June 08, 2009
PingBack from http://cellulitecreamsite.info/story.php?id=9946