Service Oriented Architecture

carenextSoftware and s/w Development

Nov 18, 2013 (3 years and 6 months ago)

53 views

Service Oriented Architecture

A High Level Breakdown


for COMP 410 by Dennis
Qian

Source: SOA with .NET & Windows Azure, Thomas
Erl

What is Service
-
Oriented Computing?


New generation of distributed computing
platform


Has its own design paradigms, principles,
patterns, models, etc.


Creation of solution logic units individually
shaped so that they can be
collectively

and
repeatedly

utilized

Eight Design Principles of
service
-
orientation
paradigm


Standardized Service Contract


Service Loose Coupling


Service Abstraction


Service Reusability


Service Autonomy


Service Statelessness


Service Discoverability


Service
Composability

Service Loose
Coupling

Service
Abstraction

Service
Composability

Standardized
Service
Contract

Service
Reusability

Service
Autonomy

Service
Statelessness

Service
Discoverability

SERVICE

Implement a

standardized contract

Minimize dependencies

Implement generic and

resusable

logic and contract

Minimize the availability

of meta information

Independent functional

boundary and runtime
env
.

Adaptive and state

management
-
free logic

Maximize
composability

Implement communicative

m
eta information

A Service


Container of capabilities associated with a
common purpose


Neutral to technology platform


Component


part of a distributed system


Web Service


XML Schema, confusing shit

Service Models


Service model


classification indicating type of
service based on its logic


Task Service


non
-
agnostic so general single
-
purpose,
parent business process logic, usually has logic to
spawn other services


Entity Service


reusable, agnostic, associates with
one or more related
business entities


Utility Service


reusable, agnostic, low
-
level
technology
-
centric functions, not derived from
business specifications, notification/logging/security

Distributed Computing
--
> Service
Oriented Computing


Computing has moved from procedural
programming
-
> object
-
oriented
programming, and then from OOP
-
> service
-
oriented programming


Distributed architecture met evolving
demands that client
-
server architecture was
unable to handle, n
-
tier, service
-
oriented arch.
extends on distributive architecture


Service Contracts

(basically interfaces for our services)


u
sing System;

using
System.Service

Model;

namespace
HelloWorld

{


[
ServiceContract
]


public interface
IGreetings



{


[
OperationContract
]



string Greet1();



}

}


-----


[
MessageContract
]

public class
ContractMessage

{



[
MessageHeader
]



public
MsgHeaer

msgHeader
;



[
MessageBody
]



public
MsgBody

msgBody


-----


<
system.serviceModel
>


<services>



<service name=“
AccountService
”>



<endpoint name=“EndPoint1”



address=“
net.tcp
://localhost:1234”



binding=“
netTcpBinding




contract=“
Iaccount
” />



</service>


</services>

</
system.serviceModel
>

-
Corresponds to
ServiceContract

attribute

-
Composed of an interface contract
and a service
endoint

-
Interface Contract



subset of
service contract comprised of the
operation contract, data contract,
and message contract

-
Operation Contract

-

method or
capability as part of interface
contract

-
Data Contract



means of
expressing data models
ie
, XML
schemas are data contracts

-
Message Contract



pretty much
message protocol

-
Service Endpoint



cormprised

of
address, binding, and contract
parts

Contract
-
First approach


Create or Reuse Data Contract


Create Message Contract


Create Interface Contract


allows for standardized service contracts
(possibly on industry standards etc.)


Canonical Schemas // XML Schemas //
establishes structure and validation rules, can
also define data models

Data Model Transformation


avoid this shit at run time, which is why we
used Standardized Service Contract principle


example
: services encapsulating legacy
systems inevitably need to transform data
between legacy data models and standardized
data models


Service B : schema1
-
> transform schema
-
>
schema2 : Service A

Data Model Transformation


three ways to apply DMT


object
-
to
-
object


XML message serialized into
object, translated into another object, serialized
back into XML


LINQ
-
XML


irrelevant


XSLT Transformation
-

irrevenat

Canonical Protocol


use the same communication protocol within
a
service inventory

boundary (like TCP for all
our module
comms
)


Dual Protocol



easy because we can just add
additional endpoints, allows for
primary/secondary protocols say to optimize
for performance issues

Canonical Expression


obvious but worth mentioning


have uniform naming conventions when it
comes to service contract definition


ie
.
Get
OrderStatus
()
synonymous

with
Retrieve
StatisticsPerOrderMode
(), so just be
consistent
:
Get
OrderStatus
(),
Get
StatisticsPerOrderStatus
()

*** Service Loose Coupling ***


goal of this principle is to
allow service to
develop and evolve with minimal impact on
each other










Service Loose
Coupling


logic
-
to
-
contract coupling



internal service logic
to service contract,
positive
, preserves contract’s
independence from implementation


contract
-
to
-
logic coupling


opposite ^,
negative
,
because changes to logic impact service contract,
and consequently also impact service consumers
who depend on contract


contract
-
to
-
technology coupling



similar ^,
negative
, forces service consumers to bind to
platform
-
specific technology protocol


contract
-
to
-
implementation coupling


negative
,
directly expressing characteristics of
implementation within the contract


contract
-
to
-
functional coupling


negative
,
occurs when general logic is designed with a
particular consumer in mind, contract can
become dependent on underlying functionality


consumer
-
to
-
implementation coupling


negative
, consumer bypasses contract to direct
access implementation


consumer
-
to
-
contract coupling


positive
,
consumers have limited access to the service
contract

-
goal of this principle is to
allow service to develop and
evolve with minimal impact
on each other

-
determines how the contract
is architecturally positioned

-
advocates reducing
dependencies between
service consumers and the
service contract, as well as
b/w the service contract and
the underlying service
implementation

-
positive and negative types of
coupling

core service logic

service

consumers

SC

underlying service logic

is coupled to the

service contract

consumers are coupled

to the service contract

service contract is

physically decoupled

Service Façade


[Service Contract]

interface
IPersonService

{



[
OperationContract
]



person
GetPerson
(
int

personId
);

}


//façade1

class
PersonService
:
IPersonService

{



public person
GetPerson
(
int

personId
)



{



return
ServiceImplementation
.



GetPersonById
(
personId
);



}

}


//facade2

class
SimplePersonService

:
IPersonService

{



public person
GetPerson
(
int

personId
)



{



var

person =
ServiceImplementation
.



GetPersonById
(
personId
);



person.address

= null;



return person;



}

}


class
ServiceImplementation

{



public static person
GetPersonById
(
int

personId
)


{



return new person{ id =
personId

};


}

}

-
when pursuing
logic
-
to
-
contract
coupling, additional coupling
flexibility can be built into the
service architecture by
establishing
additional layers of
implementation logic

-
advocates the positioning of a
façade components between the
contract and core service logic

-
protects the core service logic
from changes to the contract, or
concurrent contracts

-
typically contains code that:

-
chooses which methods or
functions to call in the core
implementation

-
compensates for changes in
logic to retain coupling

-
allows logic to remain
physically separate and
stable should contract
change

core service logic

service
façade
logic

SC

façade logic is coupled

to core logic

façade logic is coupled

to contract

changes to the contract

impacts façade logic

core logic is decoupled

from contract and may

therefore not be affected

by the change

Concurrent Contracts


enables a service to have more than one service
contract in order to accommodate different
service consumers

core service logic

service
façade
logic : A

SC: A

service
façade
logic : B

SC: B

Service Reusability



identification of reusable logic



Separation of Concerns


Functional Decomposition


Service Encapsulation


after above, leads to
below


Agnostic Context, single/multi
-
purpose logic


Agnostic Capabilities

Service Composition


Aggregate of services composed to
automate a particular task


common objective among all SOA
design principles

Service A

-

Capability A

Service B

-
Capability A

-
Capability B

Service C

-
Capability A

-
Capability B

Service D

-
Capability A

-
Capability B

(1)

(2)

(3)

(4)

(5)

Composition Roles


composition controller



service with capability that is
executing the parent composition logic required to compose
capabilities within other services (CP much?)


composition member



service that participates in a service
composition by being composed by another service
(FE/Mixers)


composition initiator



program that initiates a service
composition by invoking the composition controller, may or
may not exist as a service (control panel :D)


composition sub
-
controller


variation of the composition
controller role that is assumed by a service carrying out
nested composition logic, within a capability that is
composing one or more other service capabilities while itself
also being composed (Mixer roles and mixer trees)

Service Layers


based on a fundamental separation of
agnostic and non
-
agnostic service logic


end up with a
task service
layer, followed by
agnostic service layers

Orchestration


book doesn’t explain it that well, but it’s basically
what were doing when we try to construct our
cloud tree/graph/chains in an automated way


http://en.wikipedia.org/wiki/Orchestration_%28c
omputing%29


“Stitching of software and hardware components
together to deliver a defined Service”


involves saving state in a State Repository (yeah
database)

Topics Worth Exploring


Service Bus


basically a big messenger utility to
establish
comms

between services


eventing


service
remoting


tunneling


message buffers


service registry


Use of caches


could eliminate some processing


Access Control and cloud security
(marketability/extensibility factor)

Useful Sites


www.whatissoa.com


www.soaprinciples.com


www.soapatterns.com


www.soa
-
manifesto.com