There is no widely-agreed upon definition of Service-oriented architecture other than its literal translation that it is an architecture that relies on service-orientation as its fundamental design principle. Service-orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation . These concepts can be applied to business, software and other types of producer/consumer systems.
The main drivers for SOA adoption are that it links computational resources and promotes their reuse. Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro level (objects).
Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including:
REST- Representational state transfer
RPC- Remote Procedure Call
DCOM- Distributed Component Object Model
CORBA- Common Object Request Broker Architecture
SOA can be implemented using one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.
The modeling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SOAD. 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.
Responsible - The role is the person/team 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.
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 internal and external clients each with a different invocation means and interface. Examples:
The Automotive Work Order domain describes the process by which an automotive maintenance company manages its customer operations. We will use this domain problem to illustrate the issues of SOAD.
A work order represents an agreement between the auto service company and a customer to perform a set of scheduled or emergency maintenance activities such as a scheduled 50,000-mile service, a brake pad or tire replacement, or an oil change.
If you constructed Work Order as an OO application, these software objects would contain all the necessary business rules and would understand the business processes that should be followed.
However, there are some practical disadvantages to this approach:
Many of the steps involve interfacing with existing legacy systems and databases such as billing, scheduling, and inventory systems, which were probably not designed adhering to the OO paradigm (applying an adapter or mediator pattern helps in such situations).
In order to make the system as flexible as possible, it would be helpful to have some of the rules externalized so that the processes or workflow can be modified without changes to the code. For example, rules like:
A standard 24,000-mile service includes four liters of oil. Additional charges for oil should only be made if more than four liters are used, or if the customer requests a premium grade oil (such as a synthetic oil).
There are a set of industry-standard labor estimates for common automotive maintenance activities available through a legacy application. The customer should be billed the standard labor costs unless the mechanic exceeds that estimate by more than X% and reports a valid reason for the difference.
The customer should be contacted for confirmation if the estimate is exceeded by more than Y%.
SOAD provides an excellent solution to these issues. Since it groups services on the basis of related behavior, rather than encapsulated (behavior plus data), the set of services will be subtly different from a business object model.
For example, you would probably group Work Order and Work Order Item together, into Work Order Services, and create Scheduling, Catalog, and Inventory services. Also, because there are no services instances, there are no equivalents to relationships between services.