Service Oriented Architecture

What is SoA

SoA or Service Oriented Architecture is a term that has been used context with different purposes and it is very difficult to find a unique definition for it. With all the confusion around the term, one thing has remain unchanged i.e.  it provides a mechanism for breaking down large systems into units that perform specific functions and provides mechanisms that can be used to integrate these independent units to provide larger solutions.
The fundamental change that service oriented architecture brings around the concept of large systems can be defined as

• Independent units of logic (functionality) should exist autonomously
• Units conform to a set of principles so that they can be created and maintained independently
• They are standardized in a way that they can be integrated to provide bigger solutions
• These units of logic are called services

SoA and other paradigms

By definition, SoA sounds very similar to other distributed computing paradigms like client server technologies. This section compares SoA with other well known paradigm and salient differences betwen them. Following table compares SoA with Client Service Architecture.

SOA	Client Server Architecture
Presentation layer is detached from services themselves	Application logic resides in client software. Client needs to control user experience, back-end resources
Highly distributed processing, services themselves may be distributed over many servers	Client is responsible for most of the processing, 80/20 rule was used as a rule of thumb
Complex security model but provides flexibility	For simple scenario, implements a very easy security model
Also has high maintenance costs and requires powerful administration tools	Very high maintenance costs of maintaining client server applications

Following table compares SoA with Distributed Internet Achitecture.

SOA	Distributed Internet Architecture
Standardized interfaces, Self sufficient messages	All the logic exists in server side. Some very insignificant logic may exist in client. Proprietary interfaces in place
Message based communication, promotes creation of autonomous services	Can support stateful and stateless components, data exchange is primarily synchronous
Messages contain header blocks where security logic can be stored	Exclusive connection maintains context. In non-exclusive connections, user credentials have to be sent across each request
Higher administration costs	Simple to maintain, HTTP server needs to be built for scalability

Web Service Framework

There is a significant misconception in the practitioners of SoA that Web Services is SoA. Although Web Services is not SoA, in practical terms it relies very heavily on web services. Web Service framework is a collection of following.

• Standardized existence
• Consists of building blocks that are required for this to work, includes Web Services, Service Descriptions and messages
• A communication agreement, depends heavily on WSDL. Although REST and JSON are also used very frequently now a days.
• A messaging framework relies heavily on SOAP. REST is also used here.
• Service description and discovery framework, relies heavily on UDDI, although other mechanisms are also used

Service Roles

When using web services framework different entities perform different roles. In some sense these are different states that a service can enter with in a context. Some of the main roles are as follows.

• Service Provider
• Invocation of web services via an external source
• Provides a published service description offering information about its features and behavior
• Service Requester
  
• Web services invokes a service provider by sending a message
• Web services searches for and assesses the most suitable service provider by studying available service descriptions
• Intermediaries
• Passive intermediaries – responsible for routing messages to a subsequent location
• Does not modify the message
• Active intermediaries – Route the message but would process the message and may need to alter it
• Initial Senders
• These are service requestor entities that initiate the transmission of a message
• Ultimate receiver
• These are service providers that finally receive the message
• Service compositions
• These are compositions of multiple service to provide a service
• Each service that participates in service composition becomes service composition member
• Service compositions are typically governed by extensions defined in WS-* composition extensions e.g. WS-BPEL

Service Models

Service models provide a way to categorize the services based on the application logic.

• Business Service Model
• Most fundamental building block
• Represents corporate entity or information set
• Represents business process logic
• Act as service composition members
• Could correspond to Business service layer
• Utility Service Model
• Any web services that is designed for potential reuse can be classified a utility service
• These are used as
• Solution agnostic intermediary
• Service that promotes intrinsic interoperability
• Service with highest degree of autonomy
• Controller Service Model
• These services perform the task of assembly and coordination of service compositions
• These are used to
• Support autonomy in services
• Leverage reuse opportunity
• Support and implement principle of composability

Service Descriptions

Services descriptions are provided using service description documents Most commonly WSDL is used to write service description. A WSDL definition consists of following.

• Service endpoints -- the point of contact for service provider
• Establishes Structure of request messages
• Physical location of service
• Abstract Descriptions
• portType
• High level view of service interface
• WSDL 2.0 is renaming this to interface
• Operation
• Specific action performed by service
• Comparable to a public method with input and output parameters
• message
• A set of input and output messages are used with every operation
• Concrete Description
• Concrete description in WSDL file is used to connect abstract interface to physical transport protocol
• Binding
• Represents one possible transport technology that service can use to communicate – SOAP
• Port
• Physical address at which a service can be accessed with a specific protocol
• Being renamed to endpoint in WSDL 2.0
• Service
• Group of related endpoints

WSDL Basics

The definitions element is root or parent element of every WSDL document and houses all parts of service definitions. It also establishes namespaces being used. The types element is used to place XSD schema. It contains embedded and imported types. XSD complexType element is used to establish embedded types.

• The message and part elements
• For every message that a service is designed to receive or transmit, a message construct must be addded. The message contains one or more part child elements that are assigned a type. If all messages in a WSDL definition are assigned XSD(simple) types, a types element is not needed.
• The portType, interface and operation element
• portType defines a collection of operations
• Individual operations are defined using operation elementportType element is being renamed to interface in WSDL 2.0
• The input and output elements
• Input and output elements are part of operation elements . These are analogous to parameter passing in function calls.
• The binding element.
  
• This is the first element for the concrete portion of service definition. This element is used to bind the operations and portType defined with actual SOAP bindings
• The input and output element
• These elements are analogous to elements in abstract portion but establish protocol details to be used
• The service, port and endpoint elements
• The service element provides a physical address at which the service can be accessed
• It hosts the port elements that contains location information
• Port element is replaced with endpoint element in WSDL 2.0
• The import element
• WSDL definitions support a similar form of modularity as XSD schemas.
  
• The import element can be used to import parts of WSDL definitions as well as XSD schemas
  

SOAP Basics

The Envelope element represents the root of SOAP message structures. It contains a mandatory body element and an optional header construct. A SOAP message is composed of following sections

• Header
• The Header element is a key enabler of WS-* specification. Most of these specifications have added new header blocks. Header also has a mustUnderstand attribute that indicates that the receiver needs to process header before understanding body
  
• Body
• The structure and naming used to define this part of SOAP message relates to the style and use attributes in WSDL binding element
• Intermediaries, in general would use header information without touching body. In exceptional cases, if allowed they may read the body contents
• Fault
• Fault construct provides a readymade error response that is added inside the body construct
• Contains FaultCode, FaultString and detail elements
  

Message Exchange Patterns

Almost all the tasks in web services context require transmission of multiple messages. Message Exchange Patterns (MEPs) have been developed to provide a set of templates that provide a group of mapped out sequences for exchange of messages. Following are set of primitive MEPs defined as part of Web Services.

• Request Response – Synchronous communication
• Establishes a simple exchange in which a message is first transmitted from source to a destination
• Upon receiving the message, the destination responds with a message back to source
• Fire and Forget – Based on unidirectional transmission of messages from source to one or more destinations without expecting a response
• Single destination
• Multicast
• Broadcast

These simple MEPs are not enough and further complex MEPs are defined.

• Publish and Subscribe model – services involved with message exchange become publishers and subscribers
• WS-* specifications that incorporate this model are
• WS-BaseNotification
• WS-BrokeredNotification
• WS-Topics
• WS-Eventing

WSDL 1.1 provides four message exchange patterns

• Request Response operation – Upon receiving the message, the service must respond with a standard or fault message
• Solicit response operation – Upon submitting a message to a service requestor, service expects a standard response or fault message
• One way operation – The service expects a single message and is not obligated to respond
• Notification Operation – The service sends a message a expects no response

WSDL 2.0 extends MEP to support eight patterns

• In-out pattern
• Out-in pattern
• In-only pattern
• Out-only pattern
• Robust in-only and out-only pattern
• Same as in out with fault message because of transmission or processing error
• In-optional-out and out-optional-in pattern – delivery of one of the messages becomes optional

Coordination

Coordination establishes a framework to provide a means for context information in complex activities
to be managed, preserved, and/or updated and distributed to activity participants. Context is defined as something that is happening or executing has meaning during its lifetime and description of its meaning. WS-Coordination establishes a generic service based on coordinator service model
This service controls composition of three other services that each play a specific part in the management of context data

• Activation service – responsible for creation of new context and associating this to an activity
• Registration service – allows use of context information received from activation service
• Protocol-specific service – protocols supported
• Coordinator – controller service of composition

Coordination service composition is instantiated when an application service contacts the activation service via CreateCoordinationContext request message. The context data is created and passed back with ReturnContext message. Application service can invite other services to participate in coordination using context data
Any Web Service in possession of this context information can issue a registration request to registration service. Registration allows service to enlist in a coordination based on a protocol
The application service can request a coordination to be completed by issuing a completion request message to coordination service. The coordinator then issues its own completion message to all coordination  participants. Each participant responds with a completion acknowledgement message
WS-Coordination provides a coordinator based context management framework and introduces a layer of composition control to SOA. It standardizes the management and interchange of context information within a variety of key business protocols. Coordination also alleviates the need for services to retain state

Atomic Transactions

Atomic transactions implement the familiar commit and rollback features to enable cross-service transaction support

• Acronym ACID is used to represent traditional transaction
• Atomic – Either all changes or no changes suceed
• Consistent – Valid data models
• Isolated – Multiple transaction don’t interfere
• Durable – Changes made as part of transaction survive subsequent failures

WS-AtomicTransaction is a coordination type extension created for use with WS-Coordination context management framework. To participate in an atomic transaction, a service first receives a coordination context from activation service. It subsequently registers for available atomic transaction protocols. Following transaction protocols are provided

• Completion protocol – used to initiate commit or abort states of transaction
• Durable 2PC protocol – Services representing permanent data repositories should register for this
• Volatile 2PC protocol – Service managing non persistent data should register for this

Atomic transaction coordinator is tasked with the responsibility of deciding the outcome of  a transaction. It bases this decision on feedback it receives from all the transaction participants. Two phase process is used. During prepare phase, all participants are notified by the coordinator to prepare and issue a vote. The vote consists of commit or abort request. In second phase the coordinator enters a commit phase. If all votes are commit then a commit is issued. If any of the vote requests an abort then the transaction is aborted and changes are rolled back.

Business activities

Business activities govern long running complex service activities. The activity may take hours, days or weeks and during this period the activity may perform numerous tasks involving many participants. Business activities differ from protocol based atomic transactions in the way they deal with exceptions and nature of constraints introduced by protocol rules. Business activity protocols do not offer rollback capabilities. Business activities provide an optional compensation process that can be invoked when exception conditions occur.
WS-BusinessActivity is a coordination type designed to leverage WS-Coordination context management framework

• BusinessAgreementWithParticipantCompletion -- Allows participant to decide completion
• BusinessAgreementWithCoordinatorCompletion -- Allows coordinator to decide completion

Business activity coordinator and participants transition through series of states . Points of transitions identified by passing of special notification messages. Following are known business activity states

• Completion -- A participant could indicate that it has completed the processing by issuing Completed notification
• Participant moves from active to completed state
• Coordinator may respond with a close message to let the participant know that business activity is successfully completed
• Compensation -- If things do not go as planned, participants could enter compensation state where they attempt to perform some kind of exception handling
• Cancelled -- A cancelled stated could be entered which results in termination of any further processing except distribution of cancellation notifications
• Exit -- Participants can enter exit state by issuing an exit notification message

One of the main differences between business activities and atomic transactions is the fact that participating services are not required to remain participants for the duration of the activity. Participants may leave an activity after their contribution is performed.

Orchestration

Orchestration facilitates connecting of different processes/services without having to redevelop the solutions that originally automated the processes individually. Orchestration introduces workflow logic which is abstracted and more easily maintained. In SOA orchestrations themselves exist as services. A key industry specification that standardizes orchestration is web services business process execution language or WS-BPEL.

Basic and structured activities

WS-BPEL breaks down workflow logic into a series of predefined primitive activities

• Basic Activities
• Invoke
• Receive
• Reply
• Throw
• Wait
• Structured activities are created by assembling other activities using logics
• Sequence
• Switch
• While
• Flow
• Pick

Sequence aligns a group of related activities in a list that determines sequential execution order. Flow also contains group of related activities but activities can be executed concurrently. The flow does not finish till the time all the activities are completed. Links are used to establish formal dependencies between activities that are part of a flow. Links are also knows as synchronization dependencies.
WS-BPEL fully utilize WS-Coordination context management framework by incorporating the WS-BusinessActivity coordination type.

Choreography

Relationships and Channels

Every action within a choreography can be broken down into a series of message exchanges between two services. Each potential exchange between two roles in a choreography is defined as a relationship. Channels are used to define characteristics of messages exchange between two roles. Channel information can be passed around in a message. This fosters dynamic discovery and increases the number of potential participants within large-scale collaborative tasks.

Interactions and work units

Logic behind the message exchange in encapsulated within an interaction. Work units are related to interactions and impose rules and constraints that must be adhered to

Orchestrations and Choreographies

Although orchestrations and choreographies look very similar to each other there are significant differences among them.

• An orchestration expresses organization specific business workflow
• An organization controls the logic behind an orchestration even if it involves external businesses
• A choreography is not owned by a single entity, it acts as a community interchange pattern used for collaborative purposes by services from different provider entities

Addressing

In the context of SOAP message addressing enables everybody to know

• Where a message is coming from
• The address where it is supposed to go
• The specific address where it is supposed to be delivered
• Exception – where it should go if it can’t be delivered

WS-Addressing implements addressing features by providing two types of SOAP headers

• EndpointReference

• Address
• ReferenceProperties
• ReferenceParameters
• PortType
• ServiceName and PortName
• Policy

• Message information header elements
• MessageID
• RelatesTo
• ReplyTo
• From
• FaultTo
• To
• Action
  

Reliable Messaging

Reliable Messaging address the concerns of non-delivery and delivery out of sequence. Establishes a measure of quality assurance that can be applied to other activity management frameworks. It provides a framework that guarantees notification of success and failure of message. It guarantees that message sent with specific sequence related rules will arrive as intended. In case of out of sequence message delivery, failure condition would be generated. WS-ReliableMessaging introduces critical quality of service features for the guaranteed delivery and failure notification of SOAP message

Key elements

• Sequence
• MessageNumber
• LastMessage
• SequenceAcknowledgement
• AcknowledgementRange
• Nack
• AckRequested

Policy

Service properties are expressed individually by policy assertions. Each assertion could be required or optional. Policy assertions can be grouped into policy alternatives. Policies are used in coordination to restrict sharing of context data. Policies can be applied to any subject in orchestration and choreography. Policies are used in reliable messaging to implement fundamental features like delivery assurances
WS-Policy framework consists of following three specifications

• WS-Policy
• WS-PolicyAssertions
• WS-PolicyAttachments

Security

Core security specifications are

• WS-Security
• XML-Signature
• XML-Encryption
• Single-Sign On

Identification, Authentication, and Authorization

Identity is a claim regarding origin of a message. Authentication means that identity is established. Authorization provides the extent of access that authentication grants

Single Sign-on

Propagating the authentication and authorization to multiple service providers is a challenge. Single Sign-on address this issue. Three primary extensions that support SSO

• SAML – Security Assertion Markup Language
• .NET Passport
• XACML – XML Access Control Markup Language

Confidentiality and Integrity

Confidentiality is concerned with protecting the privacy of message contents. A message is considered to have remained confidential if no service or agent in its message path not authorized to do so viewed its contents. Integrity ensures that the message is not altered since its departure from the original sender. This guarantees that the state of the message has remained same since original transmission.

Transport Level security and message level security

SSL provides transport level security. A service intermediary taking possession of this message may still have capability to alter the message. In SOA message level security is a must

Encryption and digital signatures

Encryption provides features so that encryption can be applied to whole message or parts of it. Signatures provide non-repudiation which can prove that the message was sent by a specific requester and delivered to specific provider Is also legally binding.

Notification and Eventing

WS-I Profiles

Service Design Guidelines

• Apply naming standards

• Create naming standards and apply them to
• Service endpoint names
• Service operation names
• Message value

• Naming standards are organization specific
• Suggestions for naming
• Service candidates with high reuse potential should be stripped of any business process related naming characteristics
• Entity centric business services need to remain representative of their corresponding entity models
• Service operations for entity centric business service should be verb based and should not repeat service names
• Names should clearly communicate the nature of their individual functionality
• Suitable interface granularity
• XML based processing generally has performance challenges hence service design should be of optimum granularity
• Use alternatives like binary encoding extensions if needed
• Have alternative WSDL definitions for same services
• Have coarse grained interfaces to services designated as solution endpoints

SoA Platforms

J2EE

Slide 185

• Relevant specifications

• Java 2 Platform Enterprise Edition Specification
• Java API for XML based RPC
• Web Services for J2EE
• Architectural components
• JSP
• Struts
• Servlets
• EJBs
• Runtime
• EJB container
• Web container