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

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)
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: