Service Oriented Architectures and Semantic Web Processes
Total Page:16
File Type:pdf, Size:1020Kb
Wright State University CORE Scholar The Ohio Center of Excellence in Knowledge- Kno.e.sis Publications Enabled Computing (Kno.e.sis) 2004 Service Oriented Architectures and Semantic Web Processes Francisco Cubera Kunal Verma Amit P. Sheth Wright State University - Main Campus, [email protected] Follow this and additional works at: https://corescholar.libraries.wright.edu/knoesis Part of the Bioinformatics Commons, Communication Technology and New Media Commons, Databases and Information Systems Commons, OS and Networks Commons, and the Science and Technology Studies Commons Repository Citation Cubera, F., Verma, K., & Sheth, A. P. (2004). Service Oriented Architectures and Semantic Web Processes. https://corescholar.libraries.wright.edu/knoesis/62 This Tutorial is brought to you for free and open access by the The Ohio Center of Excellence in Knowledge-Enabled Computing (Kno.e.sis) at CORE Scholar. It has been accepted for inclusion in Kno.e.sis Publications by an authorized administrator of CORE Scholar. For more information, please contact [email protected]. Service Oriented Architectures and Semantic Web Processes Jorge Cardoso1, Francisco Curbera2, Amit Sheth3 1University of Madeira (Portugal) 2IBM T.J. Watson Research Center (USA) 3 LSDIS Lab, University of Georgia and Semagix, Inc (USA) 2 Service Oriented Architectures and Web Services Semantic Web Processes 2 3 Semantic Web Processes Part 3 Service Oriented Architectures and Web Services 5 Overview z IT for a new business model z Service Oriented Architectures (SOAs). z Web services as an XML based instantiation of SOA. z Protocols. z Metadata. z Discovery. z Composition. z Summary. 5 6 A New Business Environment z Business outsource every non-essential function. z Concentrate on core function and values. z Vertically integrated enterprises are being broken apart z Replaced by heavily networked ones. z Applications that used to be internal are now provided by outside parties. z Corporate boundaries become fuzzier. z Does today’s IT models support the new business environment? z IT is too centered on IT! z When enterprises where islands this was sort of OK. z Today it is vital to adapt the computing model to the business interaction model. 6 7 Enterprises as IT Islands Value added networks and proprietary protocols support most B2B interactions Ad-hoc bridges support interorganizational interactions. Most application interactions take place inside the enterprise. Most applications belong to a single administrative domain. 7 8 Fully Networked Enterprises Web based interactions become pervasive, based on standard protocols The frequency of external interactions and their reach inside the Internal applications enterprise increases seamlessly reach out of dramatically. the enterprise. Interacting applications naturally belong to multiple administrative domains. 8 Fully Networked Business 9 Interactions The distinction between internal and external applications and providers looses importance Many potential providers can be found for each required function. 9 10 IT for the New Enterprise: Business Components z Need to raise the level of IT abstractions. z Concentrate on business function and requirements. z Need to encapsulate business function to make it available to partners: service components. z Different level granularity – coarse grained business services vs. fine grained objects. z Services must be defined by explicit contracts to allow independent party access. z Consequence is automatic binding. z Core concern of business is to integrate business processes and functions. z Business components are integrated creating service compositions. z New value is created through integration/composition. z New components are recursively created. 10 11 Business Interactions z Business interact over standard protocols. z Businesses interact as peers: z Interactions are not client-server. z They are “conversational” in nature: asynchronous, stateful, bidirectional. z Business interactions are often multi-party interactions z Business process integration model is intrinsically multi-party. z Distributed multi-party interactions are a cornerstone of advanced enterprise integration: z Making distributed computing truly distributed. 11 12 What About The SOA Triangle? z Standard protocols augment the pool of technically compatible services. z Explicit contracts allow automatic discovery. z Central registries build on registered contracts extend the reach of the enterprise both as provider and consumer of business services. 12 13 Traditional Middleware z Distributed object systems z Based on client-server paradigm. z Heavily asymmetric Client interaction model. JNDI z Biased towards synchronous protocols. z Assigns public interfaces to Server network accessible objects. Name=A? A z Supports “name-oriented” object discovery. Client Client 13 14 Service Oriented Middleware z Service interactions z Peer to peer by nature. z Symmetric interaction Service model. Registry D z Mixes synchronous and asynchronous protocols. Server z Assigns public contracts QoS=A/B? to network accessible Iface=I A etc… objects. Service Service B C z Supports capability based service discovery. 14 Coupling Between 15 Applications z Interacting applications are bound by the set of assumptions each one Explicit contract makes about the other: z What message formats can be sent/received z Constraints on how content of these messages z Sequencing information. z Required QoS characteristics of the Implicit contract interaction. 15 16 Tight and loose binding z Tight coupling leads to monolithic and brittle distributed applications. Explicit contract z Even trivial changes in one component lead to catastrophic breaks in function. z Small changes in one application require matching changes in partner applications. z Lack of componentization and explicit contracts. Broken implicit contract 16 17 A Plan for Building a SOA z Requirement #1: Interaction protocols must be standardized. z Need to ensure the widest interoperability among unrelated institutions. z Requirement #2: Make all contracts explicit. z Explicit contracts define what may be changed in an application without breaking the interaction. z It is hard or impossible to make all assumptions explicit, but the more the better. z Requirement #2 : Standardize contract language(s) and formats. z Standard metadata is the basis of interoperable contract selection and execution. z Requirement #3: Allow for points of variability in the contract. z Dynamic adaptation on variability points. z Increases the number of possible interactions supported. z Requirement #4: Provide native composition models and runtimes. 17 Web Services As a SOA SOA and Web Services Where Are We on Web 19 Services? BPEL4WS Composition WSDL, WS-Policy, UDDI, Inspection Description Reliable Security Transactions Quality Messaging of Service SOAP (Logical Messaging) Other protocols Interaction Other services Interaction XML, Encoding 19 Protocols SOA and Web services 21 Protocols z Provides a common set of universally supported interaction protocols. z A basic messaging layer z SOAP z Easily extensible, allows QoS protocols to be defined on top. z Some basic QoS protocols: z Basic requirements of business interactions. z Provide guarantees z Message Reliability, WS-ReliableMessaging z Coordination and transactional interactions. z Message integrity, confidentiality 21 22 SOAP (v1.1) z A lightweight XML-based mechanism for exchanging structured information between peers in a distributed environment. z A transport-independent messaging model. z Transport bindings for HTTP z An encoding model for a type system, and an RPC convention: a link to “legacy middleware”. z Built around a standard message format: z Envelope z Headers z Body z Possibly attachments. 22 23 SOAP Messaging Service Requestor Service Provider Application Application web service 1 4 3 2 SOAP Middleware SOAP Middleware Network Protocol Network Protocol Response Request (service invocation) 23 24 SOAP over HTTP POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV… SOAP-ENV:encodingStyle=“…/> <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <po:PlacePurchaseOrder xmlns:po=…> <OrderDate>02/06/01</OrderDate> <Ship_To> … </po: PlacePurchaseOrder > </SOAP-ENV:Body> </SOAP-ENV:Envelope> 24 25 SOAP Headers z Headers are managed and consumed by the Web services middleware infrastructure. z Headers support middleware protocols such as security, transactions, reliability, provisioning, etc. z Extensible nature allows message to endowed with be an extensible set of QoS protocols. z Header attributes z actor z Indicates the intended recipient of the header z http://schemas.xmlsoap.org/soap/actor/next z mustUnderstand z encodingStyle z Identifies serialization rules 25 26 SOAP Body and Attachments z Body: belongs and is processed by the application level. z Is the only part that should be visible by the application logic. z Business modeling is the modeling deals with what goes in the body and how it is processed and exchanges. z A separation that shows up in WSDL, BPEL4WS as well. z Attachments: Not all data can be conveniently placed within an XML document z SOAP Messages with Attachments: How to carry a SOAP envelope within a MIME Multipart/Related structure z SOAP envelope must be the root part 26 z Type is text/xml z Uses href attribute to reference parts 27 SOAP Status z SOAP 1.2/XML Protocol is now a W3C