SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES. Some Key Concepts and Ideas

Transcription

1 SERVICE ORIENTED ARCHITECTURE DESIGN PRINCIPLES Some Key Concepts and Ideas

2 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 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

3 Service Oriented Architecture? Or Stupid Overused Acronym?

4 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

5 An example, DaaS in SOA SELECT custname, custaddress FROM Customers WHERE custid = 21323; Predefined reusable services No direct connection to db for the client Purchasehistory JDBC API Contact Favorites Customerdatabase Customerdatabase

6 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 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

7 SOA Meta Model

8 SOA solution stack

9 Some key ideas SOA is an architectural concept in software design that emphasizes the use of combined loosely coupled services to support business requirements directly In SOA, resources are made available to service 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)

10 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 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

11 Loose coupling based 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 Court Jacobellis vs. Ohio, 1964

12 Loosecoupling W3C Glossary: Coupling is a dependency between interacting systems. Real depedency is the set of features or servicesthat a system consumes from other systems. The real dependency always exists and cannot be reduced. Artificial dependency is the set of factors that a system has to comply with in order to consume the features or services provided by other systems. Artificial dependency always exists but it or its cost can be reduced. Examples?

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

14 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

15 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 timeout Asynchronous, 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

16 Synchronous communication flow Wait for a Request Send Request Request Receive Request Wait or Time Out Process Request Receive Response Response Return Response

17 Asynchronous communication flow Web store Submit order Wait Request Receive Request Record Order What you d like to see is a web page with the package-tracking number and the expected delivery date. Thanks for your order! Response Send ACK Delay Instead, a store returns a web page containing an acknowledgement. Rather than complete transaction, this page is a placeholder: The next event in this transaction will occur when we ship your purchase, and send you an message. Your order has shipped. Fire-and-Forget Ship Purchase Send Confirmation If the store didn t return the ACK, and instead required your system to pend, you might be sitting in front of your computer screen watching the browser s spinning logo until the order shipped days later

18 Asynchronous communication flow From the programming point-of-view Shopping at the mall Shopping online More gifts to buy? no Done More gifts to buy? no Done yes yes For the next recipient For the next recipient Doorbell rings (that s UPS) Select a gift for that person Purchase the gift Select a gift for that person Order gift online Event handler Determine the recipient Wrap it and label it Have it wrapped and tagged Procedural design vs. Event-driven design Done

19 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 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

20 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!

21 Message routing Purchase order 1 Inventory Inventory 1 2 Our Application 2 Customer Info Our Application Customer Info 3 Order 4 Processing Order Processing 3

22 Message routing More requirements to messaging protocols and infrastructure Inventory Message Acknowledgement Messaging Server A Message Internet or Intranet Acknowledgement Queue Messaging Server B Queue Poll Message Customer Info

23 Technology agnosticism Standards as the answer to interoperability problems? The problem remains as there are too many standards : different programming languages and conventions, development environments, operating systems, technology platforms, etc. Order Entry (J2EE) CRM (DCOM) Common technology subset Common technology subset Two J2EE apps Yet Another Application (RMI)

24 Technology agnosticism The idea of loose coupling is to standardize the interface and not the implementation Somewhat similar approach is used in the most EAI products as well (adapters) Standardized Interface

25 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 early as possible, which leads to a tight coupling between the systems In a loosely coupled system, the syntax of information exchange is decoupled from how it is stored in a data base or manipulated in an application

26 Publishedschemas Schema Subscribe Describe Publish Service requester Mapin/Map out Message Mapin/Map out Service provider

27 Publishedschemas The party offering the service publishes the schema (using a standardized XML in case of Web Services) thatdescribes Data structures Documents Methods The requesting party can query the schema and discover up-to-date details at runtime

28 Delayedbinding The goal of delayed binding is to avoid any fixed or hard-coded binding to data typing, structure, location, or network connections Delayed binding helps to ensure that new versions of a service are backwards compatible and allows incremental development and change <servicename= myservice > <portname= myport binding= tns:mybinding > <soap12:address location= > </port> </service>

29 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

30 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 another on a run-time QoS, SLA UDDI service directories, WS-Discovery, multicast protocol queries Challenging to implement for real-life applications?

31 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

32 Four steps to SOA Decompose the existing processes and siloed systems to their structural elements Identify the reusable and frequently needed components Create a pool of reusable service components Base new applications and processes on these components using orchestration technologies (e.g., WS-BPEL)

33 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!