1 / 100

4. Service Oriented Architecture 4.1. An Introduction

4. Service Oriented Architecture 4.1. An Introduction. Enterprise Service Bus (ESB). SOA = S ervice O riented A rchitecture. Web Services. SOA = Service Oriented Architecture

nyx
Download Presentation

4. Service Oriented Architecture 4.1. An Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 4. Service Oriented Architecture4.1. An Introduction

  2. Enterprise Service Bus (ESB) SOA = Service Oriented Architecture Web Services • SOA = Service Oriented Architecture The services on the ESB are: a) thought to be integrated – “service oriented”;b) registered on a directory server; c) typically orchestrated.

  3. SOA • Service Oriented Architecture • A system is made up of autonomous entities (sub-systems) which act independently of each other. All systems have interfaces which were thought explicitly for system integration. • Sub-systems have a course granularity (e.g. billing, warehouse, purchasing, etc.), typically being capable of executing independently of each other. These subsystems, and in particular their integration interfaces, are called services. • A possible way of implementing a SOA is using Web Services and related technologies. «An SOA is an orchestrated sequence of messaging, transformation, routing and processing events in which XML technologies expose the message content and the components that operate on the messages.»

  4. System B System C System D System A Service Interface Service Interface Service Interface Service Interface Enterprise Service Bus SOA in a nutshell Process Orchestrator Service Directory A Service Oriented Architecture

  5. Services != Distributed Objects • Different Deployment Model • Services are “hosted” instead of distributed based on their computational function • Encapsulation is made at the interface level (business driver) and not at implementation level • Interception and chaining of services is natural • Routing is performed based on content and context • High level of granularity • High autonomy • Integration Structure • Integration interfaces (services) where thought explicitly for that • Common business models among partners

  6. Why use a SOA? • Future, Scalability and Evolution! • An organization is made up of many different systems. Sooner or later they will have to talk to each other. (typically, sooner than latter!) • If systems are not thought from the beginning for integration, the solutions found for doing so will be ad-hoc, without possibility of evolution, and with high development and maintenance costs • Using a Service Bus and a Service Oriented Architecture allows for future evolution, both by easily adding new services and, if necessary, replacing existing service implementations • A SOA allows to do so with minimal disruption of the business processes of an organization.

  7. The importance of Open Standards • It’s absolutely important that a SOA is based on Open Standards • It allows the architecture to stay in place on the long-run • Allows external services to be easily integrated into the organization’s infrastructure • Allows for the substitution of existing systems by better ones (e.g. better technology, with a lower cost of ownership, or that are more adequate to the organization’s strategy) • Technologies like XML, HTTP, SOAP e 1st generation Web Services and 2nd generation WS play a vital role «It allows applications to bind to services that evolve and improve over time without requiring modification to the applications that consume them»

  8. Moving into Services To From • Connections = cost • Function oriented • Build to last • Prolonged development • Connections = value • Process oriented • Build for change • Incrementally deployed • Application silos • Tightly coupled • Object oriented • Orchestrated solutions • Loosely coupled • Message oriented (c) Microsoft

  9. Business Process View Coarse Grained Web Service Operations Finer Grained Internal Service Operations Fine Grained Object and database calls BusinessComponent BusinessComponent ConsumerApplication Business Process

  10. SOA based on Web Services • First Generation Web Services • HTTP, XML, XSD, WSDL, SOAP  Web Services • UDDI • Second Generation Web Services • Allow for a Service Oriented Architecture • WS-* Specifications • WS-Routing • WS-Referral • WS-Inspection • WS-Security • WS-Attachments • WS-Coordination • WS-Transaction • WS-SecureConversation • WS-SecurityPolicy • WS-Policy • WS-PolicyAttachment • WS-PolicyAssertions • WS-Addressing • WS-ReliableMessaging

  11. Autonomous systems, viewed as services S4 S5 S6 They are capable of sending and receiving messages S2 S7 Orchestration Logic S1 S8 UI1 User Interfaces UI4 UI2 UI3 What does it look like? S3

  12. BizTalk Server 2003

  13. 4. Service Oriented Architecture4.2. Web Services

  14. ?$#%$# ?$#%$# ?$#%$# Web Services? Warehouse Java/J2EE JavaRMI Portal Billing CORBA COBOL DCOM VB/ASP

  15. Web Services! • The first step to have interoperable systems is to based them on open standards, de facto supported by industry • All systems must be able to talk a common language Warehouse Java/J2EE WS SOAP XML SOAP XML Portal Billing WS COBOL WS VB/ASP SOAP XML

  16. Web Services • What’s a web service? «A web service consists in an application identified by a URI which can be accessed over the internet using open standards like SOAP/XML»

  17. Evolution of the Web XML HTML Technology TCP/IP Presentation Programmability Connectivity FTP, E-mail, Gopher Innovation Web Pages 1 Web Services Browse the Web 2 Program the Web 3

  18. Web Services • XML • Representing messages using a platform-independent universal format. • SOAP = Simple Object Access Protocol • Allows to transport XML messages between systems in a simple an middleware-independent way. • The underlying protocol is normally HTTP. But, others can be used (SMTP, FTP, ...) • HTTP  Port 80 is good  [Well, sort of... ] • WSDL = Web Services Definition Language • Describes web services (i.e. the service contract) • UDDI = Universal Description, Discovery, and Integration • Directory service which allows to register and discover web services

  19. Web Service Model Service Description Service Registry FIND 2 PUBLICATION WSDL, UDDI 3 WSDL, UDDI Service Requester 4 Service Provider Service Service Description BIND SOAP 1 • Web service is installed • Web service is registered • Client(s) lookup web service • Web service is instantiated (n times), possibly by many clients

  20. HTTP/FTP/SMTP UDDI WSDL SOAP XML Web Services Stack?

  21. XML based protocol for exchange of information Encoding rules for datatype instances Convention for representing RPC invocations Designed for loosely-coupled distributed computing No remote references Used with XML Schema Transport independent SOAP with Attachments allow arbitrary data to be packaged. SOAP1.1 Message Structure SOAP Envelope Header Entries [Header Element] Body Element [Fault Element] SOAP

  22. Node types SOAP Receiver • Three node types: sender nodes, intermediate nodes, receiver nodes • Destination nodes (i.e. intermediate or final nodes) are identified on the Header of the messages (env:role) • Typical values of env:role are “next” (processed by the intermediate and final nodes) and “ultimateReceiver” (only processed by the final node) • Messages (payload) exchanged between SOAP nodes can be: • RPC-based (i.e. method invocation) • Document-based (i.e. you send/receive an XML document) • It’s also possible to exchange messages containing BLOBs of binary data (SOAP Messages with Attachments) SOAP Intermediary SOAP Sender Intermediary Service Service Provider Service Requester

  23. Web Services Types • Document/Literal (Wrapped) • The payload of the SOAP message is an XML document that can be validated against XML schema. The document itself is represented as method parameters (Wrapped approach). • Document/Literal (Bare) • Bare is an implementation detail from the Java domain. Neither in the abstract contract (i.e. wsdl+schema) nor at the SOAP message level is a bare endpoint recognizable. • A bare endpoint or client uses a Java bean that represents the entire document payload. • RPC/Literal (Wrapped) • With RPC there is a wrapper element that names the endpoint operation. Child elements of the RPC parent are the individual parameters. It’s “calling methods” using XML, not passing documents. • Note: there is no complex type in XML schema that could validate the entire SOAP message payload. • RPC/Encoded • Shouldn’t be used! “SOAP encodeding style is defined by the infamous chapter 5 of the SOAP-1.1 specification. It has inherent interoperability issues that cannot be fixed. The Basic Profile-1.0 prohibits this encoding style”

  24. Web Services Types • JBoss extends available web services types to include a very useful mechanism: direct XML Elements. • “You may come to the point where RPC/literal or Document/literal is not what you are looking for. This may be the case for instance, when you want to do the XML processing yourself instead of deferring it to the SOAP stack. JBossWS offers the possiblity to setup message style endpoints that do exchange raw XML documents mapped to DOM elements or SOAPElements”(JBoss Web Services Guide) • This means that you can pass directly an XML tree created in memory as parameter. • Called “Message Style Endpoints” public interface Shop extends Remote { public Element getInvoice(Element client) throws RemoteException; } http://labs.jboss.com/jbossws/user-guide/en/html/1.0.4/en/html/getting-started.html

  25. SOAP Messages <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetailsxmlns="http://warehouse.example.com/ws"> <productID>827635</productID> </getProductDetails> </soap:Body> </soap:Envelope> Request <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <getProductDetailsResponse xmlns="http://warehouse.example.com/ws"> <getProductDetailsResult> <productName>Toptimate 3-Piece Set</productName> <productID>827635</productID> <description>3-Piece luggage set.</description> <price>96.50</price> <inStock>true</inStock> </getProductDetailsResult> </getProductDetailsResponse> </soap:Body> </soap:Envelope> Response

  26. HTTP Request HTTP Body XML Syntax SOAP Envelope SOAP Body SOAP Body Block Textual Integer Sender Receiver 0x0b66 What’s the problem with all this? • Computationally heavy and data heavy! • 1 byte of information  many bytes of context • 1 byte of information  many CPU cycles of processing

  27. WSDL = Web Services Description Language • Used for describing SERVICE INTERFACES • Datatypes used by the web service • What methods are available for invocation • What are the input and output parameters • Which are the SERVICE IMPLEMENTATIONS available • Which are the endpoints (bindings) • Which are the supported transport protocols • WSDL is the Interface Definition Language of Web Services

  28. A WSDL document describes What the service can do Where it resides How to invoke it WSDL are like IDL but lot more flexible and extensible Defines binding for SOAP1.1, HTTP GET/POST and MIME WSDL descriptions can be made available from an UDDI registry What does a WSDL document looks like? WSDL1.1 Document Structure WSDL Document [Types] {Messages} {Port Types} {Bindings} {Services}

  29. Format of a WSDL document XML-Schema of all data types Parameters of a service Listing of available services Maps services to protocols: SOAP, HTTP, etc. The service’s URL <definitions> <types> <schema></schema> </types> <message> <part></part> </message> <portType> <operation></operation> </portType> <binding> <operation></operation> </binding> <service> <port></port> </service> </definitions>

  30. WSDL example <?xmlversion="1.0" encoding="utf-8"?> <definitionsname=“BookStore" ... > ... </definitions> <types><schema> ... </schema></types> <messagename="ISBN_Number"> <partname="isbn" type="xs:string"/> </message> <messagename="BookInfo"> <partname="title" type="xs:string"/> <partname="author" type="xs:string"/> </message> <portTypename="Catalog"> <operationname="GetBookByISBN"> <input name="isbn_number"message="ISBN_Number"/> <output name=“result"message="BookInfo"/> </operation> </portType> ... Data types Messages used by the service Abstract service definition

  31. WSDL example (2) <bindingname="BookByISBN_SOAP_Binding" type="Catalog"> <soap:bindingstyle="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation> <soap:operation soapAction="/GetBookByISBN"/> <input><soap:bodyuse="literal"/></input> <output><soap:bodyuse="literal"/></output> </operation> </binding> <servicename="ACME_Book_Service"> <documentation>ACME BOOKS CATALOG</documentation> <portname="BookByISBN_Port" binding="BookByISBN_SOAP_Binding"> <soap:addresslocation="http://acmebooks.com/webservices"/> </port> </service> </definitions> Maps the service into the HTTP protocol Binds the service mapping into an address endpoint

  32. Luckly... • In many cases you don’t need to know the details behind WSDL. (But some times you do!) • There are tools to automatically generate all the necessary classes for the target programming language you are using

  33. 3. 1. SW companies, standards bodies, and programmers populate the registry with descriptions of different types of services Marketplaces, search engines, and business apps query the registry to discover services at other companies 2. 4. BusinessRegistrations Service Type Registrations Businesses populate the registry with descriptions of the services they support Business uses this data to facilitate easier integration with each other over the Web UDDI • A directory service for web services UDDI Business Registry

  34. UDDI (2) • The initial objective was that different organizations and companies would register their businesses on a central directory. Other companies looking for functionality would look them up. • Didn’t happen! • Organizations and companies don’t work that way! • Even so, UDDI is extremely useful when implementing a SOA. It can serve as a centralized repository for all services available in an organization! • Easy lookup and orchestration

  35. 1st Generation Web Services

  36. Problems Interoperability!!! ?

  37. Web Services Interoperability Organization • Supervises the process of having compatible WS stacks among players • Strategy: Profiles and Tests Interoperability • With so many specifications (XML, XSD, SOAP, WSDL, UDDI), it’s really hard to setup a system that is able to talk with another system on a different platform • Different versions, different implementation, different interpretations of standards…

  38. WS-I Basic Profile 1.1 • A WS stack implementation is compliant with WS-I Basic Profile 1.1 if it correctly supports: • SOAP 1.1 • HTTP/1.1 • HTTP State Management Mechanism (RFC2965) • XML 1.0 (2nd Edition) • XML Schema (Part I+II) • WSDL 1.1 • UDDI 2.0 (2.04 API, 2.03 Data Structure, 2 XML Schema) • HTTP over TLS (RFC2818) • TLS 1.0 • SSL 3.0 • X.509 (RFC2459) • ... with some extensions and amendments... • WS-I Basic Profile 1.2 was issued on March 2007

  39. Suppliers...

  40. 4. Service Oriented Architecture4.3. APIs for Web Services

  41. Seen in SD We’ll see it as an example... Recommended for the 2nd assignment (but not compulsory) APIs for Web Services • For developing web services you can use a number of platforms, application servers, and APIs • Sun J2EE Application Server • AXIS + Tomcat • BEA WebLogic • Microsoft.NET + IIS • JBoss WS

  42. A simple web service Algoritmos.asmx <%@ WebService Language="C#" Class="Algoritmos" %> using System;using System.Web.Services; publicclassAlgoritmos : WebService{[WebMethod]publicint Soma(int a, int b) {return a + b; }}

  43. Says that the web service is written in C# Says which class corresponds to the web service Example of a web service <%@ WebService Language="C#" Class="Algoritmos" %> using System;using System.Web.Services; publicclassAlgoritmos : WebService{[WebMethod]publicint Soma(int a, int b) {return a + b; }} Algoritmos.asmx

  44. How to deploy it? • Using MS Internet Information Server (IIS)... • You just have to create a new folder in the IIS web document directory and copy the file there. c:\Inetput\wwwroot\Matematica\Algoritmos.asmx http://localhost/Matematica/Algoritmos.asmx

  45. Test it using a web browser...

  46. Service Description... (?wsdl)

  47. Calling a particular operation...

  48. Calling... Which results in... Manually testing the web service

  49. tempuri.org? • “tempuri.org” is a temporary namespace. To change it, define it at the web service level. <%@ WebService Language="C#" Class="Algoritmos" %> using System;using System.Web.Services; [WebService(Namespace="http://www.dei.uc.pt/Algoritmos")]publicclassAlgoritmos : WebService{[WebMethod]publicint Soma(int a, int b) {return a + b; }}

  50. How can I use the service? • Obviously, the idea is to use the web service from an application, not through a web browser. • The wsdl.exe application generates the necessary files for including the service into your code.

More Related