Razorbills: What and How of Service Consumption

Maarten Mullender
Microsoft Corporation

January 2005

Summary: Maarten Mullender explains the fundamental idea of creating a description of what Web services expose, and then explores possible use of such descriptions. (14 printed pages)

Contents

Introduction
What and How
What
Entities
Views
Actions
References
Relationships
Entities and Views in SOA
How Can What Be Used?
Entity Aggregation
Collaboration
User Interaction
What Should Happen Next?
Raise Her Bill
See Her Chin
What Should We Do in the Meantime?
Footnotes
About the author

Introduction

Why did the razorbill raise her bill? So that the sea urchin would see her chin!

Almost exactly seven years ago, I read a Microsoft internal memo called The Internet Applications Manifesto, Take II or The Sea Urchins Memo. This paper pushed for using XML as the communication mechanism between services. To quote:

I call this model the sea urchin model because I think of sites already as sea urchins with many spikes sticking out of them (URLs) each dispensing UI (HTML). These URLs as most have already realized are the "methods" of the site. In this brave new world, I expect sites to also routinely become Information dispensers with the "methods" of the site returning not UI but information. Thus one can think of the Web as a sea filled with spiky sea urchins, all willing to emit information of various kinds if one but knew to ask. Initially, one will have to know to ask. The evolution of an infrastructure that can automatically find such information will depend upon the emergence of what I call "Schema", namely universally agreed upon types of semantics that allow multiple independent consumers and producers to agree on how to share information in specific domains. See opportunities below for more on this.

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. Describing the 'what' will add dramatically to the usefulness of services and "raise her bill". I propose standardizing the 'what' description using Entities, Views, Actions, References and Relationships.

Service Oriented Architecture (SOA) 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.

What and 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 and everything else needed to describe how to send the message. It does not describe what should be called. For any dedicated client or consumer of a service that already knows what to call, this is great and since the infrastructure and the description are based on standards, the code is reusable and many technologies can interoperate. This means that you can create communications between many parts, based on a single infrastructure.

However, this implies that the logic of what is being called is coded into the application. When organizations want to be flexible, they may want to access services to get information, aggregate information, and reorder information, or they may want to change process flows. Currently, to do this, they require developers. This may make the desired changes expensive—in many cases, too expensive. Organizations facing this problem would rather have business analysts, and even business users, make these changes. This would make change cheaper, shorten the change cycle, and make them more agile.

If our software could communicate this 'what' to the business people, then they could define new aggregation of information, and change or create the flow of processes without the help of developers.

If we describe what services have to offer 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 generally 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 use 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. The entity is made up of the combination of all of its state, its behavior as well as its relations to other entities.

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 exposing attributes or properties of the entity. It must be noted however, that views do not necessarily present a subset of the entity information. They may very well contain information from related entities and overlap with views on those entities. The view on an order may contain the customer's name and address as well as the product descriptions so that it may be used in the user interface or to populate a document.

Actions

The service also exposes methods or actions. Many of the actions are related to an entity. For example, "release order" or "upgrade customer" are clearly related to specific entities. And, if these actions require input information, this information often comes from views on other entities. For example, a request to a supplier to create a sales order is built using the information from a purchase proposal. A view on the purchase proposal is converted into the sales order request.

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. Customers can be identified using their social security number, tax number, or 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 and a more generic way as well.

References formulate queries to services. Such a query may be as simple as the list of key attributes or as complex as the formulation of a complete set of conditions. Often a reference will consist of a combination of required and optional attributes allowing clients that have different information to obtain the same views and use the same actions through the same interfaces. Design of reference schemas is just as important and just as complex as the design of view schemas.

Relationships

Now, if we have a view of one entity, an order say, it should not be too hard to build a reference to a related entity, e.g. the customer for that order. In other words, we can transform the order-view into a customer-reference which refers to the customer entity. This effectively gives us a relationship between the order view and the customer entity.

A relationship uses the data in one view to construct a reference to another entity. Such a relationship can be defined using the schemas of a view and a reference. Consequently, 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 should not only describe the artifacts and the relation between them, but also their behavior, what people can do with them and what software can do with them. This description can easily be linked to, and in fact has to build on, the existing description of the how.

Even though much of this information can be provided by the designer of the service interface similar to how WSDL is currently provided, an extension to WSDL cannot solve all of 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 runtime 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 in many other systems the analysis has been done and captured in some form of metadata.

The values in these references came from the view on the order. The names of the elements and attributes may be different between the view and the reference. Sometimes it is even useful to merge in values that did not come from the original, if you want to restrict the result set to a specific department for instance, or, if you need a combination of views as the source (e.g.: all customers that bought a product xyz from account manager abc). The recipe that gets you from the view or the set of views to the reference is called a relationship. The relationship can be defined as an XSLT or as a piece of code, it doesn't really matter as long as the consumer understands how to interpret the metadata and construct the reference. The relationship describes how the consumer of the services can construct a reference from a view.

Example

Let me give a simple example. Suppose we retrieve an order—i.e., a view on an order—from a Web service. The order view may come in XML that, after much simplification, looks something like:

Table 1.   Simplified Order View

<ERP:Order OrderID="8245" >
<Customer CustomerID="4711" >
<CustomerAddress
Name="Microsoft Corporation"
Country="USA"
...
/>
</Customer>
<OrderLines>
...
</OrderLines>
</ERP:Order> 

The view is not restricted to what is stored in the order table or in the order object. This view on an order includes some customer information and possibly some product information, so that it can be displayed or printed.

From such an order, we may derive references to the customer for the order:

Table 2.   Examples of Customer References

<ERP:CustomerReference CustomerID="4711"
/>

<CRM:CustomerReference CustomerName="Microsoft Corporation"
State="WA"
...
/>

<My:CustomerReference CustomerID="4711"
CustomerName="Microsoft Corporation"
State="WA"
...
/> 

References may refer to entities, thus allowing the consumer (the user or the client-side code) to decide which view to retrieve, or they may refer to a specific view on an entity. The reference schema alone is not sufficient for the client to retrieve a view. The client needs a description of which service provides access to the service, which method needs to be called, and how to call that method using the given reference. For any given view, there may be one or more references that can be used to obtain that view and for each valid combination we need the description of which method to call. Not all customer references can be used to retrieve all customer views. For example, an ERP service may not provide a method to retrieve customer information using the Social Security Number (SSN), but the CRM service may. So, you may go to the CRM service to retrieve enough customer information to build a reference to the ERP customer.

Lists have views too: a customer address list is completely different from a customer balance list. Both are views on a list of customers. The descriptions of Entities, Views, Actions, References and Relationships would not be limited to schemas and recipes. These descriptions would encompass information about those artifacts.

The descriptions need to be useful both to humans and to software, including describing:

• Which method needs to be invoked to retrieve a specific view from a reference.
• How long a view is guaranteed to remain valid, or how long it may be used to formulate requests. The prices in the catalog from Ikea are valid for a year, but what information can I use from a production schedule, and, for how long? What can we describe about these different types of information contained in views?
• Caching behavior and how to optimally retrieve and manage the offline views.
• Access rights on references and thus on relationships.
• Relevance of relationships for certain roles, allowing the user interface to display the most relevant relationships.
• Types of relationships, such as one-to-one relationships, one-to-many, one-way, hierarchical, sibling, 'hard' and 'soft', etc.
• How an aggregated view is composed and what the caching policy for the constituent views and thus for the aggregated view is.
• When an action should be enabled or disabled in the user interface.
• The action's impact on the service's state. Does it update state, is the update transactional, does it throw exceptions or offer retries, etc.

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 no longer reflect the internal state of the service even when I receive it, and the chance of my view being out of sync 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 not see the entire building; you will only see it from one particular angle. The building will not change much 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.

Table 3.   Examples of OrderList References

References do not always return a single instance. It is equally possible to have references to lists, like for instance:

<ERP:OrderListReference CustomerID="4711" 
/>

<ERP:OrderListReference of
ProductID="B-747"
/>

<ERP:CustomerReference
CustomerID="4711"
/>

Because views are copies of data and may be or may get out of sync, the concept of references is important. They provide access to the source of 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 get out of sync. Normally, that will only happen if the entity ceases to exist. To avoid this from happening, I would recommend that the entity be marked as being obsolete rather than to delete it.

As I said above, the entity is made up of the combination of all of its state, its behavior and its relations to other entities. Understanding the mechanisms that cover the relationships between entities and their views, their behavior and other entities should form one of the fundamentals of any distributed architecture and thus of any SOA. It would be a huge step to capture these mechanisms in ways that can be used by the business people, the designers, and developers as well as by the systems.

These concepts are very similar to what we know from object orientation. However, there are differences. The most important one, I find, is the notion of distance between consumer and supplier of the functionality. The data has to travel from within the service to the consumer. One of the consequences of this is that, since the data will not be locked on behalf of the consumer, the consumer has to be prepared for changes to the service's state i. This leads to the concept of views. This notion of physical distance and the consequential temporal distance between requesting information, providing information and using that information leads to a whole new field requiring exploration ii. For instance, what is the behavior of the service when it is receives a request that uses older data? What are the guarantees the service will give about that data? When I issue a price list with prices valid through January 1, I guarantee that I will honor those prices. When I request a stock price, there is no guarantee whatsoever. What are the possible guarantees or service level agreements and how can we describe these?

How Can What Be Used?

Exposing all this information is extra work for the designers and developers of the service. This extra work will only pay off if these services are consumed using this new description. We don't only need infrastructure to capture and expose the functionality offered by the service, we also need the infrastructure to consume that information and offer it to business analysts and users so that they can do useful things. In the following, I present only a few examples of infrastructure to provide better service to users and thus to offer better human interaction.

Entity Aggregation

Formalizing the concepts of entities, views, and references provides a good starting point for a model for entity aggregation and for information integration in general and thus for an information architecture. By providing infrastructure and tools for information integration, building on a description of services in terms a domain expert understands, a business analyst will have more influence on the way the business is organized.

Let me revisit entities. Earlier I wrote that a service encapsulates entities. If we look at the customer entity, many organizations will have multiple services defining customer entities. There could be an ERP system with an ERP customer entity, a CRM system with a CRM customer entity and many other systems as well. Users might want to see an aggregated customer entity that has aggregated views as well as the original ones and that has aggregated actions as well as the original ones and that has all the relationships from the original ones and possibly some new ones. We want the business analyst to define these aggregations and reduce the required amount of support from the developers.

In entity aggregation, entities are combined to form new entities. These entities may live in the same service or may come from different services. Entity aggregation, or information integration, has two main aspects:

• Aggregating information
• Aggregating functionality

I will discuss these separately.

Aggregating information

An aggregated entity is defined by the views on that aggregated entity and by specifying how these views are built out of the underlying views. A business analyst can build new schemas using the existing ones, taking into account constraints such as whether the access rights to these underlying views match the intended audience for the aggregated view.

A tool should be able to see how the information can be retrieved from the specification of the composition. For instance the tool could decide that when presented with a CRM customer reference, the CRM view should be retrieved first and then a relationship from that view to an ERP customer reference could be used to obtain the ERP information. It could define a different path when presented with an ERP customer reference.

When the information needs to be replicated, the tool could look at the caching policies of the constituent views and provide replication for those and offer aggregation based on the cached views. In other cases it may try to minimize the number of constituent views. For example, by retrieving an aggregate view of the ERP customer, retrieve and cache that and then derive the smaller views from the cached aggregate.

Whichever the best algorithm for the specific problem, a tool should be able to offer working solutions using the information given by the description of what the services have to offer. The metadata should provide information that helps the business analyst define useful combinations and make appropriate policy choices and it should provide information for tools and runtime to support and execute both the decision process and the outcome.

Aggregating functionality

Actions on such an aggregated entity will often have to touch the underlying entities. In some cases this has to be an "all or nothing" action and in other cases it has to be made certain that all individual steps are executed. Both are examples of what I call short running processes or activities. A tool could concatenate actions based on their inputs and outputs. Moreover, given a description of the underlying actions or methods, including a description of their transactional behavior such as whether they update state, throw exceptions or offer retries, a tool could concatenate the underlying actions in a logical sequence to minimize chance of failure and inconsistency and even raise an event or send an email in case something does go wrong after all. Of course there is no reason to restrict this to entity aggregation, these types of activities happen all the time. This is generally applicable in the area of service orchestration.

Again, a description in user understandable terms allows a user or an analyst to combine and order a set of actions and build larger actions. A description of behaviors and side effects of actions allows a tool to make sure that such aggregated actions behave predictably and can be controlled and managed.

Even with good tool support, defining good schemas for views on and references to entities remains difficult. We should put more effort in providing guidance in this area. One of the major challenges in this area is designing for change, where the different artifacts have a different rate of change. Data obviously changes much faster than schemas do and some types of data change faster than others. The definition of the data may change while the definition of the processes remains unchanged. The reverse of this may happen too. Views, references, actions, code and process definitions will often change at different rates and at different times. A discussion on this goes beyond the scope of this document. Nonetheless, it must be clear that a good design of all of these artifacts must include a concept of versioning even in the first version.

Collaboration

References play an important role when crossing the boundary of organizations where one wants to make sure that both parties collaborate on the same subject. Often this is complicated by the fact that not all information can or may be shared. For instance when one physician sends information about a patient to another it is important to be able to send an exact reference to the other party, to unambiguously identify the patient, but both parties will have access to their own private additional information. The other party will have different information available and will access different services to obtain that information, but the reference may still be standardized for the domain and be communicated. The key attributes and therefore the data model do not have to be the same on both sides. It suffices to agree on an interchange format for the references.

On the other side, the work of collaborating users that do have access to the same services could be coordinated by those services if the users communicate references instead of chunks of information. Multiple users can request changes from the service and the service will resolve the concurrency issues. The single truth is clear to all in the coordinating service.

Microsoft Office Information Bridge Framework (IBF) uses references in documents to communicate information and to allow the user to add business context to a document. References can be used to convey not only a limited piece of information, such as an expense report, but also to provide access to a wealth of information, such as the trip report, the customer opportunities, and other information related to such an expense report. If the recipient of the information has a description of the references and of relationships used in the document, this user can then do more than just consume the information compiled by the sender. Related relevant information will automatically be available and offered as well.

Many collaborations or workflows designed today store the data with the flow. The flow then just runs by itself based on that data. It breaks as soon as someone does anything in the backend system that influences the flow. For example, when designing a flow for doing a stock trade, the progress of the trade is stored in the workflow system and the flow tries to just go ahead. If someone blocks that trade in the backend system, the flow runs into an exception at some next step. In other words the designer should have synchronized the state of the flow with the state of the backend system.

References are also a way to avoid unneeded duplication or even multiplication of state—state that may, and often will, become out of sync. Formalizing references will reduce, not completely solve, the problem.

This is true for workflows and for document collaboration. There is no difference between using references in workflows, documents, e-mails or in instant messenger. In all cases I have the choice between sending the data itself or a reference to that data and in all cases I have to manage change between many copies when I send the data or I have a service manage it for me. If I send a document to ten people for review; each person gets a copy and everyone makes changes. If instead I send everyone a reference to the document, each person can edit the document and the changes are synchronized by the service. Using the references avoids making many copies and having to manage those copies. This can now be delegated to a service that was already designed to deal with concurrent updates and that service does not care whether the references were sent by email, instant messenger or as part of a workflow.

The main points here are that in designing for collaboration and processes in general:

1. Avoid building a parallel data structure, but use references instead to make it easier to develop robust flows and collaborations
2. Eliminating different types of payload makes designing the system easier. References have behavior: the actions defined by the service description of the entity. The workflow can use this behavior.

The concept of references helps reduce synchronization issues and this helps reduce the need for conflict resolution. It also helps convey uniquely identifiable information without the need to align the systems, which then can be used to identify related information by following the relationships. Capturing these concepts makes them available to tools, infrastructure, and thus to humans.

User Interaction

The description of views and actions effectively exports this functionality to the consumer of the service. A consumer can use this to provide presentation for views on entities in the user interface. The step to portals seems a natural continuation. For instance a portal can define parts to show views on entities. A part showing the content of such a view to the user can provide access to the actions, using buttons, or smart tags, thus exposing these actions to end users. The metadata can provide hints to the user interface on how to expose the actions and the run-time description can provide hints as to whether certain actions are available at this time for the instance that is currently displayed.

If these parts use portal infrastructure based in the proposed metadata, then that infrastructure would know which view on which entity instance is being shown. It could then offer the user a choice of relevant related instances that the user could navigate to. IBF was the first instantiation of this idea and offered a portal in the task pane.

Not only presentation, but also offline availability would be aided by a description of the views and their relationships. Service agents manage offline and cached information on behalf of their consumers. I could see a design where if such a service agent is triggered to take an instance offline, it uses the relationships to see what further relevant information should be taken offline. It uses the relationships to find the relevant instances and to prune the offline tree by weighing that relevance. For instance, if the calendar takes an appointment offline for a customer visit, by following the reference in the appointment the customer information can be taken offline, and by following further relationships, the problem reports can be taken offline as well.

The concepts of portal parts and service agent infrastructure form the basis for a smart portal infrastructure. The addition of the extended service description provides user interface with the ability to generically provide actions to the user and enable or disable these actions as appropriate. Moreover the description of relationships between the views provides navigation between the parts. The description also offers service agents the opportunity for more intelligent offline behavior. All in all, the description of services offers much to make a smarter portal.

What Should Happen Next?

It is only a logical evolution that leads us from how to access services to what services offer. Many organizations and vendors already describe the functionality of their services in metadata. It is only a reasonable to expect that the industry will standardize on the way to describe these services. It is equally reasonable to expect that it will take time, a lot of time.

The Sea Urchins memo was about how to communicate. Razorbills is about what to communicate; until she can "raise her bill" the sea urchin will never "see her chin." Just like the original Sea Urchins memo discussed the need for both a method and tools for sharing data, for functionality, we will need infrastructure to describe and expose what functionality services have to offer. But such infrastructure alone doesn't bring about change. So, we will need applications and application infrastructure to use these descriptions. One will not be available before the other, they will have to grow up together and in the mean time, we will want to use some of the concepts already. We don't want to wait for this entire infrastructure to be available, but we do want to use it as it becomes available.

Raise Her Bill

Standardization on exposing what services have to offer requires an industry effort in the following areas:

Extensible model to describe what services offer

This, like the current WS standards, should offer a fixed basis and be extensible in most areas. For instance, multiple standards describing caching behavior or the guarantees on data validity might evolve and each of these needs to be plugged in to the overall description.

Extensible infrastructure for that model

It is important to provide a model that, like WSDL, can be queried by both tools and service consumers. However, it is equally important to not just provide static information. The effort needs to align with our thinking on service contracts and should include dynamic definition and redefinition of views, actions, references, relationships and even entities. Such as, providing the current availability of actions and relationships on a particular instance or provide information about an instance of an ad-hoc workflow. Building on the extensible SOAP infrastructure, this should become part of the .NET Framework.

Shared infrastructure for storing inter-service description

The description of everything that transcends a single service needs a place to go. This includes relationships between entities in different services as well as the description of user interface or hints for user interface. I am hesitant to call for a directory infrastructure on top of UDDI. Distributed directory infrastructures are gaining popularity and seem to offer good alternatives. Important in this context is only that consumers of these services can store and query a description of inter-service relationships. After the Sea Urchins memo, it took us a few years to be convinced that XML was the way to communicate and we're still struggling to define all of the standards and required infrastructure. It will take time before the above starts being realized and the razorbill will have proudly raised her bill. However, would this be enough for the sea urchin to see her chin?

See Her Chin

For the above infrastructure to be visible and usable, the industry would have to provide tools, applications, and higher level infrastructure that allows the users, the business analysts, and even developers to build on that infrastructure. I will suggest a few here and others will be able to extend this short list with many other useful examples. Not all of the above infrastructure needs to be in place. Some of these can start using more proprietary solutions. When solutions like these become available, everybody, including the sea urchin, will be able to see the razorbill's chin.

Build tools for Entity Aggregation and Service Orchestration

Bring aggregation and orchestration to the domain of business analysts where it belongs. In Microsoft, BizTalk would form an ideal basis to build tools for this.

Provide User Interface infrastructure to browse the business

Build a Smarter Portal defining default presentation for views, thus allowing navigation from view to view, across entities and across services.

Provide a Framework for Service Agents

Such a framework would enable smart clients to deal with intermittent connectivity and caching and queuing. Using the relationships, service agents could not only take views offline, but could also provision relevant related information.

What Should We Do in the Meantime?

Putting all this infrastructure in place will be a multi-year effort. To prepare for this future, I recommend those building services:

Differentiate between entities and views

Distributed computing and therefore Service Oriented Architecture and Design introduce the necessity to think about the distance between the services and between the service and its consumer. Differentiate between the entity information contained in the service and the copies of information defined by the views. Put these views into schemas and assemble a collection of reusable schemas. Build on existing industry specific schemas when available. Define and describe the properties of these views. For example, manage access to information by means of views and examine how the service honors the information it handed out in accepting requests that use that information.

Formalize the concept of references

When defining an information model, model references, build services to use these references, abstract away the key attributes, think about the defining attributes of the entities and schematize this to allow other services and humans to interact with these services.

Footnotes

i See for instance my article Dealing with Concurrency: Designing Interaction Between Services and Their Agents.

ii Pat Helland has an interesting article on this subject. See Data on the Outside vs. Data on the Inside.

About the author

Maarten Mullender
Microsoft Corporation
maartenm@microsoft.com

Maarten Mullender is a solutions architect for the .NET Enterprise Architecture Team; this team is responsible for architectural guidance to enterprise architects. During the last seven years, Maarten has been working at Microsoft with a select group of enterprise partners and customers on projects that were exploring the boundaries of Microsoft’s product offerings. The main objectives of these projects were to solve a real customer need and, in doing so, to generate feedback to the product groups. Maarten has been working for more than twenty years as a program manager, as a product manager and as an architect on a wide range of products.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.

© Microsoft Corporation. All rights reserved.