SOA

Build up from reviewing Thomas Erl's SOA Principles of Service Design Service Contracts

Corresponds to Chapter 6 definition

defines terms of engagement provides technical constraints public semantic information

described with 'service description' documents web service contract would be made up of

WSDL definition XML Schema Definition WS Policy description document for SLA

RPC service contracts could be described with IDL or ASN.1 Principle Profile

Definition "services share standardized contracts" services within the same inventory are in compliance

with the same contract design standards Goals

have meaningful levels of interoperability consistency of data models to minimise transformation allow services to be easily understood achieve a level of consistency

Design Characteristics a contract is provided with the service contract is standardised application of design standards

Implementation Requirements design standards in place & in use formal processes for ensuring service modelling & design is

consistent promotion of 'contract first' approach appropriate modelling & design skills

Standardization data representation

avoid unnecessary transformation common definitions for common types causes of non standardisation

auto generated by dev tools part of service adaptor purchase no standards in place standards ignored

functional service expression policies

assertion vocabularies e.g. WS-SecurityPolicy, WS-ReliableMessaging without standardisation risk of dependency

on underlying implementation parameters & nested policies

structural standards e.g. using WSDL

granularity quantity service contract content & extent of

standardisationcan have direct bearing in principles being realized

has close relationship to service loose coupling & service abstraction principles

Risks with Service Contract Design versioning technology dependencies

technology maturity lifespan compatibility upgradability

development tool deficincies manual crafting to avoid defn being subject minute

changes from App tool capable of supporting aspects of standards

needed ability to import existing services

capture of non technical elements SLAs

Design Fundamentals Design Characteristic

attribute orv quality goal for characteristics that are measurable aim for common characteristics increased consistency increased consistency -> more predictable

Design Principle generalized industry practise recommended guidelines for shaping solution

Design Paradigm approach or school of thought combines with rules governing approach to design

Design Pattern Language when apptern applied to solve 1 problem shows up

another so resolved by a combination of patterns Design Standard Best Practise Design Pattern

Service OrientatedRelates to Chapter 4 of SOA Principles

Service Orientation as a Design Paradigm Standardized Service Contract Service Loose Coupling Service Abstraction Service Reusability Service Autonomy Service Statelessness

excessive state info can impact scaling Service Discoverability Service Composability

considerations to support service usability service - has specific meaning service can be a collection of related capabilities services are interoperable

service contracts are standardised reducing service coupling means limited interdependency abstraction allows implimentation to evolve designing for re-use in mind raising service autonomy makes service more predictable statlessness allows better scaling options - therefore interoperate

more frequently more consistently service discoverability - easier location by components that want

to use servic es composable requires interoperability

Challenges in Introduction design complexity (potentially increased)

increased performance requirements due to greater usage reliability at peak concurrent usage increased risk due to single point of failure increased demand on hosting service contract versioning issues

design standards facilitate consistency more successful if championed by snr exec need to 'lay down the law' cultural resistance communication & education to overcome

top down requirements conceptualise services through blueprint of all planned

services does create a lot of upfront effort iterative process - will require existing work to be revisited

& reviewed counter-agile service delivery in support of agile solution delivery

initial upfront work can be seen as counter agile once into svc dev - lot more agile as a result

Governance Demands

other considerations enterprise wide standardisation not required not revolutionary paradigm

Origins & Influences on SOA Object Orientation

reuse abstraction composition

Business Process Management Enterprise Application Integration Aspect Orientated Programming

Service CouplingThis relates to Chapter 7 of the SOA book

coupling types consumer coupling

Consumer-to-implementation will cause problems with linkage to technology bypasses contract maybe seen as attractive for performance reasons can constrain this approach through centralisation

Consumer-to-contract recommended & desirable approach

connection between services to form solution contract based coupling

Logic-to-Contract contract 1st approach doesn't fit when having to accomodate existing logic able to tune logic to contract - potential for

performance improvement contract-to-Function Contract-to-Implementation Contract-to-Technology Contract-to-Logic

allows freedom for service evolution can create situation where service defn has to

change in auto generated situations measurement

possible to measure coupling & resultant quality score each type of coupling by type - best being lowest score, worst

highest calculate couplnig score over total coupling

coupling and service models entity services

keep coupling to biz entities should only change as biz changes keep agnostic to process

utility services encapsulate legacy so can become implementation coupled use contract to limit implementation associated coupling

risk of being defined with vendor technology Task Services

can be functionally coupled if service repsents sub biz process will be dependent on

external biz logic can end up with service - consumer coupling where

providing very small services Orchestrated Task services

avoid tech coupling in implementation by using stds e.g. BPEL

impact considerations service loose coupling can have can influence design of standards for contracts emphasis on service abstraction emphasis centralization to maximise re-use increase levels of service autonomy regulate meta data publication for discoverability prevent dependencies that can inhibit service composability

what if coupling is too loose interface types too bareboned/primitive incur greater overhead in data interpretation increased performance requirements

Service Reusability Principle

goals repeated leverage service to improve ROI increase business agility realize agnostic service models enable creation of service inventories with high percentage

of agnostic services design characteristics

The service is defined by an agnostic functional context The service logic is highly generic The service has a generic and extensible contract The service logic can be accessed concurrently

Definition -Services contain and express agnostic logic and can bepositioned as reusable enterprise resources

measurement commercial design considerations

Service Autonomy (Boundaries & Control)Chapter 10 - service Autonmy (Processing Boundaries and Control)

Service Re-usabilityChapter 9

challenges of service design designing for multiple scenarios potential of complexity growth implementing enhancements when there are multiple users

Profile Definition - Services contain and express agnostic logic and

can be positioned as re-usable enterprise resources

goals allow for service logic to be repeatedly leveraged

over time so as to achieve an increasingly high returnon the initial investment of delivering the service

increase business agility on an organizational level byenabling the rapid fulfillment of future business automationrequirements through wide-scale service composition

enable the realization of agnostic service models To enable the creation of service inventories with a high

percentage of agnostic services characteristics

service is defined by an agnostic functional context service logic is highly generic service has a generic and extensible contract service logic can be accessed concurrently

Implementation Requirements scalable runtime environment solid version control analysts and designers have a high level of SME high level of service dev & commercial s/w dev to ensure

underlying logic generic Measuring re-use & applying commercial design

maximise re-use need to understand potential future uses need to understand organisations biz models,

tech env, and users - hence upfront SOA analysis commerical solution view - helps predict

possible application in future informs most suitable type of logic informs most suitable quanity of logic

common criteria to be applied strategic goals & vision statements existing models such as service inventory blueprint common usage scenarios current biz requirements historical biz patterns (see changes in direction) possible acquisitions that may impact biz model service delivery timelines existing legacy and upgrade plans

can use market survey - as target audience known to measure needs

measures of planned re-use tactical reuse (the services needed now) targeted reuse (features for now & beyond

immediate need, but only extend as need arises) Complete reuse (service developed for complete

range of functionality - use if good service inventory blueprint exists)

measuring actual reuse the number of services that consume the service

frequency of consumers using the service Commercial Design vs Gold Plating

gold plating risks extra features increase delivery time & cost extra features conflict with program's existing

design goals features may never be needed or used

if apply service re-use properly, wont result in gold plating to achieve re-use need to persue design standards

services defined as re-usable must only be used throughpublished interface - Logic Centralization pattern

motivation for logic centralisation standard risk of adding logic into existing services project not aware of other services where logic better

suited startup effort of a developing with a different service

differentiate between logic centralization & contract centralization Logic Centralization asks designers to build consumer

programs that only invoke designated services when specific types of information processing are required, it does not address how this logic is to be accessed.

Contract Centralization asks designers to build consumer programs that access a service only via its published contract, it does not specify which services should be accessed for what purpose.

reuse & design reuse & service modelling reuse & granularity

service granularity capability granularity data granularity constraint granularity

reuse & service models other principles to be considered

service autonomy service statlessness service discoverability service discoverability service composability

Risks cultural concerns

re-use not engendered managing cross projects as reuse can cross cut its impact surrender of solution design control

governance team focus away from solutions to services change in ownership of services to a central group augmentation of central team

reliability - single service, means if it fails impact far greater

security - service providing right level of constraint to consumers agile delivery

Service AbstractionRelates to Chapter 8 of Thomas Erl's Principles of SOA Design

for information hiding meta abstraction types

technology information functional information programmtic logic information

hiding how service implemented consider implications of delivery

closed source inhouse open source

quality of service information may have to publish details concurrency limits availability limits eg scheduled outages biz rules that determine way apps respond

profiling of principle measuring abstraction

content abstraction levels (worst) detailed

elaborate with many constraints defined common with validation when business rules have been deferred to a

contract abstraction not really being applied

concise minimal abstraction applied

(best) optimized typically audited for abstraction validation of inputs sparse & capable of handling a

widev range of data input mixed detail

some aspects optimized others not typical of vevolutionary process can occur when policies not properly applied

access control levels abstraction typically on the technical domain access control on the human domain prevent non service owners from seeing detail they should not

need balance between abstraction & encapsulation

encapsulating legacy environments may prove challenging asconstrained by APIs, connectors and existing technology

custom logic - provides best chances to balance risks

multi-consumer coupling

difficult to get service vs performance right for all consumers

abstract too much information can make service unusalble to some consumers

Contract denomalization pattern may help misjudgement by humans

abstract too much and human assumption about capability can be a problem

insufficient information lead none use as assumed doesnt meet need

security & privacy risks of compliance etc service availability

Web References SOA Books

http://www.soabooks.com/ SOA Patterns

http://www.soapatterns.com/ SOA Magazine

http://www.soamag.com/ IBM RedBook- Implementing an SOA using an Enterprise Service Bus

http://www.redbooks.ibm.com/redbooks/pdfs/sg246346.pdf Wikipedia

http://en.wikipedia.org/wiki/Service-oriented_architecture OASIS

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm#resources SOA Blue Print

http://www.soablueprint.com/ IBM RedBook - SOA Security

http://www.redbooks.ibm.com/redbooks/pdfs/sg247310.pdf Design Principles

Relates to Chapter 5 activities to get SOA underway

Commonly supported SOA Principlesduring modelling process

Service Reliability Service Autonomy Service Discovery

need to factor principles into design process Establish Supporting Design standards

principles that implement vs regulate principles resulting in implementation

of specific service patterns standardized service contract service re-usability service autonomy service statelessness service discoverability

primarily shape & regulateapplications of other principles

service loose coupling

service abstraction service composability

capability vs operation vs method capability = specific function of a service capability = expressed within service contract capability = not a dictation of implementation operation = capability implimented as web service method = represents capability as part

of a service existing as a component Granularity

service granularity functional scope of service coarse grained - broad functional context.

Maybe 1 or many capabilities capability granularity

functional scope of a specific capability fine grained means less work to do

data granularity quantity of data exchanged for a capability to do its work passing whole documents (even if service only

needs a fraction of it) = coarse grained constraint granularity

how precise the schema/data modeldefines the data structure

Service Orientated ComputingBased around Chapter 3

key elements Service Orientated Architecture Service orientation Service Orientated Solution Logic Services Service Compositions Service Inventory

Service Models Entity Services Task Services Utility Services

supporting services e.g. logging SOA and Web services

1st Gen WSDL SOAP UDDI

2nd Gen WS-* extensions www.ws-standards.com

www.ws-standards.com www.soaspecs.com

www.soaspecs.com Service Inventory Blue Prints

pre-service development, consolidate variousbiz models to get global view

sources business entity models logical data models canonical data models ontologies

Service Orientated Analysis a methodology to provide consistent level of service definitions Service modeling service candidates (candidate services) increased emphasis in BA in design process

Goals & Benefits Increased Intrinsic Interoperability

improved data sharing between apps make services interoperable - so less actual integration

effort facilitated by consistency of approach

Increased Federation resources & apps united whilst retaining autonomy &

governance standardisation needed upfront underpining becomes de-emphasised

Increased vendor diversification options always 'best of breed' becomes an option services approach allows for vendor neutrality

Increased Business & Technology Domain alignment promotion of abstraction layers abstraction allows modelling to be better aligned to biz needs more input from biz SMEs

Increased ROI potential for re-use does require more upfront investment for longer term ROI

Increased Organisational Agility ability to respond to change better building blocks - so quicker results improved agnostic allowing for changes easier/quicker to

introduce Reduced IT Burden

better reuse = lower total maintenance