OASIS Reference Model for SOA. Part 9: Core Concepts – Execution Context

March 28, 2008

This post is part of a series. Click here for the ‘home page’

According to OASIS, the execution context of a service interaction is the set of infrastructure elements, process entities, policy assertions and agreements that are identified as part of an instantiated service interactionThe execution context is the foundation of any successful service interaction because:

  • It is a collection of all the agreements in place for a given service interaction (e.g. semantics, protocols, policies etc).
  • It allows the consumers and providers to distinguish between different instances of the same service.
  • It allows providers and consumers to identify each other.
  • It provides a mechanism for policy enforcement.
  • It provides a mechanism for managing state (yes I know the theory says that services should be stateless but as with everything in technology – compromises sometimes have to be made)
  • It provides a context for interpreting data. For example, Amazon provides a ‘recommended books’ feature. A list of recommended books is meaningless unless you log in and tell Amazon who you are. Only then, does the data have meaning to you, the consumer.

It’s also noteworthy that:

An execution context often evolves during a service interaction. The set of infrastructure elements, the policies and agreements that apply to the interaction, may well change during a given service interaction. For example, at an initial point in an interaction, it may be decided by the parties that future communication should be encrypted. As a result the execution context also changes – to incorporate the necessary infrastructure to support the encryption and continue the interaction.”


OASIS Reference Model for SOA. Part 8: Core Concepts – Contract and Policy

March 25, 2008

This post is part of a series. Click here for the ‘home page’

According to OASIS:

  • A policy represents some constraint or condition on the use, deployment or description of an owned entity as defined by any participant.
  • A contract, on the other hand, represents an agreement by two or more parties.

Service Policy
In order to write effective service policies you need to keep just two things in mind:

  • Policies are based on assertions and assertions must be measurable.
  • An assertion can only be adopted as a policy if it is enforceable.

These examples will help clarify these two points.

Example 1: Valid and Invalid Assertions

An example of a valid (i.e. measurable) assertion is “all messages are encrypted.” This assertion is measurable because the message is either encrypted or it is not.

An example of an invalid assertion is “only small orders will be accepted electronically”. This assertion is not measurable because there is no way of knowing what ‘small’ means. A better assertion would be “only orders valued under $50,000 will be accepted electronically.”

Invalid assertions can never be policies.

Example 2: Valid Assertion and Valid Policy
A valid (i.e. measurable) assertion can be adopted as a policy only if it enforceable.

Continuing on from the above example, we know that “all messages are encrypted” is a valid assertion. It would also make a valid policy because:

  • We can measure the assertion: ether the message is encrypted or it is not
  • We can adopt the assertion as a policy because we can enforce it: if it is not encrypted the message will be rejected

Example 3: Valid Assertion but Invalid Policy
Just because an assertion is measurable does not mean that it will automatically make a good policy. To make a good policy the assertion must be enforceable.

Here is an example of a valid assertion:
“The value of the orders placed in any given day must not exceed $50000 unless prior arrangements have been made with the sales manager in charge of your account.”

This assertion is valid because:

  • We can easily measure the value of orders placed in a given day
  • We can measure whether ‘prior arrangements’ have been made – either they have or they haven’t.

Would this assertion make a good policy? It depends. If the service can find out whether ‘prior arrangements’ have been made in real time when an order is placed then it would make a valid policy. However, if the ‘prior arrangement’ takes the form of a phone call between a sales manager and a client and no record of it is made in a repository accessible to the service then clearly the policy is not enforceable.

When developing your service policy you may also want to consider these points:

  • Define policies in terms of ‘real world effects’. For example, your policies should:
    • prevent unauthorised actions to be performed
    • invalid states to be entered into
    • business rules to be violated
  • Explain the consequences of attempting to violate the policy (e.g. if a client tries to place an order over $50,000 it may be rejected and no harm done, or the account may be disabled)
  • Consider whether any ‘compensatory actions’ may be appropriate when policy violations are detected further down the chain (if the service the consumer is interacting with calls other services). It is not always possible to check all applicable policies ‘at the gate’ (the first service). For example:
    • the consumer calls Service A, which in turn calls Services B, C and D.
    • Services B/C alter shared stated used by D.
    • When D is called the request may violate D’s policies, but the violation may not have been foreseeable when A was called.
  • Policies should cover BOTH of these areas:
    • Infrastructure (e.g. security, privacy, Quality of Service etc)
    • Business rules

Service Contract
A service contract is an agreement between two parties. A contract is basically a collection of policies. The policies in a contract may be:

  • Generic policies that apply to all
  • Specific policies that relate only to the agreement/relationship between the parties in a contract.

A contract may be arrived at through:

  • Out-of-band process – outside of the SOA environment (e.g. lawyers in a boardroom)
  • In-band process – during the course of service interaction (e.g. a service may have a policy that when you interact with it for the first time, you are implicitly ‘signing up’ for a 6 month contract at a set monthly fee)

OASIS Reference Model for SOA. Part 7: Core Concepts – Service Description

March 23, 2008

This post is part of a series. Click here for the ‘home page’

The service description represents all the information needed in order to use a service. There is no one “right” way of describing a service, rather the elements of description required will depend on the context and the needs of the parties using the service.In essence, the service description is an amalgamation of information the other core concepts in the OASIS Reference Model:


As discussed earlier, interaction is composed of:

  • Behaviour Model, which is made up of:
    • Action Model
    • Process Model
  • Information Model, which contains information about:
    • Semantics
    • Structure

All of these elements should probably be included in your service description.

As discussed earlier, visibility is composed of:

  • Awareness
  • Reachability
  • Willingness

The documentation from OASIS suggests that you only need to include the ‘reachability’ components in your service but I disagree. I think all three elements need to be there. For example:

  • Awareness – location of the service (and maybe alternate/backup locations)
  • Reachability – protocols used
  • Willingness – fair use policies

Real World Effect
Clearly the whole point of interacting with a service is to “get something done”. The service description needs to include sufficient information to allow the consumer to clearly understand the real world effects of invoking a service.

For more information about real world effect click here.

Contract and Policy
A service description may include information about the policies (i.e. constraints or conditions of use) that govern the use of the service.

For more information about contract and policy click here.

OASIS Reference Model for SOA. Part 6: Core Concepts – Real World Effects

March 16, 2008

This post is part of a series. Click here for the ‘home page’

The consequence of invoking a service is the realization of one or more real world effects. These effects may include:

  • Returning information in response to a request for that information
  • A change in the shared state of defined entities
  • A combination of both

Note that the shared state does not necessarily refer to specific state variables being saved in physical storage but it is really a “mutual understanding” between the provider and consumer. For example, if I make an airline reservation, the airline and I have a mutual understanding that I will be travelling on a specified date. There is no “physical” data source that is shared between us.When thinking about real world effects in your architecture, consider such things as:

  • Does the consumer need to know ANYTHING about the internal (private) workings of a service? Does the provider need to know anything about the consumer? Each party should not have any knowledge of the internal workings of the other.
  • If the interaction between a provider and consumer is a sequence of events, how do you manage ‘incomplete’ state (i.e. when the sequence is not yet complete)?
  • Is there sufficient auditing/logging of real world effects?
  • Are ALL real world effects clearly understood by the consumer? Or is there any side effects of the interaction that the consumer may not be aware of?
  • Are the real-world effects clearly understood by consumers? For example, if you call a “BookFlight” service and no seats are available, the service may notify the consumer of that fact OR it may automatically put the person on a waiting list – this is also a real world effect but unless the consumer knows that this will happen it is not the real world effect intended by the consumer.

OASIS Reference Model for SOA. Part 5: Core Concepts – Interaction

March 14, 2008

This post is part of a series. Click here for the ‘home page’

Interaction with a service involves performing actions against the service. This interaction can be:

  • A message exchange (e.g. returning the result of a complex financial calculation)
  • Modifying the shared state of an entity (e.g. crediting a bank account)

In order to interact with a service we need two things: an information model and a behavioural model.

1. Information Model
The information model explains the information that may be exchanged with the service. It includes both structure (syntax) and semantics (meaning).

When evaluating your architecture for structure/syntax consider such things as:

  • Whether the data types are unambiguously defined (e.g. date formats, time formats, scale and precision of numbers).
  • Whether the character encoding is specified.
  • Whether the structure is as compact as it can be. Larger messages take longer to transmit and process.
  • Whether cardinality is clearly defined.
  • Whether data validation rules are clearly defined (valid ranges for values, minimum/maximum, values, required vs. optional values)?

When evaluating your architecture for semantics/meaning consider such things as:

  • Whether the service definition clearly explains the meaning of various entities used by the service.
  • Whether the understanding of various data elements is helped or hindered by the structure/syntax of the message (e.g. a data element ‘Line 1′ has no meaning by itself but if it is nested beneath an ‘address’ element then it make sense).
  • Whether all jargon and abbreviations have been eliminated. It may be easy for your organisation to understand but if you open up services to external parties they may be confused.
  • Whether there is a domain model with clearly understood semantics available for your industry. Does your information model conform to it?
  • Whether the interaction expected is documented sufficiently to remove ambiguity. For example, what would happen if you invoke a “DebitAccount” service with a negative value (will the request be rejected or will it in fact credit the account).

2. Behaviour Model
The behaviour model encompasses two things. Firstly, it explains what actions can be invoked on the service and secondly, it explains the process (or sequence of events) that needs to be used to invoke those actions (e.g. first request a security token, then pass the token when invoking the desired action). OASIS has labelled the former the ‘action model’ and the latter the ‘process model’.

When evaluating the action model of your architecture consider such things as:

  • Whether all actions have clear, unambiguous names. For example, actions called “UpdateAccountD” and “UpdateAccountC” are confusing whereas “DebitAccount” and “CreditAccount” are much clearer.
  • Whether there are any unexpected ‘side effects’ for consumers of invoking an action. For example, actions that imply read-only retrieval of data (e.g. GetBalance) should not be updating data.
  • Whether all “implied” effects of actions are clearly communicated. For example, if you invoke an action to close a bank account it may trigger other actions that the consumer may not be aware of (e.g. letter sent to client).
  • Whether all dependencies on other services are clearly documented?.
  • Since all requests for interaction will be validated, are all business rules (validations) clearly documented?
  • Should you  provide  ‘cut  down’ versions of your true capabilities (e.g. for security or resourcing reasons). For example, in ATMs you can only withdraw a certain amount per day. Banks do not have this limitation, but they choose to impose it on consumers of their ATM service.

When evaluating the process model of your architecture consider such things as:

  • If the interaction requires a sequence of events, is this sequence clearly documented?
  • How are exceptions/errors handled if the interaction process breaks down? Will there be some temporary state persisted? How will it be cleaned up?
  • Do consumers know if the service idempotent or not (i.e. will repeated invocation of the service produce the same result each time or will the result change each time)
  • If the service is invoked as part of a transaction, how will the service handle this?
  • Is the service “long running”? Are there people/manual processes involved?

OASIS Reference Model for SOA. Part 4: Core Concepts – Visibility

March 12, 2008

This post is part of a series. Click here for the ‘home page’

For a service provider and consumer to interact with each other they have to be able to “see” each other. The core concept of visibility canbe broken down into three components. .1. Awareness.
Service consumers need to know that a service exists.When evaluating your architecture for awareness consider such things as:

  • Where will you publish the existence of your service?
  • Will the organisation have one service registry? Multiple? None?
  • Do you really need dynamic discovery? Or will something “low tech” suffice.
  • How will you prevent the publishing of services that have not been approved?
  • How will you prevent the use of services that have not been approved?
  • Is the service sufficiently well described so potential consumers a) can evaluate whether a service matches their needs and b) understand how to interact with it and c) understand the “terms of use”.
  • Will the service description be pulled by the consumer? Pushed by the provider?
  • Will discovery be achieved by point to point or through broadcasting?

Once a consumer is aware that a service exists it can try and ‘reach it’.

2. Reachability.
The service provider and consumer must be able to connect to each other.

When evaluating your architecture for reachability consider such things as:

  • Is there are communication path between each service provider and all the consumers that might want to interact with it?
  • Will providers and consumers communicate on a VPN? Over the public Internet? Intranet?
  • What security policies are in place that may prevent reachability (e.g. firewalls) and who will need to be involved if these need changing.
  • If services will be used ‘locally’ to start with, how will you go about making these services available externally (business partners, geographically dispersed offices etc)?

Once a service consumer reaches the service provider, the provider must be willing to interact with the consumer.

3. Willingness.
The service provider must be willing to cooperate with the service consumer. Willingness to ‘interact’ is not the same as a willingness to perform requested actions.

When evaluating your architecture for willingness consider such things as:

  • How will you manage the load on the service?
  • How will you prevent abuse of the service, both malicious (e.g. denial of service attacks) and inadvertent (e.g. business partner using it too frequently).
  • Do you have “fair use” policies documented (and possibly published in the service description)

OASIS Reference Model for SOA. Part 3: Core Concepts – Overview.

March 12, 2008

Rather than simply rehash the documentation for the SOA Reference Model, I will demonstrate how you can use it in practice to validate a proposed SOA architecture. I said in an earlier post (here) that this is one of the key benefits of taking the time to understand this model.

The are 7 core concepts in the OASIS reference model.

The first concept is the cornerstone of the model:

  • Service

The next 3 concepts describe the dynamics of services:

The last 3 concepts deal with describing services:



    Click on each link above for an explanation of each one.


    This post will be updated as I add additional links.