1. Service Oriented Architecture
A High Level Breakdown
for COMP 410 by Dennis Qian
Source: SOA with .NET & Windows Azure, Thomas Erl

2. 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

3. 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
Implement generic and
resusable logic and contract
Service Reusability
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

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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()

13. *** Service Loose Coupling ***
goal of this principle is to allow service to develop and evolve with minimal impact on each other

14. 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

15. 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

16. [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 var person = ServiceImplementation. person.address = null; return person; class ServiceImplementation public static person GetPersonById(int personId) return new person{ id = personId };
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

17. 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

18. 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

19. – identification of reusable 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

20. 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 B
Capability A
Capability B
Service C
Capability A
Capability B
Service D
Capability A
Capability B

21. 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)

22. 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

24. 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
“Stitching of software and hardware components together to deliver a defined Service”
involves saving state in a State Repository (yeah database)

25. 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)

26. Useful Sites www.whatissoa.com www.soaprinciples.com