SOA Service-oriented design and development

SOA Service-oriented design and development

The modelling and design methodology for Service Oriented Architecture SOA applications has become known by the terms service-oriented analysis and design and SOAD [8]. SOAD is a design methodology for developing highly-agile systems in a consumer/producer model that abstracts implementation from process, such that a service-provider can be modified or changed without affecting the consumer.

Service contract

A service contract needs to have the following components:

Header
Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
Version - The version of this service contract
Owner - The person/team in charge of the service
RACI
Responsible - The role the person/team is responsible for the deliverables of this contract/service. All versions of the contract
Accountable - Ultimate Decision Maker in terms of this contract/service
Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
Informed - Who must be informed that a decision or action is being taken. This is a 1-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
Type - This is the type of the service to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
Presentation
Process
Business
Data
Integration
Functional
Functional Requirement (From Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows test cases to prove the functionality is accomplished.
Service Operations - Methods, actions etc. Must be defined in terms of what part of the Functionality it provides.
Invocation - Indicates the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for an internal and external clients each with a different invocation means and interface. Examples:
SOAP
REST
Events Triggers
Non-Functional
Security Constraints - Defines who can execute this service in terms of roles or individual partners, etc. and which invocation mechanism they can invoke.
Quality of Service - Determines the allowable failure rate
Transactional - Is this capable of acting as part of a larger transaction and if so, how do we control that?
Service Level Agreement - Determines the amount of latency the service is allowed to have to perform its actions
Semantics - Dictates or defines the meaning of terms used in the description and interfaces of the service
Process - Describes the process, if any, of the contracted service

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture
Home: SOA Service Oriented Architecture