SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES

Some Key Concepts and Ideas

Service Oriented Architecture?

� Depends on who you ask

� SOA is Web Services

� SOA is a technical architecture

� SOA is an evolution of distributed computing and � SOA is an evolution of distributed computing and modular programming

� SOA is an IT strategy based on a philosophy of sharing IT services with the aim of achieving business agility

� SOA is about business-IT alignment

Service Oriented Architecture?

� Or Stupid Overused Acronym?

Service OrientedArchitecture?

� From a more practical point of view, the idea is to add an additional layer of abstraction upon to (existing) programmatic applications that renders their functionality as services

� Services are typically fairly coarse-grained and business-oriented

� Reusability is essential: “We took designs and held them up to the light. We asked, if we built it, how much reuse would we get?” G. Glass, BT Chief Architect

An example, DaaS in SOA

JDBC API

SELECT custName, custAddressFROM CustomersWHERE custID = 21323;

Contact

Purchasehistory

Favorites

Predefined reusable servicesNo direct connection to db forthe client

Customerdatabase Customerdatabase

JDBC API Contact Favorites

Service Oriented Architecture?

� SOA organizes enterprise IT around services rather than applications

� Discrete functions contained in enterprise applications become interoperable, standards based services that can be combined and reused quickly to meet businessbe combined and reused quickly to meet business

� Application functionality, data, processes, …

� Because of their independent, modular nature, services can be used like building blocks to quickly and easily develop new business processes and composite applications, which can be simultaneously reused and deployed across multiple delivery channels

SOA Meta Model

SOA solution stackhttp://www.ibm.com/developerworks/websphere/techjournal/0806_radcliffe/0806_radcliffe.html

Some key ideas…

� SOA is an architectural concept in software design that emphasizes the use of combined loosely coupledservices to support business requirements directly

� In SOA, resources are made available to service consumers in the network as independent artifacts that consumers in the network as independent artifacts that are accessed in a standardized way

� SOA is about raising the level of abstraction so that requirements and business process can be discussed in a language understood by business people as well as IT folk (Graham, 2008)

Architectural concept?

� Software architecture is a representation of that how pieces of software system fit together

� SOA is not an architecture per se. Rather, it is an idea how to implement a software system

Therefore, SOA is independent of underlying � Therefore, SOA is independent of underlying technology� The main ideas (but not necessarily all) of SOA can be

implemented with the myriad of technologies

� Still, most of today’s SOAs use Web Services standards and technologies

Loose couplingbased on Kaye: Loosely Coupled – The Missing Pieces of Web Services , 2003

“I shall not today attempt further to define pornography…

but I know when I see it.”

Justice Potter Stewart, U.D. Supreme CourtJacobellis vs. Ohio, 1964

Loosecoupling

� W3C Glossary: Coupling is a dependency betweeninteracting systems.� Real depedency is the set of features or servicesthat a

system consumes from other systems. The realdependency always exists and cannot be reduced.dependency always exists and cannot be reduced.

� Artificial dependency is the set of factors that a systemhas to comply with in order to consume the features orservices provided by other systems. Artificialdependency always exists but it or its cost can bereduced.

� Examples?

Loosecoupling

� The main goal of loose coupling is to minimize the amount of artificial dependency

Tight vs. loose coupling

Tightly Coupled Loosely Coupled

Interaction Synchronous Asynchronous

Messaging Style RPC Document

Message Paths Hard Coded Routed

Technology Mix Homogeneous Heterogeneous

Syntactic Definition By Convention Published Schema

Bindings Fixed and Early Delayed

Semantic Adaptation By Re-coding Via Transformation

Software Objective Re-use, Efficiency Broad Applicability

Consequences Anticipated Unexpected

Asynchronous interactions

� Synchronous, “telephone conversation”

� Requires that all the parties are available and active at the same time

� Lost connection will cause the communication to fail and delayed response will probably trigger a timeoutdelayed response will probably trigger a timeout

� Asynchronous, “e-mail conversation”� Messages are stored in a queue (“inbox”) by the system

� A receiver can read and react to the message whenever it is convenient

� A necessary feature for business-driven applications� Long running transactions, connectionless protocols…

Synchronous communication flow

Wait for a Request

Receive Send Request

Wait or Time Out

Receive Response

Receive Request

Process Request

Return Response

Request

Response

Asynchronous communication flow

Receive Request

Record Order

Web storeSubmit order

Wait

Request What you’d like to see is a webpage with the package-trackingnumber and the expected deliverydate.

Instead, a store returns a web page

Send ACK

Delay

Thanks foryour order!

Response

Ship Purchase

Send Confirmation

Fire-and-ForgetYour orderhas shipped.

Instead, a store returns a web pagecontaining an acknowledgement.

Rather than complete transaction, thispage is a placeholder: “The next eventin this transaction will occur when weship your purchase, and send you anemail message.”

If the store didn’t return the ACK,and instead required your system topend, you might be sitting in front ofyour computer screen watching thebrowser’s spinning logo until theorder shipped days later…

Asynchronous communication flow

From the ‘programming’ point-of-view

Shopping at the mall

More gifts to

buy?

For the next

Done

yes

no

Shopping online

More gifts to

buy?

For the next

Done

yes

no

For the next recipient…

Select a gift for that person

Purchase the gift

Have it wrapped and

tagged

For the next recipient…

Select a gift for that person

Order gift online

Doorbell rings (that’s UPS)

Determine the recipient

Wrap it and label it

Done

Eventhandler

Procedural design vs. Event-driven design

Document-style messages

� In practice, the document-style messaging is required to implement asynchronous communication flows in business applications

� The unit of exchange in communication is a document� Whereas RPC-styled communications use more fine-grained � Whereas RPC-styled communications use more fine-grained

messages: methods, parameters and return-values

� Messages need to carry the information about the application context� A receiver knows to which conversation a message is related

to, from whom it came, to whom the response should be send, etc…

Document style messages

Self-contained messages (with context)

� In RPC style communication messages are kept as compact as possible

� In document style, context is included in the message

No context Accumulated context

Andy Do you want to have a lunch today? Andy Do you want to have a lunch today?

Cliff Sure, what time? Cliff Sure, I’m up for lunch. What time?

Andy How about noon? Andy Is lunch today at noon okay?

Cliff 12:30 is better for me. Where? Cliff Lunch today at noon isn’t good, but 12:30 will work. Where?

Andy Let’s say Italian restaurant on the corner, OK? Andy Let’s have lunch today at 12:30 at the Italian restaurant on the corner.

Cliff OK. See you then! Cliff Lunch today at 12:30 at the Italian restaurant on the corner sounds good. See you then!

Message routing

Inventory

Inventory1 1 2

Purchase order

Our Application

Order Processing

Customer Info

Our Application

Customer Info

Order Processing

2

33 4

Message routing

� More requirements to messaging protocols and infrastructure

InventoryMessaging Server A

Message

Acknowledgement

Customer Info

Queue

Messaging Server B

Queue

Internet or Intranet

MessageAcknowledgement

Poll

Message

Technology agnosticism

� Standards as the answer to interoperability problems?

� The problem remains as there are too many ‘standards’: different

Order Entry (J2EE) CRM (DCOM)

Common technology subset

‘standards’: different programming languages and conventions, development environments, operating systems, technology platforms, etc.

Common technology subset

Yet Another Application (RMI)

Two J2EE apps

Technology agnosticism

� The idea of loose coupling is to standardize the interface and not the implementationimplementation

� Somewhat similar approach is used in the most EAI products as well (adapters)

Standardized Interface

Publishedschemas

� Traditionally, communicating partners need to have a shared understanding of the syntax (not to mention the semantics) of exchanges

� Agreements, conventions, industrystandards, etc.

The objective has been to fix the data representation as � The objective has been to fix the data representation as early as possible, which leads to a tight coupling betweenthe systems

� In a loosely coupled system, the syntax of informationexchange is decoupled from how it is stored in a data base or manipulated in an application

Publishedschemas

Schema

PublishSubscribe

Service requester

Service provider

Message

PublishSubscribe

Describe

Mapin/Map out Mapin/Map out

Publishedschemas

� The party offering the service publishes the schema(using a standardized XML in case of Web Services) thatdescribes

� Data structuresData structures

� Documents

� Methods

� The requesting party can query the schema and discover up-to-date details at runtime

Delayedbinding

� The goal of delayed binding is to avoid any fixedor hard-coded binding to data typing, structure, location, or network connections

� Delayed binding helps to ensure that new versions� Delayed binding helps to ensure that new versionsof a service are backwards compatible and allowsincremental development and change

<servicename=”myService”><portname=”myPort” binding=”tns:myBinding”><soap12:address location=”http://myserver.com:9080/myService/myPort”></port></service>

Delayed binding

� Service description is read at runtime and a client dynamically selects the proper data encoding scheme and transfer protocol based on binding information

� The binding information is not hard-coded into the client

� Interface description is read just before service is requested

� Interface description (and of course the service implementation) can change between the requests

Dynamic discovery

� Dynamic binding makes it possible to use so called dynamic discovery

� No need to create pre-fixed service bindings and

� A requester can decide to switch from one service to � A requester can decide to switch from one service to another on a run-time

� QoS, SLA

� UDDI service directories, WS-Discovery, multicast protocol queries

� Challenging to implement for real-life applications?

Software objective and consequences

� Broad applicability

� Self-contained and coarse-grained services that perform universal and business-oriented tasks

� Just like Lego bricks� Standards-based interfaces (bumbs) allow services to be attached � Standards-based interfaces (bumbs) allow services to be attached

(and detached) to each others in a various ways

� Unexpected consequences

� Follows the broad applicability

� Unforeseen use cases

� Mashups (as an example, see the case vuokra-asunnot 5.3.), composite applications and SaaS

Four steps to SOA…

� Decompose the existing processes and siloed systems to their structural elements

� Identify the reusable and frequently needed componentscomponents

� Create a pool of reusable service components

� Base new applications and processes on these components using orchestration technologies (e.g., WS-BPEL)

Or twelve steps to SOA…by Dave Linthicum

1. Understand your business objectives and define success

2. Define your problem domain

3. Understand all application semantics in your domain

4. Understand all services available in your domain

5. Understand all information sources and sinks available in your domain

6. Understand all processes in your domain

7. Identify and catalog all interfaces outside of the domain you must leverage (services and simple information)

8. Define new services and information bound to those services

9. Define new processes, as well as services and information bound to those processes

10. Select your technology set

11. Deploy SOA technology

12. Test and evaluate

There is plenty to do to tackle the Step 1 alone.

And no, when creating SOA, you’re not supposed to start from the Step 10!