1. Service Identification
Provide descriptive details of services identification attributes
[TABLE]Service identification table -- Additional information:
Service name: The service must have a fully distinguished name which uniquely identifies it within its given name space according to the service taxonomy naming approach.
Service version: Service version provides an extension to the service name such as 1.00, 2.32. Initial version of a service should be decided based on organizational policy for versioning.
Service location: Service location uniquely identifies the service in service provider's domain, major and or minor sub system.
Service contact: A service's contact is a person (or a reference to a specific role) that acts as a central point of contact for all matters relating to the service. The contact may not necessarily be the service owner since this may be a technical resource. The contact information will include the contact's name and contact details: e-mail address, phone number, etc.
Service owner: The ultimate owner of the service, this ownership should be associated with respect the service provider business sub system.
Service type: Services may be categorized with a service type based on service taxonomy approach. The service type may be used by consumers to help them quickly locate and/or understand a service. Service type is usually drawn from a hierarchical categorization system based on technical and business views of the services. Service may be categorized in taxonomy as Business services, Application services and Infrastructure services. A business service is composed of multiple application services and infrastructure services provide the supporting requirement of application services. Please see the service taxonomy specification for more details.
Service dependency: A service such as business se
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
rvice is composed of multiple services to assure the reusability and loose coupling principles of service oriented architecture. Service dependency provides a top down list of services that a given service depends upon during run time execution. Please see the service taxonomy specification for more details.
Service description: A human readable description of the service. It may include references to other documents.
2. Service Functional Requirements
Document the functional requirements.
[TABLE]Service functional requirements table - Additional information:
Functional objective: A concrete service provided through the service entity. A service entity's services can be implemented through different operations of the service. Each functional objective of a service has to be explicitly explained in the context of the service exposed and non-exposed functionalities.
Information model data objects: In order to meet the functional objective of a service, the application components of a service act on data objects provided as parts of the service information model. Each data object should have a unique owner associated with a namespace.
3. Service Change Log
Describe changes that are made to the service or reference change control documents.
[TABLE]4. Service Provider-Side Information
The provider side (along with the identification side) contains all of the information an actual or potential consumer of the service needs.
[TABLE]Service provider-side information table - Additional information:
Service interface: Service interface defines how to use service operations. The Service Interface should be named based upon the service taxonomy naming approach.
Service interface type: Each service interface should be associated with a type such as inbound (Import), outbound (Export), and abstract. Type defines the direction in which a given service moves the business data based on the associated information model. Type should be defined based on the business system own the service.
Service interface mode: Mode of an interface decides the mode in which service clients access the service operation via the interface. Mode can be synchronous or asynchronous.
Service operation: Operation is the entity of the service which fulfills the task on a transaction context. Service operation should be named based upon the service taxonomy naming approach.
Service operation type: Type of a service operation can be business oriented or management oriented. Technically business and management operations are the same except for the fact that management service is used in the management of services related activities.
Interface information model: Each service interface should be associated with an information model for request, response, and fault conditions of the exposed operation based on the type of interface.
Service behaviors: The behavior describes what a service operation does. For each service operation provide the behavior description in human readable format.
Behavior type: Type of a service operation is controlled by the characteristics of the operation.
If a given service has at least one stateful operation, the overall service behavior will be stateful.
If a given service has no stateful operations at all, the overall service behavior will be stateless.
Service events: Service events may or may not be part of a service specification. Some time service layer management framework should be capable to capture all major service events as part of the service run time policy. If there are consumer driven policies around the service events it should be part of the service specification.
Service policies: List all major service policies applicable to the business and run time aspects of the service here.
Policy type: A policy type of a service can be static or dynamic in nature.
Security Identification and Authentication: Verifying the identity of a service consumer, often as a prerequisite to allowing access to resources in a service or application infrastructure. Provide a human readable description of the service user identification and authentication requirement.
Authorization: The permission to use a service resource, granted, directly or indirectly, by a service provider. Provide a human readable description of the service authentication requirement.
Integrity: The property that data has not been altered in an unauthorized manner while in storage, during processing, or in transit. Provide a human readable description of the service data integrity requirement.
Non-repudiation: Assurance that the service consumer is provided with proof of delivery and the service provider is provided with proof of the sender's identity so neither can later deny having processed the information. Provide human readable details of the non repudiation security requirement of the service.
Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information. Provide human readable description of the confidentiality requirement of the service security.
Privacy: Restricting access to consumer or relying party information in accordance with Federal law and organization policy. Provide human readable description of the privacy requirement of the service security.
Note: Service security features explained here is the human readable interpretation of the security requirement explained in business functional analysis.
5. Service Dependency Information
The dependency section describes the services upon which this service depends to provide its service.
[TABLE] Service dependency information table - Additional information:
Dependent service: A service being used in a supporting role to fulfill the functionalities of the major service specified in the specification document.
Contract: A service level contract between a major service and supporting service.
Specification: Service specification of the supporting service.
Operations: Operations being used from supporting service in the context of major service.
Mapping specification: Specify the message mapping details for a service dependency in case services having different message layout and or format.
6. Service Assets
List the documents and other assets related to this service. These would typically be added into the Repository.
[TABLE]About the Author
Shaji Nair is a senior SOA solution architect with HP's consulting and integration practice. He can be reached at shaji.nair@hp.com.
