Your SlideShare is downloading. ×
0
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Service Oriented Architectures and Web Services
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Service Oriented Architectures and Web Services

4,156

Published on

Topics of Informatics, USI Lecture, 15.12.2010

Topics of Informatics, USI Lecture, 15.12.2010

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,156
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
169
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Service Oriented Architectures and Web ServicesProf. Cesare PautassoFaculty of InformaticsUniversity of Luganoc.pautasso@ieee.orghttp://www.pautasso.info@pautasso
  • 2. Prof. Cesare Pautasso  Ph.D. at ETH Zürich (2004)  Post-Doc at ETH Zürich in the Systems (IKS) Group  Researcher at IBM Zurich Research Lab (2007)  Assistant Professor at the new Faculty of Informatics, University of Lugano (USI), Switzerland (since September 2007)  Research Interests:  Software Architecture and Software Composition  Business Process Management  Service Oriented Architectures and Web Services  Web 2.0 Mashups and RESTful Web Services  Autonomic Computing  Grid Computing (Scientific Workflow Management)  More Information: http://www.pautasso.info/  Follow me on: http://twitter.com/pautasso/©2010 - Cesare Pautasso 2
  • 3. Marcin NowakDr. Achille Peternier Daniele Bonetta Saeed Aghaee
  • 4. Master Software Design III Software Design and Evolution II Software Architecture and Design I Software Engineering©2010 - Cesare Pautasso 4
  • 5. Once upon a time©2010 - Cesare Pautasso 5
  • 6. Once upon a time Software used to come in boxes©2010 - Cesare Pautasso 6
  • 7. Once upon a time Today, software runs in the clouds©2010 - Cesare Pautasso 7
  • 8. Once upon a timeCloud Operating System?©2010 - Cesare Pautasso 8
  • 9. Once upon a timeCloud Operating System?©2010 - Cesare Pautasso 9
  • 10. Today’s plan Software The Web Architecture (REST) SOA & WS Components Connectors vs. Services and Integration©2010 - Cesare Pautasso 10
  • 11. Context  Databases  Networking How to build applications  Software Engineering from scratch  Programming Languages  Service Oriented Architectures How to reuse and compose two or more existing applications  Web Services©2010 - Cesare Pautasso 11
  • 12. What is the problem? Operations Vermarktung Angebotserstellung& Leistungserbringung Fakturierung Leistungsbereitstellung (Assurance) (Billing) (Fulfillment) OTTO, Windows , Lotus Notes SIF MQ ORCA OMS extern FX CORBA MQ PeP LSM Insight esBill PA, zLinux PA FTP TTS ARS TOPM SCHON Notes CORBA ESW OPM MERS FTP CORBA FTP FTP FTP CORBA CSS TIS IPP+ FTP FTP Tuco FTP BASKAI FX MIDAS TIS CORBA Direx Peris SAP BDM TTS DWH BW extern FX BSK ES Archiv AD©2010 - Cesare Pautasso 12
  • 13. Integration (by hand…)©2010 - Cesare Pautasso 13
  • 14. Once upon a hand…)Integration (by time©2010 - Cesare Pautasso 14
  • 15. Integration (…with SOA)©2010 - Cesare Pautasso 15
  • 16. Integration Example©2010 - Cesare Pautasso 16
  • 17. Integration (… with JOpera)©2009-2010 - Cesare Pautasso, Erik Wilde 17
  • 18. De Architectura firmitatis utilitatis venustatisDurability: the building should last for a long time without falling down on the people inside itUtility: the building should be useful for the people living in itBeauty: the building should look good and raise the spirits of its inhabitants Vitruvio, De Architectura, 23BC
  • 19. Software Architecture As the size and complexity of a software system increase, the principal design decisions and the global structure of a system become more important than the selection of specific algorithms and data structures in order to determine its quality.©2010 - Cesare Pautasso 19
  • 20. Large Software Project  Lines of code: 50 Million  Number of developers: 2000  Time to compile: 24 hours  Time to ship: 5 years (from previous release) 60 Millions of LOC 40 20 0 1990 1995 2000 2005 2010©2010 - Cesare Pautasso 20
  • 21. Abstraction Layers Application Operating System Hardware©2010 - Cesare Pautasso 21
  • 22. Software as a Service Application Platform as a Operating System Service Infrastructure as a Service Hardware©2010 - Cesare Pautasso 22
  • 23. Layered Architectural Style Infrastructure as a Service Hardware
  • 24. Platform as a Operating System ServiceInfrastructure as a Service Hardware
  • 25. Component  Reusable unit of composition Made out of smaller components Can be composed into larger systems©2010 - Cesare Pautasso 25
  • 26. Connector  Generic enabler of composition Plug into matching component ports Transfer signals (data, control) between ports©2010 - Cesare Pautasso 26
  • 27. New Abstraction Levels Web Services Services XML REST Components J2EE .NET Eclipse Objects C++ Java C#©2010 - Cesare Pautasso 27
  • 28. Component vs. Service: Example Map Drawing Component Map getMap(lat, long, zoom)  (lat, long) centers the map on any location on the planet Earth and zoom can show details up to 1m precision  What is the “size” of this component?  How to deliver the component to customers so that it can be reused in their own applications?©2010 - Cesare Pautasso 28
  • 29. Component vs. Service: Business Model  How to sell a component?  How to sell a service?  Component developers  Service providers can charge on a per- charge on a per-call basis: deployment basis: each time an existing whenever a new client client interacts with a downloads the component. service by exchanging a  Component upgrades may new message. be sold separately to  Service providers can generate a revenue stream charge a monthly/yearly  Components can be flat access fee licensed to be redistributed  Services can be made within larger systems and available for free and developers can demand providers can support royalties from the revenue them with advertising of the final product revenue©2010 - Cesare Pautasso 29
  • 30. IT as a “manufacturing” industry (ship software components) IT as a “service” industry (publish software on the Web)©2010 - Cesare Pautasso 30
  • 31. Correctness & Verification function f(x) { … while(true) return y; { } … } Will it terminate? Will it run forever?©2010 - Cesare Pautasso 31
  • 32. Service Lifecycle Change (Functional Refactor Non-Functional) Design System Architecture Run, Define Manage, Interface Operate Contracts Deploy Build Test Services©2009 - Cesare Pautasso 32
  • 33. More than 500 million active users 30 billion pieces of content 20 million applications installed every day Launched February 2004©2010 - Cesare Pautasso 33
  • 34. Around the year 2010…  Google answers 5 billion API queries every day  Amazon S3 stores over 100 billion objects  75% of all the traffic (3 billion calls/day) of Twitter goes through its API From Tomas Vitvar, Mashups 2010 Keynote©2010 - Cesare Pautasso 34
  • 35. Component vs. Service: Technology  To be used a component must:  To be used a service must:  be packaged to be deployed  be published on the Web as part of some larger (once) application system  advertise its description and  fit with the existing framework location to potential clients used to develop the system across the Web so that they  There are many component can access it using standard frameworks available for building protocols distributed systems (e.g., J2EE,  Like components, services can be DCOM, .NET, CORBA). reused, composed into larger  The problem is: they are not systems and (of course) they can compatible (as an exercise try to be found on the Web. use a .NET assembly to make an  Unlike components, services do Eclipse plug-in and see what not have to be downloaded and happens) deployed in order to be used by clients. Instead, a client may discover and access their functionality by using standard protocols (WSDL, SOAP, UDDI) based on XML standards.©2010 - Cesare Pautasso 35
  • 36. What is Integration? Application 1 Application 2 Display Logic State + Display Logic State =?  New applications are built out of the composition of existing ones  Prefer to reuse, extend, and recombine existing systems as opposed to develop new ones from scratch©2010 - Cesare Pautasso 36
  • 37. Why integration matters  Useful information systems evolve over time by growing in size and by incorporating functionality of existing standalone systems. Applications originally intended to operate separately, are required to interoperate with others later on.  Technology change affects all layers, legacy does not go away so easily.  The architecture of the enterprise information system depends on constraints related to the technology but also to the organization.  In the case of B2B, each company owns its information system and will not open it up more than strictly necessary as it is part of their competitive advantage. For example, not all business processes are going to be shared, as business processes are mostly kept secret.  Within an enterprise, each department may have its own IT infrastructure, systems and databases which are maintained independently. Integrating them may bring additional value through cost reduction to the company.  Mergers, acquisitions and spin-offs leave a long lasting trace in the information systems of the corresponding companies©2010 - Cesare Pautasso 37
  • 38. Challenges of Integration  Many problems to be addressed in Enterprise Application Integration stem from having to integrate standalone applications which have been developed independently, operate autonomously, and were not originally indended to be integrated with one another.  Heterogeneous – each application implements its own data model. Concepts may be shared, but representation mismatches are to be expected. Mappings and transformations are required.  Autonomous – applications update their state independently without coordinating with each other. The systems to be integrated are maintained independently and upgraded at different times.  Distributed – in the worst case, every application runs on a completely separate environment, e.g., database storage is not shared among applications. Message-based communication through the network is the only possibility to exchange information. This part is taken from C. Bussler, B2B Integration, Springer, 2004©2010 - Cesare Pautasso 38
  • 39. Integration is bottom up How to mix software not designed to be integrated?©2010 - Cesare Pautasso 39
  • 40. Integration Techniques  Given two (or more)  Examples: existing applications,  Manual Data Transfer how can you compose  Manual (with Copy & Paste) them?  File based integration (Hot Folder)  It depends on whether  API extraction and publishing you can change the  Command line scripting applications to make  Wrap existing software them talk together.  Screen Scraping  How much integration  Data transformation and conversion can be done  Message based integration automatically?  Point to Point  Centralized, Peer to Peer  Mashup©2010 - Cesare Pautasso 40
  • 41. Layers as integration points Integration at the presentation layer (screen scraping) is always possible, but the least recommended. UI Well designed applications Application have an API It is also possible that we can call to bypass the directly. application and directly access DB its database©2010 - Cesare Pautasso 41
  • 42. Connectors
  • 43. RPC Call Remote Procedure Call  Procedure/Function Calls are the easiest to program with connector.  They take a basic programming language construct and make it available across the network (Remote Procedure Call) to connect distributed components  Remote calls are often used within the client/server architectural style, but call-backs are also used in event-oriented styles for notifications©2010 - Cesare Pautasso 43
  • 44. Hot Folder Write Copy File Transfer (Hot Folder) Watch  Transferring files does not require to modify components Read  A component writes a file, which is then copied on a different host, and fed as input into a different component  The transfers can be batched with a certain frequency©2010 - Cesare Pautasso 44
  • 45. Shared Database Create Read Shared Database Update  Sharing a common database does not require to modify components, if they all can Delete  support the same schema Components can communicate by creating, updating and reading entries in the database, which can safely handles the concurrency©2010 - Cesare Pautasso 45
  • 46. Bus Publish Subscribe Message Bus  A message bus connects a variable number of components, which are decoupled from one another.  Components act as message sources by publishing messages into the bus; Components act as message sinks by subscribing to message types (or properties based on the actual content)  The bus can route, queue, buffer, transform and deliver messages to one or more recipients  The “enterprise” service bus is used to implement the SOA style©2010 - Cesare Pautasso 46
  • 47. Web (RESTful Web services) Get Put Delete Post Web  The Web is the connector used in the REST (Representational State Transfer) architectural style  Components may reliably transfer state among themselves using the GET, PUT, DELETE primitives. POST is used for unsafe interactions.©2010 - Cesare Pautasso 47
  • 48. Software Connectors for SOA RPC ESB WS-* WWW REST©2010 - Cesare Pautasso 48
  • 49. Interface DescriptionLanguages (IDL) WSDL CORBA 1.0 DCOM RPC IDL MIDL IDL Java Interfaces©2010 - Cesare Pautasso 49
  • 50. Component Interoperability  Due to lack of interoperability, it is not always possible to build a distributed system using heterogeneous components Enterprise Java DCOM .NET Beans Objects Assemblies Web Legacy CORBA Services COBOL Objects Programs©2010 - Cesare Pautasso 50
  • 51. Web Services for Interoperability  If the components are published as Web services, they can interoperate across different component frameworks. (Interoperability through Wrapping) Java DCOM .NET Bean Object Assembly Web Legacy CORBA COBOL Object Service Program©2010 - Cesare Pautasso 51
  • 52. Interoperability Component Adapter Adapter Component (Platform A) (Platform A) (Platform B) (PlatformB) Components of different platforms can interoperate through adapters mapping the internal message format to a common (standard) representation©2010 - Cesare Pautasso 52
  • 53. Is this a Web Service?©2010 - Cesare Pautasso 53
  • 54. Web Sites (1992) Web HTML Web Browser HTTP Server WS-* Web Services (2000) SOAP WSDL Client XML Server (HTTP)©2010 - Cesare Pautasso 54
  • 55. RESTful Web Services (2007) PO-XML ATOM JSON WADL Web Client HTTP Server WS-* Web Services (2000) SOAP WSDL Client XML Server (HTTP)©2010 - Cesare Pautasso 55
  • 56. Extending the Web with Services Web Browser WS Client HTML/HTTP SOAP, XML or JSON/HTTP Web Server add your Java ASP CGI PHP favourite Servlet .NET here Back-end Systems and Databases©2010 - Cesare Pautasso 56
  • 57. Defining Web Services  W3C defined Web services in the early 2000s as: a software application identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via the Internet©2010 - Cesare Pautasso 57
  • 58. Properties of Web Services  The W3C definition emphasizes different aspects:  In order to be accessed by clients, a Web Service should be defined, described and discovered.  XML is the foundation for all standards that are going to be used (SOAP, WSDL, UDDI) to do so.  Web services are intended to be used as components that can be readily integrated into more complex distributed applications.  Web services are meant for software based consumption (clients are programs)  Web-based applications are meant to be used by humans equipped with a WWW browser (clients are users)©2010 - Cesare Pautasso 58
  • 59. Web Services and SOA  Web Services can also be seen as the technology used to implement service oriented architectures (SOA)  SOA are about building distributed applications out of the interconnection of loosely coupled, heterogeneous services.  To do so, interoperability is paramount and Web services are meant to deliver it.  In a service oriented architecture services are:  Interoperable – Services seamlessly work with one another and can be easily composed into complex applications  Heterogeneous – Standard service interfaces virtualize the underlying mechanisms and protocols of the middleware platform  Distributed – Services can (in principle) be located across the Web  Autonomous – Services belong to different organizations and may evolve independently of each other  Loosely Coupled – Services should make very few assumptions about one another so that they can be easily moved, replaced and even interact without being available at the same time.©2010 - Cesare Pautasso 59
  • 60. Web Services Architecture  A popular interpretation of Web services is based on IBM’s Web service architecture based on three elements: 1. Service requester: The potential user of a service (the client) 2. Service provider: The entity that implements the service and offers to carry it out on behalf of the requester (the server) 3. Service registry: A place where available services are listed and that allows providers to advertise their services and requesters to lookup and query for services©2010 - Cesare Pautasso 60
  • 61. Web Service Architecture Service Service Service Requester Registry Provider Service Description 1. Publish 2. Lookup 3. Invoke Clients use the Registry to lookup published service descriptions that will enable them to perform the actual service invocation with the provider©2010 - Cesare Pautasso 61
  • 62. Main Web Services Standards  The Web service architecture proposed by IBM is based on UDDI two key concepts:  architecture of existing synchronous middleware platforms  current specifications of SOAP, UDDI and WSDL  The architecture has a remarkable client/server flavor  It reflects only what can be SOAP done with:  SOAP (Simple Object Access Protocol)  UDDI (Universal Description and Discovery Protocol)  WSDL (Web Services WSDL Description Language)©2010 - Cesare Pautasso 62
  • 63. What is SOAP?  The W3C started working on SOAP in 1999. The current W3C recommendation is Version 1.2  Originally: Simple Object Access Protocol  SOAP covers the following main areas:  Message construct: A message format for one-way communication describing how a message can be packed into an XML document  Processing model: rules for processing a SOAP message and a simple classification of the entities involved in processing a SOAP message. Which parts of the messages should be read by whom and how to react in case the content is not understood  Extensibility Model: How the basic message construct can be extended with application specific constructs  Protocol binding framework: Allows SOAP messages to be transported using different protocols (HTTP, SMTP, …) • A concrete binding for HTTP  Conventions on how to turn an RPC call into a SOAP message and back as well as how to implement the RPC style of interaction©2010 - Cesare Pautasso 63
  • 64. HTTP RequestSOAP RPC SOAP Envelope SOAP header Transactional context SOAP Body Name of Procedure Input parameter 1 SERVICE REQUESTER SERVICE PROVIDER Input parameter 2 Procedure RPC call HTTP engine HTTP engine SOAP SOAP engine engine HTTP Response SOAP Envelope SOAP header Transactional context SOAP Body Return parameter©2010 - Cesare Pautasso 64
  • 65. SOAP Request Response XML <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:sayHi xmlns:ns2="http://test.inf.usi.ch/"> <text>World</text> </ns2:sayHi> </soap:Body> </soap:Envelope> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns2:sayHiResponse xmlns:ns2="http://test.inf.usi.ch/"> <result>Hello World</result> </ns2:sayHiResponse> </soap:Body> </soap:Envelope>©2010 - Cesare Pautasso 65
  • 66. What is WSDL?  The Web Services Description Language specification is in version 1.1 (March 2001) and currently under revision (v2.0 is in the candidate recommendation stage, Jan 2006)  WSDL 1.1 discusses how to describe the different parts that comprise a Web service interface  the type system used to describe the service data model (XML Schema)  the messages involved in the interaction with the service  the individual operations composed of 4 possible message exchange patterns  the sets of operations that constitute a service  the mapping to a transport protocol for the messages  the location where the service provider resides  groups of locations that can be used to access the same service  It also includes specification indicating how to bind WSDL to the SOAP, HTTP (POST/GET) and MIME protocols©2010 - Cesare Pautasso 66
  • 67. Elements of WSDL (1.1) WSDL document Abstract description of the service Types (type information for the document, e.g., XML Schema) Message 1 Message 2 Message 3 Message 4 Message 5 Message 6 Operation 1 Operation 2 Operation 3 Port Type (abstract service) binding 1 binding 2 binding 3 binding 4 Concrete description of the service port 1 port 2 port 3 port 4 Service (the interface in all its available implementations)©2010 - Cesare Pautasso 67
  • 68. Hello World WSDL <?xml version=1.0 encoding=UTF-8?> <wsdl:definitions name="HelloWorld" targetNamespace="http://test.inf.usi.ch/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://test.inf.usi.ch/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <xs:schema elementFormDefault="unqualified" targetNamespace="http://test.inf.usi.ch/" version="1.0" xmlns:tns="http://test.inf.usi.ch/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="sayHi" type="tns:sayHi" /> <xs:element name="sayHiResponse" type="tns:sayHiResponse" /> <xs:complexType name="sayHi"> <xs:sequence> <xs:element minOccurs="0" name="text" type="xs:string" /> </xs:sequence> </xs:complexType> <xs:complexType name="sayHiResponse"> <xs:sequence> <xs:element minOccurs="0" name="result" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema> </wsdl:types> <wsdl:message name="sayHiResponse"> <wsdl:part element="tns:sayHiResponse" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="sayHi"> <wsdl:part element="tns:sayHi" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:portType name="Contract"> <wsdl:operation name="sayHi"> <wsdl:input message="tns:sayHi" name="sayHi"> </wsdl:input> <wsdl:output message="tns:sayHiResponse" name="sayHiResponse"> </wsdl:output> </wsdl:operation> </wsdl:portType> <wsdl:binding name="HelloWorldSoapBinding" type="tns:Contract"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="sayHi"> <soap:operation soapAction="" style="document" /> <wsdl:input name="sayHi"> <soap:body use="literal" /> </wsdl:input> <wsdl:output name="sayHiResponse"> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="HelloWorld"> <wsdl:port binding="tns:HelloWorldSoapBinding" name="ServicePort"> <soap:address location="http://localhost:9000/helloWorld" /> </wsdl:port> </wsdl:service> </wsdl:definitions>©2010 - Cesare Pautasso 68
  • 69. Hello World WSDL <?xml version=1.0 encoding=UTF-8?> <wsdl:definitions name="HelloWorld" targetNamespace="http://test.inf.usi.ch/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://test.inf.usi.ch/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <xs:schema elementFormDefault="unqualified" targetNamespace="http://test.inf.usi.ch/" version="1.0" xmlns:tns="http://test.inf.usi.ch/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="sayHi" type="tns:sayHi" /> Types (type information for the document, e.g., XML Schema) <xs:element name="sayHiResponse" type="tns:sayHiResponse" /> <xs:complexType name="sayHi"> <xs:sequence> <xs:element minOccurs="0" name="text" type="xs:string" /> </xs:sequence> </xs:complexType> <xs:complexType name="sayHiResponse"> <xs:sequence> <xs:element minOccurs="0" name="result" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema> </wsdl:types> Request and Response Messages <wsdl:message name="sayHiResponse"> <wsdl:part element="tns:sayHiResponse" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="sayHi"> <wsdl:part element="tns:sayHi" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:portType name="Contract"> <wsdl:operation name="sayHi"> Abstract Port Type and Operations <wsdl:input message="tns:sayHi" name="sayHi"> </wsdl:input> <wsdl:output message="tns:sayHiResponse" name="sayHiResponse"> </wsdl:output> </wsdl:operation> </wsdl:portType> <wsdl:binding name="HelloWorldSoapBinding" type="tns:Contract"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="sayHi"> Concrete SOAP Binding <soap:operation soapAction="" style="document" /> <wsdl:input name="sayHi"> <soap:body use="literal" /> </wsdl:input> <wsdl:output name="sayHiResponse"> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="HelloWorld"> <wsdl:port binding="tns:HelloWorldSoapBinding" name="ServicePort"> Service HTTP Endpoint <soap:address location="http://localhost:9000/helloWorld" /> </wsdl:port> </wsdl:service> </wsdl:definitions>©2010 - Cesare Pautasso 69
  • 70. Hello World WSDL <?xml version=1.0 encoding=UTF-8?> <wsdl:definitions name="HelloWorld" targetNamespace="http://test.inf.usi.ch/" xmlns:ns1="http://schemas.xmlsoap.org/soap/http" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://test.inf.usi.ch/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:types> <xs:schema elementFormDefault="unqualified" targetNamespace="http://test.inf.usi.ch/" version="1.0" xmlns:tns="http://test.inf.usi.ch/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="sayHi" type="tns:sayHi" /> <xs:element name="sayHiResponse" type="tns:sayHiResponse" /> <xs:complexType name="sayHi"> <xs:sequence> <xs:element minOccurs="0" name="text" type="xs:string" /> </xs:sequence> </xs:complexType> <xs:complexType name="sayHiResponse"> <xs:sequence> <xs:element minOccurs="0" name="result" type="xs:string" /> </xs:sequence> </xs:complexType> </xs:schema> </wsdl:types> <wsdl:message name="sayHiResponse"> <wsdl:part element="tns:sayHiResponse" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:message name="sayHi"> <wsdl:part element="tns:sayHi" name="parameters"> </wsdl:part> </wsdl:message> <wsdl:portType name="Contract"> <wsdl:operation name="sayHi"> <wsdl:input message="tns:sayHi" name="sayHi"> </wsdl:input> <wsdl:output message="tns:sayHiResponse" name="sayHiResponse"> </wsdl:output> </wsdl:operation> </wsdl:portType> <wsdl:binding name="HelloWorldSoapBinding" type="tns:Contract"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="sayHi"> <soap:operation soapAction="" style="document" /> <wsdl:input name="sayHi"> <soap:body use="literal" /> </wsdl:input> <wsdl:output name="sayHiResponse"> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="HelloWorld"> result = sayHi(text) <wsdl:port binding="tns:HelloWorldSoapBinding" name="ServicePort"> <soap:address location="http://localhost:9000/helloWorld" /> </wsdl:port> </wsdl:service> </wsdl:definitions>©2010 - Cesare Pautasso 70
  • 71. WSDL as an IDL  WSDL can be best understood when we approach it as an XML version of an IDL that also covers the aspects related to integration through the Internet and the added complexity of Web services  An IDL in conventional middleware and enterprise application integration platforms has several purposes:  description of the interfaces of the services provided (e.g., RPC)  serve as an intermediate representation for bridging heterogeneity by providing a mapping of the native data types to the intermediate representation associated to the IDL in question  serve as the basis for development through an IDL compiler that produces stubs and libraries that can be use to develop the application  A conventional IDL does not include information such as:  location of the service (implicit in the platform and found through static or dynamic binding)  different bindings (typically an IDL is bound to a transport protocol)  sets of operations (since an interface defines a single access point and there is no such a thing as a sequence of operations involved in the same service)©2010 - Cesare Pautasso 71
  • 72. What is UDDI?  Universal Description, Discovery  Originally, UDDI was conceived as an and Integration “Universal Business Registry” similar  Services offered through the to search engines (e.g., Google) which Internet to other companies will be used as the main mechanism require much more information to find electronic services provided by than a typical middleware service companies worldwide. This triggered  In many middleware and EAI a significant amount of activity efforts, the same people develop around very advanced and complex the service and the application scenarios (Semantic Web, dynamic using the service binding to partners, automatic  This is obviously no longer the partner selection at runtime, etc.) case and, therefore, using a  Nowadays UDDI is far more pragmatic service requires much more and recognizes the realities of B2B information than is typically interactions: it presents itself as available for internal company name and directory service (i.e., services binder in RPC) applied to Web  This documentation has three services and mostly used in aspects to it: constrained environments (internally  basic information within a company or among a predefined set of business partners)  categorization  technical data©2010 - Cesare Pautasso 72
  • 73. WS Technology Design Space Representations WS-* REST Many Message Formats (XML, JSON, ATOM, HTML, CSV, …) 1 Message Format (SOAP) 1 Communication “Endpoint” 4 HTTP Verbs Many URIs (GET, PUT, POST, DELETE) Many Operations (WSDL) InterfaceResources©2010 - Cesare Pautasso 73
  • 74. Architectural Decision Modeling Design Issue Architecture Alternatives 1 Communication “Endpoint” 4 HTTP Verbs Many URIs (GET, PUT, POST, DELETE) Many Operations (WSDL)©2010 - Cesare Pautasso 74
  • 75. REST Richardson Maturity Model 0. HTTP as an RPC Protocol (Tunnel POST+POX or POST+JSON) I. Multiple Resource URIs (Fine-Grained Global Addressability) II. Uniform HTTP Verbs (Contract Standardization) III. Hypermedia (Protocol Discoverability) (Decentralized Service Discovery by Referral)©2009-2010 - Cesare Pautasso, Erik Wilde 75
  • 76. RESTful Web Service Example Web Server HTTP Client Database Application Server (Web Browser) SELECT * GET /book?ISBN=222 FROM books WHERE isbn=222 POST /order INSERT INTO orders 301 Location: /order/612 PUT /order/612 UPDATE orders WHERE id=612©2009-2010 - Cesare Pautasso, Erik Wilde 76
  • 77. WS-* Service Example(from REST perspective) Web Server Web Service HTTP Client Application Server Implementation (Stub Object) POST /soap/endpoint return getBook(222) POST /soap/endpoint return new Order() POST /soap/endpoint order.setCustomer(x)©2009-2010 - Cesare Pautasso, Erik Wilde 77
  • 78. Protocol Layering “The Web is the universe of “The Web is the universal globally accessible information” (tunneling) transport for (Tim Berners Lee) messages”  Applications should publish  Applications get a chance their data on the Web to interact but they remain (through URI) “outside of the Web” AtomPub JSON POX … SOAP (WS-*) HTTP HTTP HTTP HTTP HTTP SMTP MQ… GET POST PUT DEL POST (Many) Resource URI 1 Endpoint URI Application Application©2009-2010 - Cesare Pautasso, Erik Wilde 78
  • 79. Is REST really used? Atom, 2% Gdata, 1% XMPP, 0% JavaScript, 6% XML-RPC, 2% SOAP, 17% JSON-RPC, 0% SMS, 2000+ APIs 0% RSS, 1% ProgrammableWeb.com Summer 2010 REST, 71%©2010 - Cesare Pautasso 79
  • 80. Today’s plan Software The Web Architecture (REST) SOA & WS Components Connectors vs. Services and Integration©2010 - Cesare Pautasso 80
  • 81. Looking Back You don’t What is a What is have a Web site? Why do Web your Web you need a site? API?!? Web API? From Tomas Vitvar, Mashups 2010 Keynote The Web WWW Services 1992 2000 2010©2010 - Cesare Pautasso 81
  • 82. Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy, Software Architecture: Foundations, Theory and Practice, John-Wiley, January 2009, ISBN 9780470167748©2010 - Cesare Pautasso 82
  • 83. Gustavo Alonso, Fabio Casati, Harumi Kuno, Vijay Machiraju, Web Services: Concepts, Architectures, and Applications Springer, September 2004, ISBN 3-540-44008-9©2010 - Cesare Pautasso 83
  • 84. More References Christopher Alexander, The Timeless Way of Building, Oxford University Press 1979 Grady Booch, Handbook of Software Architecture, http://booch.com/architecture/ Stewart Brand, How Buildings Learn, Penguin 1987 Thomas Erl, SOA Principles of Service Design, Prentice Hall, 200 Thomas Erl, SOA Design Patterns, Prentice Hall, 2009 Ian Gordon, Essential Software Architecture, Springer 2004 Nicolai M. Josuttis, SOA in Practice: The Art of Distributed System Design, O’Reilly, 2007 Cesare Pautasso, Olaf Zimmermann, Frank Leymann, RESTful web services vs. "big" web services: making the right architectural decision, WWW 2008 Eberhardt Rechtin, Systems Architecting: Creating and Building Complex Systems, Prentice Hall 1991 Process Support for More Than Web Services: www.jopera.org©2010 - Cesare Pautasso 84
  • 85. ©2010 Cesare Pautasso 85

×