Contract and Design

SOA Service contract and design Benefits Some 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 (classes) level. It can also simplify interconnection to – and usage of – existing IT (legacy) assets. SOA realizes its business and IT benefits by utilizing an analysis and design methodology when creating services. This methodology ensures that services remain consistent with the architectural vision and roadmap, and that they adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications. A mature rollout of SOA effectively defines the API of an organization. An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. The industry has never been exposed to this circumstance before. If an organization possesses appropriately defined test data, then a corresponding stub is built that reacts to the test data when a service is being built. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh are test deployments of full services. As each interface is fully documented with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validate that the test service operates according to its documentation, and finds gaps in documentation and test cases of all services within the environment. Managing the data state of idempotent services is the only complexity.

Criticisms of SOA SOA conflate with Web services. For example, SOA results in the addition of XML layers, introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC), applications could run slower and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI) and Data Distribution Service (DDS)) that do not depend on remote procedure calls or translation through XML. At the same time, emerging open-source XML parsing technologies (such as VTD-XML) and various XML-compatible binary formats promise to significantly improve SOA performance. State full services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall scalability of the service provider if the service-provider needs to retain the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult. IT system designs sometimes overlook the desirability of modifying systems readily. Many systems, including SOA-based systems, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace.

Design Basic Rules A service contract needs to have the following components: Header, Functional, Non-Functional Header component should include the following info: • Name – Name of the service. This should indicate in general terms what the service does, not just its definition • Version – The version of this service contract • Owner – The person/team in charge of the service • Responsibility assignment (RACI) o Responsible – The role/person/team responsible for the deliverables of this contract/service. All versions of the contract o Accountable – Ultimate Decision Maker in terms of this contract/service o Consulted – Whom one must consult before action is taken on this contract/service. This is two-way communication. These people have an impact on the decision or the execution of that decision. o Informed – Who must be informed that a decision or action is being taken. This is a one-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 component should include the following info: • Functional Requirement (from Requirements Document) – Indicates the functionality in specific bulleted items — what exactly this service accomplishes. The language should encourage 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 how to invoke the service. This includes the URL, interface, etc. There may be multiple invocation paths for the same service. One may have the same functionality for an internal and some external clients, each with different invocation means and interfaces. Examples: SOAP, REST, Events Triggers Non-Functional component should include the following info: • 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