Requirements

SOA - Requirements In order to efficiently use a SOA, the architecture must meet the following requirements: • Interoperability among different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication depends on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol. • Desire to create a federation of resources. Establish and maintain data flow to a Federated database system. This allows new functionality developed to reference a common business format for each data element.

Principles The following guiding principles define the ground rules for development, maintenance, and usage of the SOA: • reuse, granularity, modularity, compos ability, componentization and interoperability. • standards-compliance (both common and industry-specific). • services identification and categorization, provisioning and delivery, and monitoring and tracking. The first publicly published research of service-orientation from an industry perspective was provided by Thomas Erl of SOA Systems Inc. who defined eight specific service-orientation principles common to all primary SOA platforms. These principles were published in “Service-Oriented Architecture: Concepts, Technology, and Design”, on the www.soaprinciples.com research site, and in the September 2005 edition of the Web Services Journal.

Standardized Service Contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents. Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other. Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world. Service Reusability – Logic is divided into services with the intention of promoting reuse.

Service Autonomy – Services have control over the logic they encapsulate.

Service Statelessness - Services minimize resource consumption by deferring the management of state information when necessary

Service Discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.

Service Composability – Services are effective composition participants, regardless of the size and complexity of the composition. Some authors also include the following principles:

Service Optimization – All else equal, high-quality services are generally preferable to low-quality ones.

Service Relevance – Functionality is presented at a granularity recognized by the user as a meaningful service.

Service Encapsulation – Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.

Service Location Transparency – This refers to the ability of a service consumer to invoke a service regardless of its actual location in the network. This also recognizes the discoverability property (one of the core principle of SOA) and the right of a consumer to access the service. Often, the idea of service virtualization also relates to location transparency. This is where the consumer simply calls a logical service while a suitable SOA-enabling runtime infrastructure component, commonly a service bus, maps this logical service call to a physical service. The following references provide additional considerations for defining a SOA implementation: • SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc. • Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the services lifecycle and provides a detailed process for services management through the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best-practices, templates, comments on key SOA standards, and recommended links for more information. In addition, one might take the following factors into account when defining a SOA implementation: • Efficient use of system resources • Service maturity and performance • EAI (Enterprise Application Integration)