Service (systems architecture)
In the context of software architecture, service-orientation and service-oriented architecture, the term service refers to a software functionality or a set of software functionalities (such as the retrieval of specified information or the execution of a set of operations) that can be reused by different clients for different purposes, together with the policies that should control its usage (based on the identity of the client requesting the service, for example).
OASIS defines service as "a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description." 
A business analyst, domain expert, and/or enterprise architecture team will develop the organization's service model first by defining the top level business functions. Once the business functions are defined, they are further partitioned and refined into services that represent the processes and activities needed to manage the assets of the organization in their various states. One example is the separation of the business function "Manage Orders" into services such as "Create Order," "Fulfill Order," "Ship Order," "Invoice Order" and "Cancel/Update Order." These business functions have to have a granularity that is adequate in the given project and domain context.
Many analysis and design methods can be used for service engineering, both general purpose ones such as OpenUP and Domain-Driven Design as well as those discussed under Service-oriented modeling. An early call for service-oriented analysis and design methods and a compilation of building blocks of such methods was published in July 2004 
A service has a description or specification. This description consists of:
- An explicit and detailed narrative definition of service functionaly and invocation semantics supported by a platform-independent, self-describing service contract. The narrative definition can be augmented by machine-readable semantic specification about the service that facilitates service mediation and consistency checking.
- A set of quality-of-service indicators that specify service level objectives regarding performance and availability (when and how should members of the organization be able to perform the function?), duration (how long should it take to perform the function?), rate (how often will the function be performed over a period of time?), etc.
- A link to the organization's information model showing what information the service owns (creates, reads, updates, and deletes) and which information it references that is owned by other services.
Web services and RESTful HTTP resources provide two way of implementing the automated aspects of a given business or technical service; more implementation options are listed on the service-oriented architecture page.
- OASIS Reference Model for Service Oriented Architecture 1.0
- Zimmermann, O., Krogdahl, P., Gee, C., Elements of Service-Oriented Analysis and Design, IBM developerWorks Web services zone, June 2004
- Giuseppe DeCandia; Deniz Hastorun; Madan Jampani; Gunavardhan Kakulapati; Avinash Lakshman; Alex Pilchin; Swaminathan Sivasubramanian; Peter Vosshall; Werner Vogels. "Dynamo: Amazon's Highly Available Key-value Store: 2. BACKGROUND" (PDF). All Things Distributed: http://www.allthingsdistributed.com/. Retrieved 2011-03-17.
Some of these services are stateless (i.e., services which aggregate responses from other services) and some are stateful (i.e., a service that generates its response by executing business logic on its state stored in persistent store).External link in