Service Oriented Architecture [SOA]

In simplified terms, service-oriented architecture is a collection of connected services that communicate with each other. This communication may be simply passing data, or involve two or more services coordinating an activity.

A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. Services are most likely connected using XML based 'web services'.

A customer, enter a service request message on a service provider website.

The service provider returns a response message to the customer.

Both the request and response connections are defined in a form that is understood to both the customer and service provider. How those connections are defined.

• Web Services are defined using Web Services Description Language [WSDL]
• WSDL uses XML tags to define the messages
• SOAP provides the envelope for sending messages, using HTTP

Web Services

Web services applications are accessible using programming such as SOAP (Simple Object Access Protocol) and REST;and use HTTP with XML for communication. Web services are ubiquitous technologies and any device capable of using these technologies is able to both host and consume Web services. There are a various web services tool-kits available, providing a low barrier to entry and easy software development.

Service Orientation [SO]

Service-orientation is widely accepted as a distinct design paradigm that supports the creation of service-oriented automation logic in the form of services. SO comprises a set of common design principles that realize specific service design characteristics in support of the strategic goals associated with service-oriented architecture (SOA) and service-oriented computing.

Service-orientation is defined differently by different vendor SOA platforms.

Paul Allen approaches SOA in terms of seven disciplines:

1. Transparency
2. Customer fit
3. Partner connectivity
4. Adaptation
5. Multi-channel capability
6. Optimization
7. One-stop experience

Whilst service-orientation principles have their roots in the object-orientation design, service-orientation will in part replace object-orientation as the de facto design paradigm.

Service Oriented Design [SOD]

Service-oriented design refers to a formal process for designing services for SOA. As an approach for designing solution logic for SOA, service-oriented design is synonymous with service-orientation. Service-orientation principles are commonly referred to as "SOA principles

Service Oriented Architecture [SOA]

SOA helps users build composite applications; applications that draw upon functionality from multiple sources within and beyond the enterprise to support horizontal business processes.

Service-oriented architecture relies on service-orientation as its fundamental design principle. It uses loosely coupled services to support business processes and users.  SOA is proposed by some as just another term for Web Services

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. SOA concepts can be applied to business, software and other types of producer/consumer systems.

BPM-generated apps can be used to build a more flexible user interface for SOA services. SOA concepts include:

• Architecture is not tied to a specific technology
• Is independent of any specific programming language
• independent of development technologies and platforms [Java, .NET etc]
• Services inter-operate based on a formal definition [contract]
• Supports integration and consolidation activities within complex enterprise systems
• Have highly inter-operable interfaces to help businesses respond more quickly and cost-effectively to changing market conditions

SOA Principles

The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:

• Reuse, granularity, modularity, composability, componentization, and interoperability
• Compliance to standards (both common and industry-specific)
• Services identification and categorization, provisioning and delivery, and monitoring and tracking

The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:

• Service Encapsulation
• Service Loose coupling - minimizes dependencies and only requires an awareness of each other
• Service contract - a communications agreement defined collectively by one or more service description documents
• Service abstraction - hides logic from the outside world
• Service reusability - logic is divided into services to promote reuse
• Service composability - collections of services can be coordinated and assembled to form composite services
• Service autonomy – services have control over the logic they encapsulate
• Service optimization
• Service discoverability – designed to be outwardly descriptive so that they can be found
  

SOA Contract

The modelling and design methodology for SOA applications is defined 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.

Service Contract

A service contract needs to have the following components:

Header

• Name - should indicate in general terms what it does
• Version - of this service contract
• Owner - person/team in charge of the service
• RACI - roles that are deemed Responsible, Accountable, Consulted, Informed.
• Type - of the service in terms of the layer in which it resides. Different implementations will have different service types. This may include:
  • Presentation
  • Process
  • Business
  • Data
  • Integration

Functional

• 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 an internal and external clients each with a different invocation means and interface, for example:

  - SOAP

  - REST

  - Events Triggers

Non-Functional

• 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
  

Back To Top