Service Oriented ArchitectureAn IntroductionArnon Rotem-Gal-OzBiometrics Line Development Manager

What is Software Architecture

What is Architecture Formal DefinitionIEEE 1471-2000 Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolutionIEEE 1471-2000

collection of the fundamental decisions about a software product/solution designed to meet the projects quality attributes

Includes the main components, their main attributes, and their collaboration

expressed in several levels of abstraction (depending on the project's size).Architecture is communicated from multiple viewpointsWhat is Software Architecture

Architecture is EarlyArchitecture represents the set of earliest design decisionsHardest to changeMost critical to get right

Architecture is the first design artifact where a systems quality attributes are addressed

Why Architecture?Architecture serves as the blueprint for the system but also the project:Team structureDocumentation organizationWork breakdown structureScheduling, planning, budgetingUnit testing, integrationArchitecture establishes the communication and coordination mechanisms among components

Quality Attributes

How ArchitectureArchitectureQuality AttributesTechnologyPatterns & Anti-patternsPrinciplesCommunity experienceStakeholdersArchitectConstraints

What is a Service (1)Merriam-WebsterA facility supplying some public demand the work performed by one that serves HELP, USE, BENEFIT

What is a Service (2)In economics and marketing, a service is the non-material equivalent of a good. Service provision has been defined as an economic activity that does not result in ownership, and this is what differentiates it from providing physical goods.It is claimed to be a process that creates benefits by facilitating either a change in customers, a change in their physical possessions, or a change in their intangible assets. en.wikipedia.org/wiki/Service

What is a service (3)A Windows Service?RPC Locator, EventLog, DHCP Client,

Software Service?Distribution Service, Alert ServiceSecurity Service, Log Service

Business Service?Common Operational Picture, NavigationAccounts Receivable, Customers

SOA isnt a solution to world hunger

Nor is it: A specific Technology

The Ultimate answer to reuse

A New name for EAI

A New way to do RPC

ASBBLTHDLAFTTGIFRYDRWSWGQYDDLYBSTWIUASBZISXOICUIRMODLYXPSKYFKFCWHRJIAGEXFQAVUHHCOWKDECPSKDMFPWCPDKEAJTBig SOAAnalyze the business

ASBBLTHDLAFTTGIFRYDRWSWGQYDDLYBSTWIUASBZISXOICUIRMODLYXPSKYFKFCWHRJIAGEXFQAVUHHCOWKDECPSKDMFPWCPDKEAJTBig SOA Identify Business AreasCOPNavigationProtectorsAlerts

Big SOAMap to software"Network"

Little SOAArchitectural Style

For building distributed systems

Loosely coupled components

Our focus from here onward

ServicedescribesEnd PointExposesMessagesSends/ReceivesContractsBinds toService ConsumerimplementsPolicygoverned bySends/ReceivesAdheres toComponentRelationKeyUnderstandsServes

Services and SystemsA service is a program you interact with via message exchanges

A system is a set of deployed services cooperating in a given task

A Service edge is a natural boundaryWarning: Remoting and other RPCs trick us into thinking that there is no substantial difference between a local and a remote object. In fact, they hide the presence of the network.

Services are Autonomous

X

The fact that I can, doesnt mean I will.Policies

Policy IllustratedSeller Service

Runtime contractRuntime Contract 1. Use X.509 Cert for AuthN2. Use UTF-8, SOAP 1.2Policy 1. Supports X.509 Cert or Kerberos ST for AuthN2. Supports UTF-8, UTF-16, SOAP 1.2, 1.1Adopted from Clemens VastersDesign time Contract 1. Youll send a PO2. Ill send a confirmation

Endpoint

Its all about the Message, baby!

Messagestravel inno mans land!

Is he Idempotent?

MessagesGetRetransmitted

MessagesArriveMore thanonce

Idempotence

Idempotent Means Its OK to Arrive Multiple TimesAs Long as the Request Is Processed at Least Once, the Correct Stuff OccursIn Todays Internet, You Must Design Your Requests to Be IdempotentNot IdempotentBaking a Cake Starting from IngredientsNaturally IdempotentSweeping the FloorNaturally IdempotentRead Record XIdempotentIf Havent Yet DoneWithdrawal #XYZ for $1 Billion, Then Withdraw $1 Billion and Label as #XYZNot IdempotentWithdrawing $1 BillionIdempotentBaking a CakeStarting from the Shopping List (If Money Doesnt Matter)Pat Helland

Message Exchange Patterns

Request/ReplyRequest/ReactionVS

Decoupled Invocation Pattern

ServiceContract

Keep Data and state private

Big SOA is about business alignment

Little SOA is an Architectural StyleAutonomous Coarse Grained ComponentsMessage based InteractionsRun-Time configuration

Whats nextSOA Structural PatternsSOA Interaction PatternsUI Interaction PatternsService Composition PatternsContract Anti-patternsService Anti-patternsSOA Performance Anti-Patterns

2003 PSS Global Summit*2003 PSS Global Summit*2003 PSS Global Summit*Emphasize that the rationale for the architectural decisions is very important. 2003 PSS Global Summit*Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attributes (i.e. requirements). The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size).If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders.

Every system has an architecture, even if it is not formally speced out.

A Solution to world hungerNot a solution for everythingJust another tool in the toolset

A specific TechnologyMost notably SOA Web Services

Will Not make all code reusable

A New name for EAI Though well established contracts can help that too

A New way to do RPC

2003 PSS Global Summit*2003 PSS Global Summit*2003 PSS Global Summit*Business Alignment Cant stress that enough

Reduced assumptions (loose coupling)Builds on ideas from component software, distributed objects, and MOM

BPM

All the stuff enterprise architects do2003 PSS Global Summit*A service is a program you interact with via message exchangesServices are built to lastEncompass a business perspectiveStability and robustness are criticalA system is a set of deployed services cooperating in a given taskSystems are built to changeAdapt to new services after deployment

2003 PSS Global Summit*Each Service interaction is a boundary crossingDont cross it with transactions / exceptions etc.Crossing service boundaries may have costsService Orientation helps makes interaction formal, intentional, and explicitService boundary is a trust boundary !

Respect my Boundaries

(Adopted from Alex Weinert, Clemens Vasters)

2003 PSS Global Summit*Autonomous services can mean many things. One explanation Ive heard was the autonomous means that the teams working on different teams can be autonomous. While, this is a nice feature to have, a much more valuable (as in business value) definition is that the services are as self sufficient as possible. For example a imagine a journal subscription agency which needs to create a proposal for a client. The proposal service needs among other things, to produce a pro forma invoice in order to do that it must get the customers discount rate and the customers discount rate as well as the publishers discount rates (to check if the proposal is profitable) see the flow in figure 2.X below . If the proposal service is not autonomous it has to wait for two other services and while the customer service is local the publishers discount might be a remote one (on the publishers system) what happens to our proposal service if the publishers system is not on-line?

2003 PSS Global Summit*Service compatibility is determined based on policy Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy. Every service advertises its capabilities and requirements in the form of a machine-readable policy expression. Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. Policy assertions are identified by a stable and globally unique name whose meaning is consistent in time and space no matter which service the assertion is applied to. Policy assertions may also have parameters that qualify the exact interpretation of the assertion. Individual policy assertions are opaque to the system at large, which enables implementations to apply simple propositional logic to determine service compatibility.

A Policy is a set of assertions made aboutSecuritymessages behaviorlevel of servicelimited by the actual service capabilitiesPolicy-sets are attached, embedded or otherwise associated with contractsPolicy specifies a run-time dynamic, negotiable configuration information for a contract implementation.

2003 PSS Global Summit*2003 PSS Global Summit*Took Clemens example but Reversed contract direction The is owned by the service provider not the consumeraddress, a URI, a specific place where the service can be found. A specific contract can be exposed at a specific endpoint.

2003 PSS Global Summit*Services Revolve Around MessagesServices Are Black BoxesMessages go in and outThe Rest Is an Implementation Detail!

2003 PSS Global Summit*Between Services is SpecialMessages Are Sent and Float Around BetweenSpecial Care Is Needed to Understand ThemCan Be Confusion About Interpreting Them

Many Kinds of Message transportsEmail, IP, TCP/IP, HTTP, Web-service, MSMQ, MQ-Series, and moreMany Kinds of Message structuresXML, Binary, whatever

May be OK to Have Some Message LossIf messages are idempotentOther option Reliable Messaging

2003 PSS Global Summit*2003 PSS Global Summit*One WayIncoming OutgoingBroadcastPublish (as in publish/subscribe)To single recipient DuplexTwo one-waysRequest/ReplyRequest/Reaction

2003 PSS Global Summit*Messages & Formats Message Exchange PatternsWhere is a service located (Address)Protocol & content format (Binding)

2003 PSS Global Summit*Service Data is private Keep DB privateKeep transactions privateKeep exceptions privateDont share classes or other internal data structures

Dont share too much or youll lose autonomy (or tempt others to lose it)

2003 PSS Global Summit*Services interactions are message drivenServices should be Loosely coupledEdges should provide location transparencyBusiness logic and edge are separate layersScale inside the serviceYou can use workflows for long-running interactions again - inside the service

2003 PSS Global Summit*