SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES
Transcript of SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES
![Page 1: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/1.jpg)
SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES
Some Key Concepts and Ideas
![Page 2: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/2.jpg)
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
![Page 3: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/3.jpg)
Service Oriented Architecture?
� Or Stupid Overused Acronym?
![Page 4: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/4.jpg)
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
![Page 5: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/5.jpg)
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
![Page 6: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/6.jpg)
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
![Page 7: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/7.jpg)
SOA Meta Model
![Page 8: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/8.jpg)
SOA solution stackhttp://www.ibm.com/developerworks/websphere/techjournal/0806_radcliffe/0806_radcliffe.html
![Page 9: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/9.jpg)
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)
![Page 10: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/10.jpg)
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
![Page 11: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/11.jpg)
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
![Page 12: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/12.jpg)
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?
![Page 13: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/13.jpg)
Loosecoupling
� The main goal of loose coupling is to minimize the amount of artificial dependency
![Page 14: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/14.jpg)
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
![Page 15: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/15.jpg)
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…
![Page 16: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/16.jpg)
Synchronous communication flow
Wait for a Request
Receive Send Request
Wait or Time Out
Receive Response
Receive Request
Process Request
Return Response
Request
Response
![Page 17: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/17.jpg)
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…
![Page 18: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/18.jpg)
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
![Page 19: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/19.jpg)
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…
![Page 20: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/20.jpg)
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!
![Page 21: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/21.jpg)
Message routing
Inventory
Inventory1 1 2
Purchase order
Our Application
Order Processing
Customer Info
Our Application
Customer Info
Order Processing
2
33 4
![Page 22: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/22.jpg)
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
![Page 23: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/23.jpg)
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
![Page 24: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/24.jpg)
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
![Page 25: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/25.jpg)
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
![Page 26: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/26.jpg)
Publishedschemas
Schema
PublishSubscribe
Service requester
Service provider
Message
PublishSubscribe
Describe
Mapin/Map out Mapin/Map out
![Page 27: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/27.jpg)
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
![Page 28: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/28.jpg)
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>
![Page 29: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/29.jpg)
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
![Page 30: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/30.jpg)
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?
![Page 31: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/31.jpg)
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
![Page 32: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/32.jpg)
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)
![Page 33: SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES](https://reader030.fdocuments.net/reader030/viewer/2022011915/61d7e69f98d69e050c652a04/html5/thumbnails/33.jpg)
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!