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
Implement a
standardized contract
Service Loose
Coupling
Minimize dependencies
Implement generic and
resusable logic and contract
Service Loose Coupling
Service Abstraction
Service
Abstraction
Standardized
Service
Contract
Minimize the availability
of meta information
Independent functional
boundary and runtime env.
Service
Reusability
Service
Autonomy
Service Reusability
Adaptive and state
management-free logic
Service Autonomy
Service Statelessness
Service
Composability
Maximize composability
Implement communicative
meta information
Service Discoverability
Service Composability
SERVICE
Service
Statelessness
Service
Discoverability
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 -> serviceoriented 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)
-
-
-
-
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
using 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>
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. GetOrderStatus() synonymous with
RetrieveStatisticsPerOrderMode(), so just be
consistent: GetOrderStatus(),
GetStatisticsPerOrderStatus()
*** Service Loose Coupling ***
• goal of this principle is to allow service to
develop and evolve with minimal impact on
each other
Service Loose
Coupling
-
-
-
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
•
•
•
•
•
•
•
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
underlying service logic
is coupled to the
service contract
core service logic
consumers are coupled
to the service contract
SC
service
consumers
service contract is
physically decoupled
Service Façade
-
-
-
-
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
[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 };
}
}
façade logic is coupled
to core logic
core service logic
façade logic is coupled
to contract
service
façade
logic
changes to the contract
impacts façade logic
core logic is decoupled
from contract and may
therefore not be affected
by the change
SC
Concurrent Contracts
• enables a service to have more than one service
contract in order to accommodate different
service consumers
service
façade
logic : A
SC: A
service
façade
logic : B
SC: B
core service logic
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
(1)
(2)
Service B
- Capability A
- Capability B
(3)
Service A
- Capability A
(4)
Service C
- Capability A
- Capability B
(5)
Service D
- Capability A
- Capability B
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