1 / 194

(Semantic) Web Services

(Semantic) Web Services. M.-S. Hacid University Claude Bernard, Lyon – France http://www710.univ-lyon1.fr/~dbkrr. Outline. Evolution of MIS/DSS Enterprise Applications Integration (EAI) Web Services Semantic Web Semantic Web Services Conclusion. History.

norris
Download Presentation

(Semantic) Web Services

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. (Semantic) Web Services M.-S. Hacid University Claude Bernard, Lyon – France http://www710.univ-lyon1.fr/~dbkrr

  2. Outline Evolution of MIS/DSS Enterprise Applications Integration (EAI) Web Services Semantic Web Semantic Web Services Conclusion

  3. History The information processing profession is historically immature because it has existed only since the early 1960s. Classical Operational Information Systems: - How much an account balance is, right now? - How much is an inventory, right now? - What the status of a shipment is, right now? But there is a real value in looking at and integrating information over the spectrum of time as well

  4. History (Cond.) DSS is at the end of a long and complex evolution but continues to evolve. 1960 • master files • programs (Cobol) • reports

  5. History (Cond.) 1965 Lots of master files!!! • complexity of • maintenance • development • synchronization of data • hardware

  6. 1975 History (Cond.) DASD DBMS 1970 database – ’’ a single source of data for all processing’’ Online, High-performance Transaction Processing

  7. History (Cond.) 1980 MIS/DSS tx processing PCs, 4GL technology

  8. History (Cond.) 1985 OLTP extract program Why extract program? - Performance - Control

  9. History (Cond.) ’’spider web’’ 1990

  10. History (Cond.) Problems with Naturally Evolving Architecture: - credibility of data - productivity - inability to transform data into information

  11. History (Cond.) Lack of Credibility of Data: Dept. A +10% activity up Dept. B -15% activity down

  12. History (Cond.) No time basis of data Dept. A: +10% Sunday evening Dept. B: -15% Wednesday pm

  13. History (Cond.) Algorithmic differential Dept. A has chosen to analyze all old accounts Dept. B has chosen to analyze all large accounts Is there any necessary correlation between the characteristics of customers who have old accounts and customers who have large accounts? Probably NOT!

  14. History (Cond.) Levels of extraction Many levels of extraction being done from the time data enters the corporation’s system to the time analysis is prepared for management

  15. History (Cond.) Dept. A: +10% Sunday evening old accts Dept. B: -15% Wednesday pm large accts

  16. History (Cond.) External data With today’s technologies at the PC level, it is easy to bring in data from outside sources

  17. Wall Street journal Business Week History (Cond.) Dept. A: +10% Sunday evening old accts Dept. B: -15% Wednesday pm large accts

  18. History (Cond.) No common source of data Analysis of department A originates from files XY Analysis of department B originates from databases XUVW Nosynchronization or sharing of data between XY and XUVW!

  19. History (Cond.) Wall Street journal Dept. A: +10% Sunday evening old accts Dept. B: -15% Wednesday pm large accts Business Week

  20. Locate data : 9-12 months Get data : 15-24 months History (Cond.) Problem with productivity To produce a corporate report  locate and analyze the data for the report  lots of files to explore

  21. A Change in the Approach Enterprise Applications Integration Data Warehouse Web Services Semantic Web Services

  22. Enterprise Applications Integration (EAI) What is EAI? Enterprise Applications Integration is a solution that supports real-time seamless access to information resident in a variety of repositories. Business processing logic is extracted from application code and placed into an EAI tool where it is graphically represented and manipulated.

  23. Today’s Business Reality BFDI E-Commerce 15 SAP 14 17 DRP 2 16 3 11 9 Customer Call Email CBCF BW Financials 12 Computer Telephony 6 Customer Call COPS 1 JDA 7 BW Tax System Computer Telephony 6 COPS 1 JDA 7 1 ? 13 10 4 5 8 BFDI 14 E-Commerce 1 13 10 15 SAP 4 5 8 14 BFDI 14 E-Commerce 17 DRP 15 SAP 2 14 16 3 11 17 9 DRP 2 Email 16 CBCF Financials 3 11 12 9 Email CBCF Financials Tax System 12 Tax System Customer Call BW Computer Telephony 6 COPS 1 Customer Call JDA 7 BW Computer Telephony 6 COPS 1 1 13 10 JDA 4 7 5 8 BFDI 14 E-Commerce 15 SAP 1 13 10 4 14 5 8 BFDI 17 14 DRP E-Commerce 2 15 SAP 16 14 3 11 Customer Call 9 BW 17 DRP Computer Telephony 2 Email 6 CBCF Financials 16 COPS 1 12 3 11 JDA 7 9 Email Tax System CBCF Financials 12 1 13 10 4 5 8 BFDI 14 Tax System E-Commerce 15 SAP 14

  24. Why EAI? The needs for AI stem primarily from the following business and technical objectives: 1. Integrate with outside partner/customer (as part of a merger) or a «net new» entity, which varies widely from a new set of e-commerce applications to supply chain integration. 2. Migrate towards a customer centric operating model to gain additional Insights in customer behaviors and identify new revenue streams and cross-selling opportunities. 3. Isolate components of huge monolithic systems so they can be replaced or retired because the legacy systems become un-maintainable. 4. Layer an end-user application (especially portals, CRM, and Web-based self-service) that must access data across multiple systems and/or databases. 5. Lower total cost of ownership by reducing system management complexity and maintenance costs.

  25. EAI provides a structured and efficient way to integrate not only the applications but also the business process. EAI solutions offer the following unique benefits: 1. Reduced developmentand maintenance cost (separation of business logic from transaction processing capability…). 2. Enhanced performanceandreliability (asynchronous messaging mechanisms…). 3. Centralized information bus (unification of isolated applications…). 4. Extension of legacy system lifecycle. 5. Reduced time to market (customize existing business rules and extend application functionality).

  26. Enterprise Integration Solution Supplier Customer BusinessProcess Management(BPM) Reseller Exchange EAI B2Bi B2Bi Distributor Mfg. BSP PackagedApps CustomApps LegacyApps AppServers Service BSP Logistics BSP Mediate the interactions between the applications to integrate

  27. Customers, Distributors, Resselers • Community • Content • Commerce • Web Site • Profiling • Personalization • Customization Distribution Channels Data Rules Engine Data Customer Service Relationship Business Process Integration Product/Customer Analysis Customer Service • CRM • Call Center • eMail • Instant Messaging Information Systems • Data Warehouse • Data Analysis • Targeted Marketing Message Routing & Transformation Message Transport Data Data Rules Metadata • Payroll • HR • Benefits • Etc. Operational Systems Partners • Order Management • Warehouse Management • Backend Support • Billing. Data Data

  28. Web Services We look at Web services as a way to expose the functionality of an information system and make it available through standard web technologies. The use of standard technologies reduces heterogeneity, and is therefore key to facilitate application integration. Web services represent the first concerted effort that has gathered wide support for standardizing interactions across information systems. • Difficulties of integrating applications across the Internet: • Firewalls • Lack of standardized protocols • Need for loosely-coupled interactions • Etc.

  29. Web Services and their Approach to Distributed Computing (main ingredients of Web services) Defining Web services Generic definition A Web service is seen as an application accessible to other applications over the Web [Fisher 2002, Menasce and Almeida 2001].  Anything that has a URL is a Web service (ex. cgi script) A program accessible over the Web with a stable API, published with additional descriptive information on some service directory. M. Fisher. Introduction to Web Services. Part of the Java Web Services Tutorial. Aug. 2002. http://java.sun.com/webservices/docs/1.0/tutorial/. D. Menasce and V. Almeida. Capacity Planning for Web Services. Prentice Hall, 2001.

  30. Definition by UDDI Consortium A Web service is considered as a self-contained, modular business application that has open, Internet-oriented, standards-based interface. ? Published interface that can be invoked across the Internet

  31. Definition by W3C «A software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and descovered as XML artifacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged Internet-based protocols» [W3C 2002] Should be advertised so that it is possible to write clients that bind and interact with them. Part of Web technology. Data format used for many Web-based interactions. W3C. Web Services Architecture Requirements. October 2002. http://www.w3.org/TR/wsa-reqs/.

  32. Another Definition [Jupitermedia Corporation] • A standardized way of integrating Web-based applications using the XML, • SOAP, WSDL, and UDDI open standards over an Internet protocol backbone • XML is used to tag the data • SOAP is used to transfer the data • WSDL is used for describing the services available • UDDI is used for listing what services are available Jupitermedia Corporation. Webopedia: Online Dictionary for Computer and Internet Terms. http://www.webopedia.com/.

  33. Example: B2B integration Customer Supplier Web server Internal procurement requests Internal infrastructure Internal infrastructure B2B interactions occur by accessing Web pages, filling Web forms, or via email. Warehouse Web server Internal infrastructure • Automation is driven by the goals: • Lower costs • Streamlined and more efficient process • Ability to monitor and track process executions • Ability to detect and manage exceptions

  34. Limitations of Conventional Middleware in B2B Integration third party A ’’global’’ workflow is executed here (drives the whole business process) • Where to put the middleware? • Trust • Confidentiality • Autonomy WfMS The combination of message broker and adapters enables interoperability WfMS adapter message broker supplier customer Supplier’s adapters Customer’s adapters warehouse Internal infrastructure Internal procurement requests Internal infrastructure Warehouse’s adapters Internal infrastructure

  35. The Web brought • Standard interaction protocols (HTTP) • Data formats (XML) Adopted by many companies Creation of a basis for establishing a common middleware infrastructure that reduces the heterogeneity among interfaces and systems.

  36. B2B integration with Web Services Three main aspects • Service-oriented architectures. • Redesign of middleware protocols. • Standardization.

  37. Service-oriented paradigm Assumption The functionality made available by a company will be exposed as a service A service is a procedure, method, or object with a stable, published interface that can be invoked by clients Requesting and executing a service involves a program calling another program Services are loosely-coupled

  38. Middleware protocols Web services  redesign of the middleware protocols to work in a peer-to-peer fashion and across companies. In conventional middleware: lack of trust and confidentiality issues often make a case against a central coordinator. needs to be redesigned to allow more flexibility in terms of locking resources.

  39. Standardization In conventional application integration: CORBA and Java enabled the development of portable applications. Service-oriented architecture Redefinition of middleware protocols standardization Not sufficient OASIS (Organization for the Advancement of Structured Standards) W3C B2B integration is what generated the need for web services

  40. It is possible to make web services available to clients residing on a local LAN Languages and protocols standardized, eliminating need for many different middleware infrastructures (need only the web services middleware) Customer Supplier Web service Web service Internal procurement requests Internal infrastructure Internal infrastructure Interactions based on protocols redesigned for peer to peer and B2B settings Warehouse Web service Internal functionality made available as a service Internal infrastructure However, the challenge and ultimate goal of web services is inter-company interactions (a long-term goal!) No centralized coordination!

  41. Web Services Technologies • The first required issues: • What exactly a service is? • How it can be described? Service description in conventional middleware is based on interfaces and interface definition languages (IDL). • Implicit context: • Clients and services are developed by the same team. • Semantics of operations + order of invocation known in advance. • The middleware platform defines and constrains many aspects of the service • description and binding process. In web services and B2B interaction  no such implicit context! service descriptions must be richer and more detailed.

  42. Service description and discovery stack Non-functional properties e.g., return policy, QoS,.. (UDDI) Properties and semantics Order in which to execute operations by a client (WSCL, BPEL) A language for specifying URI and transport protocol (HTTP) (WSDL) Business protocols Interfaces Common base language Meta language for specifying all aspects of services (XML) WSDL: Web Services Description Language WSCL: Web Services Conversation Language BPEL: Business Process Execution Language UDDI:Universal Description, Discovery and Integration

  43. Service discovery • At design-time (static binding) • At run-time (using dynamic binding techniques)

  44. Service interactions (a set of abstractions and tools that enable interactions among services) WS-transaction Middleware properties (horizontal protocols) WS-coordination Protocol infrastructure (meta-protocol) WS-security SOAP Basic and secure messaging Transport

  45. Combining Web Services : Composition Web service PC manufacturers (latest prices) RequestQuote Customer Shippers (delivery schedules) Reseller of personal computers

  46. Web Services Architectures Web services are a way to expose internal operations so that they can be invoked through the web. • Centralized brokers • Route messages • Provide properties to the interactions • Logging • Transactional guarantees • Name and directory services • reliability Company A (provider) Company D (client) Web service client Web service interface Access to internal systems Web service Internal architecture External architecture Web service Web service middleware Company C (provider) internal service internal service Web service Web service Service composition infrastructure Supports the definition and execution of composite services Company B (provider) • Protocol infrastructure • Coordinates the interaction among web services • Implements the peer to peer protocols

  47. Internal Architecture of a Web Service other tiers service interface The basic components of each middleware instance reside on a LAN and the resulting application also runs on the same LAN. integration logic middleware service interface service interface integration logic integration logic middleware middleware resource manager resource manager resource manager resource manager

  48. External Architecture of a Web Service Wrapping internal functionality as a Web Service  brokers and workflow management systems in the case of conventional middleware External middleware for web services  where this middleware should reside? Two solutions: 1. Implement the middleware as a peer-to-peer system (appealing but problem of reliability and trustworthiness) 2. Introduce intermediaries or brokers acting as the necessary middleware.

  49. Company A (service requester) Company B (service provider) Web service client Web service 3. interact Web service middleware (internal) Web service middleware (internal) other tiers other tiers 2. find 1. Publish the service description The abstraction and infrastructure provided by the registry are part of the external middleware Service descriptions Company C (directory service provider)

  50. Basic Web Services Technology • Web services architectures are mainly based on three components: • The service requester • The service provider • The service registry Thereby closely following a client/server model with an explicit name and directory service • Basic infrastructure necessary to implement web services: • A way to communicate (SOAP) • A way to describe services (WSDL) • A name and directory server (UDDI) Core of web services

More Related