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!