1 / 89

SOA Part1 Lecture 2

SOA Part1 Lecture 2. Dr. Withalm 11-Nov-14. Lectures at the University of Bratislava/Autumn 2008. 29.09.2008 Lecture 1 Evolution Of Architectures- The long Way from OO to SOA 13.10.2008 Lecture 2 WEB-Services& Semantic WEB 20.10.2008 Lecture 3 SOA-Technological Basis

aspen-palmer
Download Presentation

SOA Part1 Lecture 2

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. SOA Part1 Lecture 2 Dr. Withalm 11-Nov-14

  2. Lectures at the University of Bratislava/Autumn 2008 29.09.2008 Lecture 1 Evolution Of Architectures- The long Way from OO to SOA 13.10.2008 Lecture 2 WEB-Services& Semantic WEB 20.10.2008 Lecture 3 SOA-Technological Basis 10.11.2008 Lecture 4 SOA-Basing on J2EE 24.11.2008 Lecture 5 SOA-Focus on Business Processes 01.12.2008 Lecture 6 B2B Frameworks and related Standards 15.12.2008 Lecture 7 WEB 2.0 & GRID Dr.Withalm

  3. Today’s Agenda • WEB Services • Example • Standards • Semantic WEB • Example • Ontology • Connection to WS Dr.Withalm

  4. Summary of last lecture • Progress in Architecture are primarily enabled by technology • i.e. distributed computing by PC & Ethernet • Distributed computing encouraged Middle ware • i.e. RPC, CORBA, DCOM-which work efficient in EAI-projects • Middle ware is kept enclosed within companies mainly because of “closed” ports • i.e. most serious obstacle when deploying CORBA applications in IAI projects • EJB tried to combine strenghts of ORB and TP • Overcoming the performance issue which requested huge programming efforts in CORBA applications • EJB made a first “implicit” step towards services • i.e. Session Beans-whenever their focus was mainly IT-focused and not business oriented. Dr.Withalm

  5. Web-ServicesExample/1 • A car rental company has a database that indicates • What kind of cars are available at each location along with the published rental rate • Compact, full-size, luxury, etc. • There is an application function that • When provided with the location and class of car • Returns availability and price. Dr.Withalm

  6. Web-ServicesExample/2 • Originally, this function would have been contained wholly • Within a booking application • Used by the company‘s agents to respond • To telephone requests from customers and travel agents. Dr.Withalm

  7. Web-ServicesExample/3 Dr.Withalm

  8. Web-ServicesExample/4 • The company soon learned, however, that other parts of the organization needed access to this same function. • Since auto rentals are highly competitive in same location • For example :marketing requests direct access to the availability and price function. • So they can quickly respond to competitors moves. • IT is asked to integrate the marketing application with the booking application. Dr.Withalm

  9. Web-ServicesExample/5 • For IT, integrating functions across internal applications is commonplace. • Several client/server technologies evolve to help achieve the architecture. Dr.Withalm

  10. Web-ServicesExample/6 • Then came the Web • Now IT was asked to make the availability and price function available to users over the Internet. • Fortunately, Internet standards emerged to make this possible • The browser is a standard client. • HTTP is a standard communication protocol for the Internet. • HTML provides data functionality that can be interpreted and displayed by browsers. • CGI- and later application servers-provide a way for developers to interface to the application function. Dr.Withalm

  11. Web-ServicesExample/7 • Most of the Web development effort of the late nineties was directed toward making an enterprise‘s application functions • Available directly to customers over the Internet. • But this is not a Web service since it is accessed by a browser user, not a client application. Dr.Withalm

  12. Web-ServicesExample/8 • The next step for the rental car company is to make the availability and price function-and even the booking function • Available not only to browser users • But to the booking applications of other companies • Travel agents cannot browse the Web sites of all potential car rental companies • Looking for the best price. • They need an automated way to access the information and to place a booking. • Web-based travel services need to do this programmatically in response to requests from browser users. Dr.Withalm

  13. Web-ServicesExample/9 • Once the Web services have been developed • The rental car company can announce the availability of the service • Publish their interface specifications • In a directory accessible to everyone in the Web. • This allows potential partners to discover the availability of the rental car Web services. • And provide partners with the information required. • To access the Web services from a client application. Dr.Withalm

  14. Web-ServicesExample/10 • Adding the Web services to an enterprise Web application environment can result in the following architecture • These application functions provide data and services • To both browser users and client applications. Dr.Withalm

  15. Web-ServicesExample/11 Dr.Withalm

  16. Web-ServicesExample/12 • These are the needs driving the development of Web services • Application functions that can be accessed by other applications using Internet technology. • The key elements of this definitions are: • Access to the service is available to applications, not browsers • The standard technologies that enable this access are developed specifically for operations over the Internet. Dr.Withalm

  17. Web-ServicesExample/13 • In some respects Web services are just an updated, Internet enabled way of doing something application developers have always been able to do. • In other ways Web services promise to change the way business is done • And even to enable new kinds of business • Application integration has been around a long time • And there exist mature technologies that can do this. Dr.Withalm

  18. Web-ServicesExample/14 • CORBA, COM, and later DCOM provide facilities • To create application functions with defined and accessible interfaces • And to enable the development of clients • That can access them-even over the Internet. Dr.Withalm

  19. Web-ServicesExample/15 • There are two fundamental advantages by Web services over earlier application integration approaches. • The underlying technology is designed from the ground up to operate over the Web and , in fact, leverages the existing standards that have made the Web successful. • Web services, and the technologies that are used to build them, take openness to a new level. Dr.Withalm

  20. Web-ServicesExample/16 • While earlier approaches made it possible to provide an internal or external partner with the interface definition of an application function • So they could build a compatible client • Web services include the concept of an universal directory • To publish the availability of the service to the entire Internet • And to make it possible for a subscriber to create a client application • That can easily, even dynamically, access the service. • Further, since the standards are widely implemented on most platforms • There is a degree of platform independence (HW, OS, and middleware) not previously available. Dr.Withalm

  21. Web-ServicesExample/17 • In theory, a client can even be made smart enough • To read and interpret the interface specification • And dynamically access the Web service • Web service promise a world in which applications can search the Web for services they need • And access these services in much the same way that browser users use search engines to locate and access Web sites. Dr.Withalm

  22. Web-ServicesExample/18 • That is the vision • The reality is that technology is new • The standards are still evolving • And the Web services being developed tend to be • Simple solutions for simple problems • Most of them are internal integration efforts. • What also is required is • Semantic Web Dr.Withalm

  23. Core Web-Services Standards Dr.Withalm

  24. Other Web Service Standards/1 Business Domain Business Domain Specific Extensions Various Management Distributed Management WSDM, WS-Manageability Provisioning WS-Provisioning Security Security WS-Security Security Policy WS-SecurityPolicy Secure Conversation WS-SecureConversation Trusted Message WS-Trust Federated Identity WS-Federation Portal and Presentation Portal and Presentation WSRP Dr.Withalm

  25. Other Web Service Standards /2 Transactions and Business Process Asynchroneous Services ASAP Transaction WS-Transaction, WS-Coordination Orchestration BPEL4WS, WS-CDL Messaging Events and Notification WS-Eventing, WS-Notification Multiple Message Sessions WS-Enumeration, WS-Transfer Routing / Addressing WS-Addressing, WS-MessageDelivery Reliable Messaging WS-ReliableMessaging, WS-Reliability Message Packaging SOAP, MTOM Metadata Publication and Discovery UDDI, WSIL Policy WS-Policy, WS-PolicyAssertions Service Message Description WSDL Metada Retrieval WS-MetadataExchange Dr.Withalm

  26. Other Web Service Standards /3 Mainstream SOAP WSDL UDDI Early Adoption WS-Security WS-RP WS-Reliability SOAP MTOM Experimentation ASAP BPEL WS-Coordination WS-Policy Specification WS-Addressing WS-Choreography WS-Eventing WS-Federation WS-Provisioning WS-Reliable Messaging WS-Resource Framework WSDM Approved Standards Proposals Dr.Withalm

  27. Web Services - Time to Mature Standards ’01 ’02 ’03 ’04 ’05 ’06 ’07 Transaction, Mgmt. Orchestration, QOS Trust & Security WS-Security, SAML, Foundation XML, SOAP, WSDL, UDDI Uptake Internal Applications Used to integrate internal applications TrustedExternal Parties Used to link with trusted external parties Used to source services on the open market Open Market Becoming established Early use Accepted approach Dr.Withalm

  28. Web Services • A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Dr.Withalm

  29. Portlets/1 • In contrast with Web-Services • which are computer-to-computer services • Presentation Oriented Services provide a user interface • that allows an end-user to interact directly with the service. • Two main standards exist • the JSR 168 specification • and the Remote Portlets specification. Dr.Withalm

  30. Portlets/23WSRP Specification/1 • is a production of OASIS. • Since all of the major players in the portal market are represented on OASIS' WSRP Technical Committee, • the technology should continue to enjoy broad acceptance in the industry. • The OASIS WSRP specification defines a common, well-defined interface • for communicating with pluggable, presentation-oriented Web services. • These services process user interactions and provide mark-up fragments for aggregation by portals. Dr.Withalm

  31. Web Service Standards • OASIS and the W3C are the steering committees responsible for the architecture and standardization of web services. To improve interoperability between web service implementations, the WS-I organization has been developing a series of profiles to further define the standards involved. Dr.Withalm

  32. Web Services – Static & Dynamic Service Flow BPML Service Discovery UDDI Service Publication UDDI DynamicWeb Services Service Description WSDL XML Based Messaging StaticWeb Services SOAP Network HTTP, SMTP Dr.Withalm

  33. Web Service Base Standards/1 • Simple Object Access Protocol (SOAP) - defines the runtime message that contains the service request and response. SOAP is independent of any particular transport and implementation technology. • Web Services Description Language (WSDL) - describes a Web Service and the SOAP Message. It provides a programmatic way to describe what a service does, paving the way for automation. • Universal Discovery, Description, Integration (UDDI) - UDDI is a cross industry initiative to create a standard for service discovery together with a registry facility that facilitates the publishing and discovery processes. Dr.Withalm

  34. Web Service Base Standards/2 Dr.Withalm

  35. Web Service Base Standards/3 Service Registrar Find (UDDI) Publish (UDDI) Define (WSDL) Service Consumer Use (SOAP) Service Provider Dr.Withalm

  36. Web Service Base Standards/4Second generation Web-Services Standards Dr.Withalm

  37. Universal Discovery, Description, Integration(UDDI) • UDDI is a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is an open industry initiative (sponsored by OASIS) enabling businesses to discover each other and define how they interact over the Internet. • A UDDI business registration consists of three components: • White Pages - address, contact, and known identifiers; • Yellow Pages - industrial categorizations based on standard taxonomies; and • Green Pages - technical information about services exposed by the business Dr.Withalm

  38. Simple Object Access Protocol (SOAP) • SOAP originally was an acronym for Simple Object Access Protocol, but the acronym was dropped in Version 1.2 of the SOAP specification. Originally designed by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein in 1998 with backing from Microsoft (where Atkinson and Al-Ghosein worked at the time), the SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium. Dr.Withalm

  39. SOAP (W3C) • SOAP is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message. Dr.Withalm

  40. Sample SOAP Message • <?xml version='1.0' ?> • <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> • <env:Header> • <m:reservation • xmlns:m="http://travelcompany.example.org/reservation" • env:role="http://www.w3.org/2003/05/soap-envelope/role/next" • env:mustUnderstand="true"> • <m:reference> • uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d • </m:reference> • <m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime> • </m:reservation> • <n:passenger xmlns:n="http://mycompany.example.com/employees" • env:role="http://www.w3.org/2003/05/soap-envelope/role/next" • env:mustUnderstand="true"> • <n:name>Åke Jógvan Øyvind</n:name> • </n:passenger> • </env:Header> Dr.Withalm

  41. Sample SOAP Message (cont.) • <env:Body> • <p:itinerary xmlns:p="http://travelcompany.example.org/travel"> • <p:departure> • <p:departing>New York</p:departing> • <p:arriving>Los Angeles</p:arriving> • <p:departureDate>2001-12-14</p:departureDate> • <p:departureTime>late afternoon</p:departureTime> • <p:seatPreference>aisle</p:seatPreference> • </p:departure> • <p:return> • <p:departing>Los Angeles</p:departing> • <p:arriving>New York</p:arriving> • <p:departureDate>2001-12-20</p:departureDate> • <p:departureTime>mid-morning</p:departureTime> • <p:seatPreference/> • </p:return> • </p:itinerary> • </env:Body> • </env:Envelope> Dr.Withalm

  42. Web Services Description Language(WSDL) • WSDL is an XML format published for describing Web services. • WSDL describes the public interface to the web service. This is an XML-based service description on how to communicate using the web service; namely the protocol bindings and message formats required to interact with the web services listed in its directory. The supported operations and messages are described abstractly, and then bound to a concrete network protocol and message format. • WSDL is often used in combination with SOAP and XML Schema to provide web services over the internet. A client (program) connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. Dr.Withalm

  43. WSDL Elements/1 Element Name Description types a container for abstract type definitions defined using XML Schema message A definition of an abstract message that may consist of multiple parts, each part may be of a different type portType An abstract set of operations supported by one or more endpoints (commonly known as an interface); operations are defined by an exchange of messages binding A concrete protocol and data format specification for a particular portType service A collection of related endpoints, where an endpoint is defined as a combination of a binding and an address (URI) Dr.Withalm

  44. Platform Independent: This view represents the abstract portion of the WSDL: Definitions Service PortType(s) Messages Parts PartType(s) Platform Specific Model: This phase completes the bindings section of the WSDL: Service Ports Binding(s) WSDL Elements /2 Dr.Withalm

  45. WSDL - Binding • A service can support multiple bindings for a given interface, but each binding should be accessible at a unique address identified by a URI, also referred to as a Web service endpoint . • Usually this information from the WSDL is used to implement late binding. Messages Tcp Smtp Http URI URI URI Service Interface Interface operationoperationoperation operationoperationoperation Dr.Withalm

  46. Semantic Web • Semantics: Meaning of a word, a sentence or a text • The existing web consists of data, • which is readable for machines • which should – in the future – be made understandable and interpretable for machines Dr.Withalm

  47. Motivation for Semantic WEB/1 • Task: Find and buy specific audio CD on the web • At present: • "clicking" from one web-shop to the next • performing the same search on each site • comparing the prices • A SW-agent is currently unable to find CD-retailers on the web • If it has a list of retailers, there is another problem: • How shall it search the site for relevant offers? Dr.Withalm

  48. Motivation for Semantic WEB/2 • Problems of the search request: • Over HTTP and URL, but how exactly? • Is there a search-function implemented in the site? • If yes, with which URI should the request be placed? • What are the parameter names? • HTTP-transmission over GET- or POST-method? Dr.Withalm

  49. Motivation for Semantic WEB/3 • Problems with the received answer: • Humans see the web-page as more or less beautifully designed • It contains the price of the CD, but where? • The SW-agent is unable to find it out • If it would be programmed to find it in line 3, column 5? • What happens if the layout is changed? Dr.Withalm

  50. Solutions/1 • Parts of the HTML-code could be made interpretable for the agent with the help of XML • If tags like <price> ... </price> were added to the HTML elements, the agent could recognize the requested data • W3C recommends the XML-schemata for establishing the required vocabulary Dr.Withalm

More Related