3. What is ArchitectureWhat is Architecture
Formal DefinitionFormal Definition
IEEE 1471-2000IEEE 1471-2000
Software architecture is theSoftware architecture is the fundamentalfundamental
organizationorganization of a system, embodied in itsof a system, embodied in its
componentscomponents, their, their relationshipsrelationships to each other andto each other and
the environment, and thethe environment, and the principlesprinciples governing itsgoverning its
design and evolutiondesign and evolution
IEEE 1471-2000IEEE 1471-2000
4. collection of the fundamental decisions about a softwarecollection of the fundamental decisions about a software
product/solution designed to meet the project‘s qualityproduct/solution designed to meet the project‘s quality
attributesattributes
Includes the main components, their main attributes, and theirIncludes the main components, their main attributes, and their
collaborationcollaboration
expressed in several levels of abstraction (depending on theexpressed in several levels of abstraction (depending on the
project's size).project's size).
Architecture is communicated from multiple viewpointsArchitecture is communicated from multiple viewpoints
What is Software ArchitectureWhat is Software Architecture
7. What is a Service (1)What is a Service (1)
Merriam-WebsterMerriam-Webster
A facility supplying some public demandA facility supplying some public demand
the work performed by one that serves HELP, USE,the work performed by one that serves HELP, USE,
BENEFITBENEFIT
HMM..HMM..
8. What is a Service (2)What is a Service (2)
In economics and marketing, a service is the non-In economics and marketing, a service is the non-
material equivalent of a good. Service provision hasmaterial equivalent of a good. Service provision has
been defined as an economic activity that does notbeen defined as an economic activity that does not
result in ownership, and this is what differentiates itresult in ownership, and this is what differentiates it
from providing physical goods.from providing physical goods.
It is claimed to be aIt is claimed to be a process that creates benefitsprocess that creates benefits byby
facilitating either a change in customers, a changefacilitating either a change in customers, a change
in their physical possessions, or a change in theirin their physical possessions, or a change in their
intangible assets.intangible assets.
en.wikipedia.org/wiki/Serviceen.wikipedia.org/wiki/Service
9. What is a service (3)What is a service (3)
A Windows Service?A Windows Service?
RPC Locator, EventLog, DHCP Client,RPC Locator, EventLog, DHCP Client,
Software Service?Software Service?
Distribution Service, Alert ServiceDistribution Service, Alert Service
Security Service, Log ServiceSecurity Service, Log Service
Business Service?Business Service?
Common Operational Picture, NavigationCommon Operational Picture, Navigation
Accounts Receivable, CustomersAccounts Receivable, Customers
10. SOA isn’t a solution toSOA isn’t a solution to
world hungerworld hunger
Nor is it:Nor is it:
A specific TechnologyA specific Technology
The Ultimate answer to reuseThe Ultimate answer to reuse
AA New name for EAINew name for EAI
A New way to do RPCA New way to do RPC
11. ASBASB BLTBLT
HDLHDL
AFTAFT TGITGI FRYFRY
DRWDRW
SWGSWG
QYDQYD DLYDLY
BSTBST
WIUWIU
ASBASB
ZISZISXOIXOI CUICUI
RMORMO
DLYDLY
XPSXPS
KYFKYF
KFCKFC
WHRWHR
JIAJIA GEXGEX
FQAFQAVUHVUH
HCOHCO
WKDWKD
ECPECP
SKDSKD
MFPMFP
WCPWCP
DKEDKEAJTAJT
Big SOABig SOA
Analyze the businessAnalyze the business
12. ASBASB BLTBLT
HDLHDL
AFTAFT TGITGI FRYFRY
DRWDRW
SWGSWG
QYDQYD DLYDLY
BSTBST
WIUWIU
ASBASB
ZISZISXOIXOI CUICUI
RMORMO
DLYDLY
XPSXPS
KYFKYF
KFCKFC
WHRWHR
JIAJIA GEXGEX
FQAFQAVUHVUH
HCOHCO
WKDWKD
ECPECP
SKDSKD
MFPMFP
WCPWCP
DKEDKEAJTAJT
Big SOABig SOA
Identify Business AreasIdentify Business Areas
COP
Navigation
Protectors
Alerts
13. Big SOABig SOA
Map to softwareMap to software
"Network"
COPCOPCOPCOP
Nav.Nav.Nav.Nav.
AlertsAlertsAlertsAlerts
Prot.Prot.Prot.Prot.
14. Little SOALittle SOA
Architectural StyleArchitectural Style
For building distributed systemsFor building distributed systems
Loosely coupled componentsLoosely coupled components
Our focus from here onward…Our focus from here onward…
15. ServiceService
describesdescribes
End PointEnd Point ExposesExposes
MessagesMessages Sends/ReceivesSends/Receives
ContractsContracts
Binds toBinds to
ServiceService
ConsumerConsumer
implementsimplements
PolicyPolicy governed bygoverned by
Sends/ReceivesSends/Receives
AdheresAdheres
toto
ComponentComponent
RelationRelation
KeyKey
UnderstandsUnderstands
ServesServes
16. Services and SystemsServices and Systems
A service is a program you interact withA service is a program you interact with
via message exchangesvia message exchanges
A system is a set of deployed servicesA system is a set of deployed services
cooperating in a given taskcooperating in a given task
17. A Service edgeA Service edge
is a naturalis a natural
boundaryboundary
Warning: 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.
20. sd Autonomous Services
User Journal Subscription System Publisher X
User
«service»
Customer
«service»
Proposals
«service»
Proposals
Waiting on external resources
do we really know how long will it take?
Not to mention that getting the information
only when needed makes Service
interaction very RPC-like (but that's another
problem)
1.0
getProforma
1.1
getCustomerDiscount
1.2
1.3
getDiscountRate
1.4
1.5
XX
21. sd ActiveServ ice
User Journal Subscription System Publisher X
User
«service»
Customer
«service»
Proposals
«service»
Proposals
note that now we are getting all the dicount rates in
one call (less messages) to generate even less traffic
the contracts can be made to include only changes
from timestamp supplied in the request
loop Activ e Class polls external resources
1.0 getCustomerDiscounts
1.1
1.2 getDiscounts
1.3
2.0 ProduceProforma
2.1
22. The fact that I can, doesn’t mean I will.
PoliciesPolicies
23. Organization AOrganization A Organization BOrganization B
PolicyPolicy PolicyPolicy
Policy IllustratedPolicy Illustrated
Buyer ServiceBuyer Service
Local ServiceLocal Service Local ServiceLocal Service
Seller ServiceSeller Service
Runtime contractRuntime contract
Runtime ContractRuntime Contract
1. Use X.509 Cert for AuthN1. Use X.509 Cert for AuthN
2. Use UTF-8, SOAP 1.22. Use UTF-8, SOAP 1.2
……
PolicyPolicy
1. Supports X.509 Cert1. Supports X.509 Cert oror Kerberos ST for AuthNKerberos ST for AuthN
2. Supports UTF-8, UTF-16, SOAP 1.2, 1.12. Supports UTF-8, UTF-16, SOAP 1.2, 1.1
……
Adopted from Clemens VastersAdopted from Clemens Vasters
Design time ContractDesign time Contract
1. You’ll send a PO1. You’ll send a PO
2. I’ll send a confirmation2. I’ll send a confirmation
……
28. IdempotenceIdempotence
Idempotent Means It’s OK to Arrive Multiple TimesIdempotent Means It’s OK to Arrive Multiple Times
As Long as the Request Is Processed at Least Once, the CorrectAs Long as the Request Is Processed at Least Once, the Correct
Stuff OccursStuff Occurs
In Today’s Internet, You Must Design Your Requests to BeIn Today’s Internet, You Must Design Your Requests to Be
IdempotentIdempotent
Not IdempotentNot Idempotent
Baking a CakeBaking a Cake
Starting fromStarting from
IngredientsIngredients
Naturally IdempotentNaturally Idempotent
Sweeping the FloorSweeping the Floor
Naturally IdempotentNaturally Idempotent
Read Record “X”Read Record “X”
IdempotentIdempotent
If Haven’t Yet DoneIf Haven’t Yet Done
Withdrawal #XYZWithdrawal #XYZ
for $1 Billion,for $1 Billion,
Then WithdrawThen Withdraw
$1 Billion and$1 Billion and
Label as #XYZLabel as #XYZ
Not IdempotentNot Idempotent
WithdrawingWithdrawing
$1 Billion$1 Billion
IdempotentIdempotent
Baking a CakeBaking a Cake
Starting fromStarting from
the Shoppingthe Shopping
List (If MoneyList (If Money
Doesn’t Matter)Doesn’t Matter)
Pat HellandPat Helland
33. Keep Data and state privateKeep Data and state private
34. Big SOA is about business alignmentBig SOA is about business alignment
Little SOA is an Architectural StyleLittle SOA is an Architectural Style
Autonomous Coarse GrainedAutonomous Coarse Grained
ComponentsComponents
Message based InteractionsMessage based Interactions
Run-Time configurationRun-Time configuration
35. What’s nextWhat’s next
SOA Structural PatternsSOA Structural Patterns
SOA Interaction PatternsSOA Interaction Patterns
UI Interaction PatternsUI Interaction Patterns
Service Composition PatternsService Composition Patterns
Contract Anti-patternsContract Anti-patterns
Service Anti-patternsService Anti-patterns
SOA Performance Anti-PatternsSOA Performance Anti-Patterns
Hinweis der Redaktion
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 “spec’ed out”.
A Solution to world hunger Not a solution for everything Just another tool in the toolset A specific Technology Most 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 Can’t stress that enough Reduced assumptions (loose coupling) Builds on ideas from component software, distributed objects, and MOM BPM … All the stuff enterprise architects do 2003 PSS Global Summit
A service is a program you interact with via message exchanges Services are built to last Encompass a business perspective Stability and robustness are critical A system is a set of deployed services cooperating in a given task Systems are built to change Adapt to new services after deployment 2003 PSS Global Summit
Each Service interaction is a boundary crossing Don’t cross it with transactions / exceptions etc. Crossing service boundaries may have costs Service Orientation helps makes interaction formal, intentional, and explicit Service 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 I’ve 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 customer’s discount rate and the customer’s discount rate as well as the publisher’s 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 publisher’s discount might be a remote one (on the publisher’s system) – what happens to our proposal service if the publisher’s 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 about Security messages behavior level of service limited by the actual service capabilities Policy-sets are attached, embedded or otherwise associated with contracts Policy 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 consumer
address, 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 Messages Services Are “Black Boxes” Messages go in and out The Rest Is an Implementation Detail! 2003 PSS Global Summit
Between Services is Special Messages Are Sent and Float Around Between Special Care Is Needed to Understand Them Can Be Confusion About Interpreting Them Many Kinds of Message transports Email, IP, TCP/IP, HTTP, Web-service, MSMQ, MQ-Series, and more Many Kinds of Message structures XML, Binary, whatever May be OK to Have Some Message Loss If messages are idempotent Other option “Reliable Messaging” 2003 PSS Global Summit
2003 PSS Global Summit
One Way Incoming Outgoing Broadcast Publish (as in publish/subscribe) To single recipient Duplex Two one-ways Request/Reply R equest/Reaction 2003 PSS Global Summit
Messages & Formats Message Exchange Patterns Where is a service located (Address) Protocol & content format (Binding) 2003 PSS Global Summit
Service Data is private Keep DB private Keep transactions private Keep exceptions private Don’t share classes or other internal data structures Don’t share too much – or you’ll lose autonomy (or tempt others to lose it) 2003 PSS Global Summit
Services interactions are message driven Services should be Loosely coupled Edges should provide location transparency Business logic and edge are separate layers Scale inside the service You can use workflows for long-running interactions again - inside the service 2003 PSS Global Summit
