One of the important principles of SOA is design by contract, and this is one of the principles that motivates and drives the service specification. In the same way that the term contract is used in a general sense to mean a formal agreement covering some form of interchange between parties or participants, Design by Contract indicates a formal approach that covers the agreement between service provider and consumer. Design by Contract does not necessarily mean that the contract precedes development. In many cases the details of the specification will evolve over multiple iterations as the requirements are understood. However it is a prerequisite that the specification is formalized before the services is published for operational use.
Service specification practices vary greatly. All services will have some form of specification, but many will comprise only the technical interface, that is clearly mandatory for service execution. Design by Contract infers a more rigorous form of specification and we use the term Rich Service Specification to denote a contract that comprehensively defines the required behavior and message schemas, providing all the information required by the service developer and the service consumer.
The RSS has real benefits:
In order to use a Service, the Service Consumer will of course want to know exactly what the service does. They will want to know what behaviour it offers, and what they have to do in order to use the Service. A Service Provisioner whose role it is to locate a suitable Service will need to be able to compare the available Services against a specification to see if it meets requirements. Or if they are commisioning a new Service (or implementation of) they will need to precisely detail the required behavior of that Service. Hence, the developer in the Service Providing organization who has to build an implementation of the Service also needs to know what requirements need to be meet.
A Service Specification is an implementation-neutral deliverable that contains all the information necessary to meet all these needs. The Service Specification facilitates exchange of consistent and precise instructions between different participants in the Service supply chain.
To address these needs, the Service Specification must provide a thorough description of what a service does, to avoid having to reveal how it is realized or deployed. The sections in the CBDI-SAE Rich Service Specification include:
At a more detailed level, the Service Specification details:
The Service Specification is expected to be developed iteratively across the service life cycle states:
The CBDI-SAE meta model for SOA shows a 1 to many relationship between a "notional" Service (e.g. the concept that is meaningful to the business) and the Service Specification. This allows for versions or variants. For example an organization may allow variants of the Service Specification in order to serve the different needs of different parts of the business. Notionally they are all the same service at a business level, and so the organization needs to trace the Service Specification variants all back to that same business service.
Also, an organization may wish to keep a copy of the specification that details their 'ideal' requirement, even though the provisioned service might make compromises to that, and hence has a different specification. But that doesn't require two different templates - one covering 'requirements' and another for 'operational' Services - rather it requires two separate but related instances.
They key thing is that participants are then using the relevant instance and understand its purpose with the consuming solution developer working from the service specification instance that reflects the provisioned, operational Service, and not on the instance that was a statement of ideal requirements.
Ideally, Service Specifications are not stand-alone documents, but entries in a Service Catalog that can maintain all these relationships, understands their current state(s), and ensures that their visibility is relevant to the role/task of the participant.
A PDF version of the CBDI-SAE Rich Service Specification Template is available for download. Everware-CBDI make the material freely available to the public under licence. Templates for various SAE deliverables are provided as Word documents. However, we do not recommend users to then complete and store instances of those documents using Word. Everware-CBDI provide a Specification Portal that stores the data in a structured manner and facilitates reuse of common specification components including rules and schema elements. The Portal integrates with modeling and schema management tools that serve the purposes of various stakeholders. ver a useful format in which to report on specifications.
Provides a SOA Deliverable template for the documentation of a rich service specification in SOA Projects. The Service Specification provides the definition of what a service does - in terms of behavior, information and nonfunctionals - regardless of how it is realized or deployed.
At the heart of the service concept is conformance with the principle of the "contract based" capability. Whilst many SOA principles will be optional depending upon context, the use of service contracts is likely to be required, because a well formed service is likely to be the primary enabler of the agile business. At the same time it is important to use a pragmatic level of specification detail that is appropriate to the context of use. Our practice research to date has focused on the Rich Service Specification and the Service Level Agreement. In this report we extend that guidance to cover evolution of specification artifacts across the full service life cycle, in an integrated way, to include all the involved parties.
This research note explores aspects of a reference model for service specification, outlining several important concepts.
Services are progressively becoming the de facto architecture for the enterprise. Whether a service is implemented as a REST API or SOAP Web Service, a specification of some sort is essential for the delivery and operational life cycle management. Casual observation tells us that service specification approaches in common use are highly variable. In our survey, conducted in October 2013 we asked architects, designers and project managers to tell us how they deliver and use service specifications. The results substantiate preconceptions to some extent, but also highlight some very interesting issues.
© Everware-CBDI Inc 1999-2016
Web design by Tribiq