Service oriented architecture l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

Service Oriented Architecture PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Service Oriented Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Service oriented architecture l.jpg

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 l.jpg

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 l.jpg

Eight Design Principles of service-orientation paradigm

Implement a

standardized contract

Standardized Service Contract

Standardized Service Contract

Service Loose Coupling

Service Abstraction

Service Reusability

Service Autonomy

Service Statelessness

Service Discoverability

Service Composability

Service Loose Coupling

Minimize dependencies

Service Reusability

Implement generic and

resusable logic and contract

Minimize the availability

of meta information

Service Abstraction

Independent functional

boundary and runtime env.

Service Autonomy

Adaptive and state

management-free logic

Service Statelessness

Service Composability

Maximize composability

Implement communicative

meta information

Service Discoverability

SERVICE


A service l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

Service Contracts(basically interfaces for our services)

using System;

using System.Service Model;

namespace HelloWorld

{

[ServiceContract]

public interface IGreetings

{

[OperationContract]

string Greet1();

}

}

-----

[MessageContract]

public class ContractMessage {

[MessageHeader]

public MsgHeaermsgHeader;

[MessageBody]

public MsgBodymsgBody

-----

<system.serviceModel>

<services>

<service name=“AccountService”>

<endpoint name=“EndPoint1”

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

binding=“netTcpBinding”

contract=“Iaccount” />

</service>

</services>

</system.serviceModel>

Corresponds to ServiceContractattribute

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 l.jpg

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 l.jpg

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 transformation10 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

*** Service Loose Coupling ***

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


Service loose coupling14 l.jpg

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


Slide15 l.jpg

underlying service logic

is coupled to the

service contract

consumers are coupled

to the service contract

SC

core service logic

service

consumers

service contract is

physically decoupled


Service fa ade l.jpg

Service Façade

[Service Contract]

interface IPersonService

{

[OperationContract]

person GetPerson(intpersonId);

}

//façade1

class PersonService: IPersonService

{

public person GetPerson(intpersonId)

{

return ServiceImplementation.

GetPersonById(personId);

}

}

//facade2

class SimplePersonService: IPersonService

{

public person GetPerson(intpersonId)

{

var person = ServiceImplementation.

GetPersonById(personId);

person.address= null;

return person;

}

}

class ServiceImplementation

{

public static person GetPersonById(intpersonId)

{

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


Slide17 l.jpg

façade logic is coupled

to core logic

façade logic is coupled

to contract

SC

core service logic

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


Concurrent contracts l.jpg

Concurrent Contracts

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

SC: A

service façade logic : A

core service logic

SC: B

service façade logic : B


Slide19 l.jpg

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 l.jpg

Service Composition

Service A

- Capability A

  • Aggregate of services composed to automate a particular task

  • common objective among all SOA design principles

(1)

(2)

(3)

(4)

(5)

  • Service D

  • Capability A

  • Capability B

  • Service B

  • Capability A

  • Capability B

  • Service C

  • Capability A

  • Capability B


Composition roles l.jpg

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 l.jpg

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 l.jpg

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_%28computing%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 l.jpg

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 l.jpg

Useful Sites

  • www.whatissoa.com

  • www.soaprinciples.com

  • www.soapatterns.com

  • www.soa-manifesto.com


  • Login