WWW Architecture II. Software Architecture VO/KU ( / ) Denis Helic, Roman Kern. KMI, TU Graz. Dec 5, 2012

Transcription

1 WWW Architecture II Software Architecture VO/KU ( / ) Denis Helic, Roman Kern KMI, TU Graz Dec 5, 2012 Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

2 Section Recap Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

3 Recap Open-Closed Principle All software changes during its life cycle Programmers face ever changing functional requirements But need to design software that is stable (i.e. does not change) Software entities should be open for extension, but closed for modification by B. Meyer Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

4 Design by contract Design by contract Its a contract between a class and its clients (other classes that use it) Specifies rules that need to be satisfied by the class and by the clients Preconditions and postconditions for methods, invariants for the class Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

5 Single Responsibility Principle Single Responsibility Principle An entity (an object, a class) should have only a single responsibility A responsibility is in fact a reason to change An entity should have only single reason to change Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

6 DRY Principle DRY Principle - Don t Repeat Yourself Every piece of knowledge must have a single, unambiguous, authoritative representation within a system Avoid copy an paste of code But also applies to other artefacts (e.g. documentation, test files,...) Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

7 Law of Demeter Law of Demeter A method of an object should only invoke methods of: 1 Itself 2 Its parameters 3 Objects it creates 4 Its members Methods should not invoke methods of other objects members Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

8 Outline 1 Web Services 2 Web Service Architectures 3 Resource Oriented Architectures 4 Service Oriented Architectures Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

9 Section Web Services Web Services Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

10 Web Services Web as a database The Web we use is full of data Book information, opinions, prices, arrival times, blogs, tags, tweets, etc. The data is organized around a simple data model: node-link model Each node is a data item that has a unique address and a representation Representation formats are e.g. HTML, PDF,... for humans, or e.g XML, JSON for programs Nodes can be interlinked using their unique addresses Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

11 Web Services Web as a platform for distributed systems The Web is full of services that allow humans and programs to use the Web data Service also have unique addresses They use a particular representation for data exchange, e.g. XML, SOAP, WSDL Services follow a particular architecture that defines how services are used Programmers combine a number of services to achieve a desired functionality and create a distributed system, e.g. mashups Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

12 Types of services Web Services What is the Google search engine? It is a service for querying a massive database (Web search index) What is a given Web application? It is a service offering (remotely) a specific functionality What is a Web site? It is a service offering specific human consumable information Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

13 Web Services Types of services All of these services are for users However, we are interested in services for programmers Such services provide an API Programmers use the API, unique addresses, representations of services Programmers follow the arch. style to integrate and combine services to achieve a desired functionality We will call this part of the Web: the programmable Web Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

14 Web Services Kind of Things on the Programmable Web There are numerous approaches to web services in all areas The programmable Web is based on HTTP for data transport and in most cases XML for data representation However, some services serve HTML, JSON, plain text, binary data, etc. Also, other things such as addressability or APIs are different We need a classification! Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

15 Web Services Classification based on architectural design Which operation should a service execute? This is method information What data should be manipulated? This is scoping information Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

16 Web Services Method information Question: how the client conveys its intention to the server? How does a server know a certain request is a request to retrieve some data? Instead of a request to delete the same data? Why should the server do this instead of doing that Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

17 Section Web Service Architectures Web Service Architectures Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

18 Web Service Architectures Competing Architectures Resource-Oriented Architectures (RESTful) RPC-Style Architectures (SOA) REST-RPC Hybrid Architectures Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

19 Web Service Architectures Resource-Oriented Architectures Resource-Oriented Architectures Descriptive URLs URLs reflect the application state Inherit semantic from HTTP methods Should be stateless Limited by its simplicity (limited HTTP methods,...) Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

20 Web Service Architectures RPC-Style Architectures RPC - Remote Procedure Call An RPC style service receives an envelope full of data from the client The service answers with a similar envelope again full of data to the client Both method and scoping information are inside of the envelope HTTP methods typically POST but sometimes also GET Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

21 Web Service Architectures RPC-Style Architectures The best example of the envelope format is SOAP There exist other envelope formats like XML-RPC Every RPC-style service defines a completely new vocabulary E.g. the way how method information and scoping information are represented You need another language to define the representation: e.g. WSDL Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

22 Web Service Architectures Problems of RPC-Style Architectures RPC implies an API APIs tend to enforce tight coupling of modules and systems We use declarative XML to describe APIs This introduces processing overhead Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

23 Web Service Architectures REST-RPC Hybrid Architectures REST-RPC Hybrid Architectures Inherit parts from REST and RPC style architectures Used by many Web Site for their API (e.g. Flickr, del.icio.us,...) Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

24 Section Resource Oriented Architectures Resource Oriented Architectures Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

25 Resource Oriented Architectures Resource Oriented Architectures 4 defining features of ROA Addressability: the scoping information is kept in the URL Uniform interface: the method information is kept in the HTTP method Statelessness: every HTTP request is isolated from other requests Connectedness: you link resources into the Web of resources Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

26 Resource Oriented Architectures Addressability Resources are exposed through URLs - an application exposes a number of URLs When you have URLs you bookmark, cache responses, chain URLs,... Many Web applications do not work this way, i.e. they are not addressable, e.g. GMail Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

27 Resource Oriented Architectures Uniform interface Standardized HTTP methods: CRUD operations (Create, Retreive, Update & Delete) Two principles Safety: GET only reads data Idempotence: the same operation has the same effect whether you apply it once or multiple times Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

28 Resource Oriented Architectures Statelessness Every request contains all necessary information There is no state managed on the server side In fact, there are two kinds of state You should distinguish between the application state and resource state Application state lives on the client Resource state lives on the server Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

29 Resource Oriented Architectures Statelessness When you use a search engine your current query and your current page belongs to application state They are different for every client Resource state is same for every client, i.e. search index A crawler can update the search index Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

30 Resource Oriented Architectures Links and connectedness Representations of resources, i.e. HTML or XML might have links to other resources Axiom for ROA services: Hypermedia as the engine of application state The current application state is not stored on the server as a resource state It is tracked by the client as an application state and created by the path that client takes through the Web Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

31 Resource Oriented Architectures Links and connectedness For example The first page is the starting application state You have links to other application states Obvious for the human Web Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

32 Resource Oriented Architectures Links and connectedness <Buckets> <Bucket> <Name>crummy.com</Name> <URL> <CreationDate>...</CreationDate> </Bucket>... </Buckets> Following the link in the URL element takes the client to a new application state Use links, links, and then use more links,... Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

33 Resource Oriented Architectures Designing ROA Figure out data set Split the data set into resources Then, for each resource Name the resources with URLs Expose a subset of the uniform interface Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

34 Resource Oriented Architectures Designing ROA Design representations accepted from the client Design representations served to the client Integrate this resource into other resources using links Consider possible application states Consider possible error states Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

35 Resource Oriented Architectures Example Application similar google maps: maps of cities, streets, planets,... Data set: Maps, points, cities, planets,... Resources: list of resources, individual resources, results of algorithms applied to the data set Example resources: the list of planets, Mars, Earth, San Francisco, Inffeldgasse,... An algorithmic resource: a list of places that match certain criteria - all cities with more than 1 million of people Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

36 Resource Oriented Architectures Example Name the resources: create meaningful URLs Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

37 Resource Oriented Architectures Example Design representations A representation talks about resource state A representation links to other (application and resource) states Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

38 Resource Oriented Architectures Read/Write ROA systems User accounts should be resources To access these resources you need to use HTTP authentication Connect with the previous resources: e.g. custom places on a map Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

39 Resource Oriented Architectures Method Semantic in ROA systems The HTTP method implies the semantics Use GET to retrieve (read the content) GET Use PUT to write (modify the content) PUT + Content Use DELETE to write (remove the resource) DELETE limited to the methods supported by HTTP Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

40 Resource Oriented Architectures REST REST (Representational State Transfer) No strict typing Typically XML as data format Concepts (RESTful) describes constrains: client-server, stateless, cacheable, layered system, code on demand, uniformity Nowadays, REST is often used a umbrella terms for related architectures Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

41 Resource Oriented Architectures RESTful frameworks Ruby on Rails with a plugin Django in Python Restlet in Java ( Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

42 Section Service Oriented Architectures Service Oriented Architectures - SOA Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

43 Service Oriented Architectures Facts about SOA SOA is the only thing Chuck Norris can t kill. SOA invented the internet, and the internet was invented for SOA. The first rule of SOA is you do not talk about SOA. One person successfully described SOA completely, and immediately died. Taken from: Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

44 Service Oriented Architectures Motivation for Services Loose coupling separation of service and client Service has a contract and a schema Orchestration a service is part of a bigger system Reuse by language independent and platform independent protocols Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

45 Service Oriented Architectures Components of SOA Components of SOA Services - basic components which provide functionality Service repository - used for discovery of services Service bus - interconnect the components of SOA Workflow engine - often used in SOA to orchestrate services Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

46 Service Oriented Architectures Standards for Web Services Standards are managed by The W3C consortium WS-I, an organisation to promote the interoperability of web services (platform independent, vendor independent) OASIS (The Organization for the Advancement of Structured Information Standards) WSDL (Web Service Description/Definition Language) - XML format to specify the operations of a service SOAP (Simple Object Access Protocol) - one-way, stateless protocol to transfer XML data to a single receiver (since SOAP 1.2 there can be more receivers) Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

47 Service Oriented Architectures Standards for Web Services Additional standards (of lesser importance) UDDI (Universal Description, Discovery and Integration) - registry service for services SAML (Security Assertion Markup Language) - XML based framework for user authentication, description of authorization data XKMS (XML Key Management Specification) - management and registry of public keys Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

48 Basic Profile 1.1 WS-I Final Specification Basic Profile The Basic Profile 1.1 provides implementation guidelines for how related set of nonproprietary Web Service specifications should be used together for best interoperability. Basic Profile 1.2 WS-I Working Group Draft Basic Profile The Basic Profile 1.2 builds on Basic Profile 1.1 by incorporating Basic Profile 1.1 errata, requirements from Simple SOAP Binding Profile 1.0, and adding support for WS-Addressing and MTOM. Basic Profile 2.0 WS-I Working Group Draft Basic Profile The Basic Profile 2.0 is an update of WS-I BP that includes a profile of SOAP 1.2. Attachments Profile 1.0 WS-I Final Specification Attachments Profile The Attachment Profile 1.0 complements the Basic Profile 1.1 to add support for interoperable SOAP Messages with attachments-based Web Services. Simple SOAP Binding Profile 1.0 WS-I Final Specification Simple SOAP Binding Profile The Simple SOAP Binding Profile consists of those Basic Profile 1.0 requirements related to the serialization of the envelope and its representation in the message. Basic Security Profile 1.0 WS-I Board Approval Draft Basic Security Profile defines the WS-I Basic Security Profile 1.0, based on a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability. REL Token Profile 1.0 WS-I Working Group Draft REL Token Profile is based on a non-proprietary Web services specification, along with clarifications and amendments to that specification which promote interoperability. SAML Token Profile 1.0 WS-I Working Group Draft SAML Token Profile is based on a non-proprietary Web services specification, along with clarifications and amendments to that specification which promote interoperability. Conformance Claim Attachment Mechanism (CCAM) 1.0 WS-I Final Specification Conformance Claim Attachment Mechanism (CCAM) catalogues mechanisms that can be used to attach WS-I Profile Conformance Claims to Web services artefacts (e.g., WSDL descriptions, UDDI registries). Reliable Asynchronous Messaging Profile (RAMP) 1.0 WS-I Working Draft Reliable Asynchronous Messaging Profile (RAMP) is a profile, in the fashion of the WS-I profiles, that enables, among other things, basic B2B integration scenarios using Web services technologies. Standards Bodies The Organization for the Advancement of Structured Information Standards (OASIS) is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 4,000 participants representing over 600 organizations and individual members in 100 countries. The World Wide Web Consortium (W3C) was created in October 1994 to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. W3C has over 350 Member organizations from all over the world and has earned international recognition for its contributions to the growth of the Web. W3C is designing the infrastructure, and defining the architecture and the core technologies for Web services. In September 2000, W3C started the XML Protocol Activity to address the need for an XML-based protocol for application-to-application messaging. In January 2002, the Web Services Activity was launched, subsuming the XML Protocol Activity and extending its scope. The Web Services Interoperability Organization (WS-I) is an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages. The organization s diverse community of Web services leaders helps customers to develop interoperable Web services by providing guidance, recommended practices and supporting resources. Specifically, WS-I creates, promotes and supports generic protocols for the interoperable exchange of messages between Web services. The Internet Engineering Task Force (IETF) is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. Business Process Execution Language for Web Services 1.1 (BPEL4WS) 1.1 BEA Systems, IBM, Microsoft, SAP, Siebel Systems OASIS-Standard Business Process Execution Language for Web Services WS-Choreography Model Overview defines the format Web Service Choreography Interface (WSCI) describes 1.1(BPEL4WS) provides a language for the formal and structure of the (SOAP) messages that are exchanged, how Web Service operations can be choreographed in the specification of business processes and business interaction and the sequence and conditions in which the messages context of a message exchange in which the Web Service protocols using Web Services. are exchanged. participates. Business Process Execution Business Process Management Language for Web Services 2.0 Language (BPML) (BPEL4WS) 2.0 OASIS, BEA Systems, IBM, Microsoft, SAP, Siebel Systems Committee Draft Business Process Execution Language for Web Services 2.0 (BPEL4WS) provides a language for the formal specification of business processes and business interaction protocols using Web Services. WS-Policy WS-PolicyAssertions BEA Systems, W3C IBM, Microsoft, SAP Working Draft Public Draft WS-Policy describes the capabilities and constraints of WS-PolicyAssertions provides an initial set of assertions the policies on intermediaries and endpoints (e.g. business to address some common needs of Web Services rules, required security tokens, supported encryption applications. algorithms, privacy rules). WS-PolicyAttachment 1.2 W3C W3C Member Submission WS-PolicyAttachment defines two general-purpose mechanisms for associating policies with the subjects to which they apply; the policies may be defined as part of existing metadata about the subject or the policies may be defined independently and associated through an external binding to the subject. WS-MetadataExchange 1.1 BEA Systems, Computer Associates, IBM, Microsoft, SAP, Sun Microsystems and webmethods Public Draft WS-MetadataExchange enables a service to provide metadata to others through a Web services interface. Given only a reference to a Web service, a user can access a set of WSDL /SOAP operations to retrieve the metadata that describes the service. Web Service Description Language 2.0 SOAP Binding 2.0 W3C Working Draft Web Service Description Language SOAP Binding describes the concrete details for using WSDL 2.0 in conjunction with SOAP 1.1 protocol. Web Service Description Language W3C Note Web Service Description Language 1.1 is an XML-based language for describing Web services and how to access them. It specifies the location of the service and the operations (or methods) the service exposes. WS-Notification 1.3 OASIS OASIS-Standard WS-Enumeration describes a general SOAP-based WS-Enumeration protocol for enumerating Systinet, Microsoft, Sonic Software, BEA a sequence of XML Systems and elements that is suitable Computer Associates for traversing logs, message queues, or other linear Public Draft information models. XML W3C Recommendation WS-Discovery Microsoft, BEA Systems, Canon, Intel and webmethods Draft WS-Discovery defines a multicast discovery protocol for dynamic discovery of services on ad-hoc and managed networks. Universal Description, Discovery and Integration (UDDI) OASIS OASIS-Standard Universal Description, Discovery and Integration (UDDI) defines a set of services supporting the description and discovery of businesses, organizations, and other Web services providers, the Web services they make available, and the technical interfaces which may be used to access those services. Web Service Description Language 2.0 Core 2.0 W3C Candidate Recommendation Web Service Description Language 2.0 Core is an XMLbased language for describing Web services and how to access them. It specifies the location of the service and the operations (or methods) the service exposes. WS-Notification is a family of related white papers and specifications that define a standard Web services approach to notification using a topicbased publish/subscribe pattern. XML Extensible Markup Language is a pared-down version of SGML, designed especially for Web documents. It allows one to create own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. WS-Choreography Model Overview 1.0 W3C Working Draft WS-BrokeredNotification defines the interface for WS-BrokeredNotification the NotificationBroker. A NotificationBroker is an 1.3 intermediary, which, among OASIS other things, allows OASIS-Standard publication of messages from entities that are not themselves service providers. WS-Topics 1.3 OASIS OASIS-Standard XML W3C Recommendation Web Service Choreography Interface (WSCI) 1.0 W3C Sun Microsystems, SAP, BEA Systems and Intalio Note XML Process Definition Language (XPDL) BPMI.org Final Final Draft Business Process Management Language (BPML) XML Process Definition Language (XPDL) provides an provides a meta-language for expressing business XML file format that can be used to interchange process processes and supporting entities. models between tools. WS-Topics defines three topic expression dialects that can be used as subscription expressions in subscribe request messages and other parts of the WS-Notification system. XML Extensible Markup Language is a pared-down version of SGML, designed especially for Web documents. It allows one to create own customized tags, enabling the definition, transmission, validation, and interpretation of data between applications and between organizations. Web Service Choreography Description Language (CDL4WS) 1.0 W3C Candidate Recommendation Web Service Choreography Description Language (CDL4WS) is to specify a declarative, XML based language that defines from a global viewpoint the common and complementary observable behaviour, where message exchanges occur, and when the jointly agreed ordering rules are satisfied. WS-ReliableMessaging 1.1 OASIS Committee Draft WS-ReliableMessaging describes a protocol that allows Web services to communicate reliable in the presence of software component, system, or network failures. It defines a SOAP binding that is required for interoperability. WS-Reliable Messaging Policy Assertion (WS-RM Policy) 1.1 OASIS Committee Draft Web Services ReliableMessaging Policy Assertion (WS-RM Policy) describes a domain-specific policy assertion for WS-ReliableMessaging that that can be specified within a policy alternative as defined in WS-Policy Framework. WS-Reliability 1.1 OASIS OASIS-Standard WS-Reliability is a SOAP-based protocol for exchanging SOAP messages with guaranteed delivery, no duplicates, and guaranteed message ordering. WS-Reliability is defined as SOAP header extensions and is independent of the underlying protocol. This specification contains a binding to HTTP. WS-BaseNotification 1.3 OASIS OASIS-Standard WS-BaseNotification standardizes the terminology, concepts, operations, WSDL and XML needed to express the basic roles involved in Web services publish and subscribe for notification message exchange. Management Using Web Management Of Services Web Services WS-Management (WSDM-MUWS) (WSDM-MOWS) AMD, Dell, Intel, Microsoft and Sun Microsystems OASIS OASIS Published Specification OASIS-Standard OASIS-Standard Web Service Distributed Management: Management Using Web Service Distributed Management: Management Of WS-Management describes a general SOAP-based Web Services (WSDM-MUWS) defines how an IT resource Web Services (WSDM-MOWS) addresses management of protocol for managing systems such as PCs, servers, connected to a network provides manageability interfaces the components that form the network, the Web services devices, Web services and other applications, and other such that the IT resource can be managed locally and from endpoints, using Web services protocols. manageable entities. remote locations using Web services technologies. Service Modeling Language IBM, BEA, BMC, Cisco, Dell, HP, Intel, Microsoft, Sun Draft Specification Servcie Modeling Language (SML) is used to model complex IT services and systems, including their structure, constraints, policies, and best practices. WS-Security WS-SecurityPolicy IBM, Microsoft, OASIS RSA Security, VeriSign OASIS-Standard Public Draft WS-Security is a communications protocol providing a WS-SecurityPolicy defines how to describe policies related means for applying security to Web Services. to various features defined in the WS-Security specification. WS-Security: WS-Security: SOAP Message Security Username Token Profile OASIS OASIS Public Review Draft Public Review Draft WS-Security: SOAP Message Security describes WS-Security: Username Token Profile describes how enhancements to SOAP messaging to provide message a Web Service consumer can supply a Username Token as a integrity and confidentiality. Specifically, this specification means of identifying the requestor by username, and provides support for multiple security token formats, trust optionally using a password (or shared secret, etc.) to domains, signature formats and encryption technologies. authenticate that identity to the Web Service producer. The token formats and semantics for using these are defined in the associated profile documents. WS-Security: Kerberos Binding 1.0 Microsoft, IBM, OASIS Working Draft Namespaces in XML XML Information Set is provides a simple method an abstract data set to Namespaces in XML for qualifying element and XML Information Set provide a consistent set of attribute names used in XML definitions for use in other 1.1 documents by associating 1.0 specifications that need to W3C them with namespaces W3C refer to the information Recommendation identified by IRI references. Recommendation in a well-formed XML document. WS-Federation 1.0 IBM, Microsoft, BEA Systems, RSA Security, and VeriSign Initial Draft WS-Federation describes how to manage and broker the trust relationships in a heterogeneous federated environment including support for federated identities. WS-Security: Kerberos Binding defines how to encode Kerberos tickets and attach them to SOAP messages. As well, it specifies how to add signatures and encryption to the SOAP message, in accordance with WS-Security, which uses and references the Kerberos tokens. WS-Security: WS-Trust BEA Systems, Computer Associates, IBM, Layer 7 SAML Token Profile Technologies, Microsoft, Netegrity, Oblix, 1.1 OpenNetwork, Ping Identity Corporation, OASIS Reactivity, RSA Security, VeriSign and Westbridge Public Review Draft Technology Initial Draft WS-Security: SAML Token Profile defines the use of WS-Trust describes a framework for trust models that enables Security Assertion Markup Language (SAML) v1.1 assertions Web Services to securely interoperate. It uses WS-Security base in the context of WSS: SOAP Message Security including mechanisms and defines additional primitives and extensions for the purpose of securing SOAP messages and SOAP for security token exchange to enable the issuance and message exchanges. dissemination of credentials within different trust domains. WS-Security: X.509 WS-SecureConversation BEA Systems, Computer Associates, IBM, Certificate Token Profile Layer 7 Technologies, Microsoft, Netegrity, 1.1 Oblix, OpenNetwork, OASIS Ping Identity Corporation, Reactivity, Public Review Draft RSA Security, VeriSign and Westbridge Technology Public Draft WS-Security: X.509 Certificate Token Profile describes WS-SecureConversation specifies how to manage and the use of the X.509 authentication framework with the authenticate message exchanges between parties including WS-Security: SOAP Message Security specification. security context exchange and establishing and deriving session keys. WS-Eventing W3C Public Draft WS-Addressing WSDL Binding 1.0 W3C Candidate Recommendation WS-Eventing defines a baseline set of operations that allow Web services to provide asynchronous notifications to interested parties. WS-Addressing WSDL Binding defines how the abstract properties defined in Web Services Addressing Core are described using WSDL. XML Schema 1.1 W3C Working Draft WS-Addressing Core 1.0 W3C Recommendation WS-Addressing SOAP Binding 1.0 W3C Recommendation WS-Coordination 1.1 OASIS Working Draft WS-Coordination describes an extensible framework for providing protocols that coordinate the actions of distributed applications. WS-Business Activity 1.1 OASIS Working Draft WS-Business Activity provides the definition of the business activity coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. WS-Atomic Transaction 1.1 OASIS Committee Draft WS-Atomic Transaction defines protocols that enable existing transaction processing systems to wrap their proprietary protocols and interoperate across different hardware and software vendors. WS-Composite Application Framework (WS-CAF) 1.0 Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Specification WS-Composite Application Framework (WS-CAF) is a collection of three specifications aimed at solving problems that arise when multiple Web Services are used in combination. It proposes standard, interoperable mechanisms for managing shared context and ensuring business processes achieve predictable results and recovery from failure. WS-Context (WS-CTX) 1.0 Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Draft WS-Context (WS-CTX) is intended as a lightweight mechanism for allowing multiple Web Services to share a common context. WS-Coordination Framework (WS-CF) 1.0 Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Draft WS-Coordination Framework (WS-CF) allows the management and coordination in a Web Services interaction of a number of activities related to an overall application. WS-Transaction Management (WS-TXM) 1.0 Arjuna Technologies, Fujitsu, IONA, Oracle and Sun Microsystems Committee Draft WS-Transaction Management (WS-TXM) defines a core infrastructure service consisting of a Transaction Service for Web Services. WS-Addressing Core provides transport-neutral mechanisms to address Web services and messages. This specification defines XML elements to identify Web service endpoints and to secure end-to-end endpoint identification in messages. WS-Addressing SOAP Binding provides transportneutral mechanisms to address Web services and messages. SOAP 1.2 W3C Recommendation SOAP 1.1 W3C Note Web Services for Remote Portlets (WSRP) 2.0 OASIS Committee Draft Web Services for Remote Portlets (WSRP) defines a set of interfaces and related semantics which standardize interactions with components providing user-facing markup, including the processing of user interactions with that markup. SOAP Message Transmission Optimization SOAP is a lightweight, XML-based protocol for exchange of information in a decentralized, distributed environment. Web Services Resource Framework (WSRF) 1.2 OASIS OASIS-Standard Web Services Resource Framework (WSRF) defines a family of specifications for accessing stateful resources using Web Services. WS-BaseFaults (WSRF) 1.2 OASIS Working Draft WS-BaseFaults (WSRF) defines a base set of information that may appear in fault messages. WS-BaseFaults defines an XML schema type for base faults, along with rules for how this base fault type is used and extended by Web Services. WS-ServiceGroup (WSRF) 1.2 OASIS Working Draft WS-ServiceGroup (WSRF) defines a means by which Web Services and WS-Resources can be aggregated or grouped together for a domain specific purpose. WS-ResourceProperties 1.2 OASIS Working Draft WS-ResourceProperties specifies the means by which the definition of the properties of a WS-Resource may be declared as part of the Web Service interface. The declaration of the WS-Resource properties represents a projection of or a view on the WS-Resource state. WS-ResourceLifetime 1.2 OASIS Working Draft WS-ResourceLifetime is to standardize the terminology, concepts, message exchanges, WSDL and XML needed to monitor the lifetime of, and destroy WS-Resources. Additionally, it defines resource properties that may be used to inspect and monitor the lifetime of a WS-Resource. WS-Transfer W3C W3C Member Submission WS-Transfer describes a general SOAP-based protocol for accessing XML representations of Web service-based resources. Resource Representation SOAP Header Block (RRSHB) W3C Recommendation Resource Representation SOAP Header Block (RRSHB) complements MTOM by defining mechanisms for describing and conveying non-xml resource representations in a SOAP 1.2 message. Mechanism (MTOM) 1.0 W3C Recommendation SOAP Message Transmission Optimization Mechanism describes an abstract feature for optimizing the transmission and/or wire format of a SOAP message. XML Schema XML XML binary Optimized Describing Media Content Schema Definition Language Packaging (XOP) is an XML XML binary Optimized Describing Media Content of Binary Data in XML is an XML language for language for describing and (DMCBDX) specifies how to describing and constraining Packaging (XOP) constraining the content of of Binary Data in XML indicate the content-type the content of XML 1.0 XML documents. (DMCBDX) associated with binary documents. element content in an XML W3C W3C document and to specify, in Recommendation Note XML Schema, the expected content-type(s) associated with binary element content. SOAP 1.1 SOAP 1.2 SOAP Message Transmission Optimization Mechanism WS-Notification WS-BaseNotification WS-Topics WS-BrokeredNotification WS-Addressing Core WS-Addressing WSDL Binding WS-Addressing SOAP Binding WS-Eventing WS-Enumeration WS-Policy WS-PolicyAssertions WS-PolicyAttachment WS-Discovery WS-MetadataExchange Universal Description, Discovery and Integration Web Service Description Language 1.1 Web Service Description Language 2.0 Core Web Service Description Language 2.0 SOAP Binding WS-Security WS-Security: SOAP Message Security WS-Security: Kerberos Binding WS-Security: SAML Token Profile WS-Security: X.509 Certificate Token Profile WS-Security: Username Token Profile WS-SecurityPolicy WS-Trust WS-Federation WS-SecureConversation WS-ReliableMessaging WS-Reliability WS-Reliable Messaging Policy Assertion Web Service Resource Framework WS-BaseFaults WS-ServiceGroup WS-ResourceProperties WS-ResourceLifetime WS-Transfer Resource Representation SOAP Header Block (RRSHB) WS-Management Management Of Web Services Management Using Web Services Service Modeling Language Business Process Execution Language for Web Services Web Service Choreography Description Language Web Service Choreography Interface WS-Choreography Model Overview Business Process Management Language Business Process Execution Language for Web Serv. 2.0 XML Process Definition Language WS-Business Activity WS-Atomic Transaction WS-Coordination WS-Composite Application Framework WS-Transaction Management WS-Context WS-Coordination Framework Web Services for Remote Portlets innoq Deutschland GmbH innoq Schweiz GmbH Halskestraße 17 Gewerbestrasse 11 D Ratingen CH-6330 Cham Phone Phone info@innoq.com Service Oriented Architectures Standards for Web Services Web Services Standards Overview Interoperability Issues Business Process Specifications Metadata Specifications Reliability Specifications Management Specifications Presentation Specifications Security Specifications Transaction Specifications Messaging Specifications SOAP Dependencies Messaging Specifications Metadata Specifications Resource Specifications Security Specifications Reliability Specifications Resource Specifications Management Specifications Presentation Specifications Transaction Transaction Basic Profile Reliability Resource Business Process Specifications Transaction Specifications Reliability Resource Meta Reliab. Metadata Security Secur. Reliability Messaging Messaging Security Security Security Messaging Security Security Mess. Security Transaction Messaging Messaging Metadata Metadata Messaging Metadata This poster is not to be reproduced or transmitted in any form or for any purpose without the express permission of innoq Deutschland GmbH. Copyright innoq Deutschland GmbH. All Rights Reserved. The poster may also contain references to other company, organisation, brand and product names. These company, organisation, brand and product names are used herein for identification purposes only and may be the trademarks of their respective owners. Version 3.0 February 2007 XML Specifications Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

49 Service Oriented Architectures Example of WSDL & SOAP Definition of an operation: GetUserData The operation has an input and an output The input is defined via GetUserDataRequest The output is defined via GetUserDataResponse Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

50 Example of WSDL Service Oriented Architectures <wsdl > < wsdl:operation name =" GetUserData " > < wsdl:input message =" es:getuserdatarequest "/ > < wsdl:output message =" es:getuserdataresponse "/ > </ wsdl:operation > < xsd:element name =" GetUserDataRequest " > < xsd:complextype > < xsd:sequence > < xsd:element name =" username " type =" string "/> < xsd:element name =" role " type =" string "/> </ xsd:sequence > </ xsd:complextype > </ xsd:element > < xsd:element name =" GetUserDataResponse " > < xsd:complextype > < xsd:all > < xsd:element name =" " type =" string "/> </ xsd:all > </ xsd:complextype > </ xsd:element > <wsdl > Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

51 Example of SOAP Service Oriented Architectures < soap:envelope > < soap:body xmlns:m =" http: // www. example. org / userdata "> < m:getuserdata > < m: > user@example. org </ m: > </ m:getuserdata > </ soap:body > </ soap:envelope > Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

52 Service Oriented Architectures Orchestration of Services How are services interconnected with each other? Applications are realized by a combination of services Orchestration takes care which services interact and when Control flow can be automated via workflow engines Should help reuse by loose coupling and flexibility Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

53 Service Oriented Architectures Binding of Services Development-time binding vs. runtime binding Development-time binding is far simpler The services, their API and address are fixed during development time Runtime binding is more complex The exact services and address are found during runtime Lookup by service name often the best approach Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

54 Service Oriented Architectures Discovery of Services How do I find the service for my needs? UDDI aimed at a lookup service for businesses, organisation and services UDDI as yellow pages for web services No widespread use Should help addressability Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

55 Service Oriented Architectures Service Types Typical service (component) types in SOA systems: Application frontend - typically not a service, initiate operation and receive results Basic services - they build the foundation Intermediary services - adapters and facades to add functionality, typically stateless Process centric services - implement the business logic, typically manage the process state Public services - for integration, higher level functionality Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

56 Service Oriented Architectures SOA and Software Architecture SOA aims to decouple the system from the software architecture No alignment between the system layers and the service layers system layers: browser, application server, web server, operation system service layers: application, process, intermediary, basic Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

57 Service Oriented Architectures Example: Simple SOA Architecture In the most simple case the SOA architecture consists of two layers The application layer, which uses the basic services The layer for the basic services For example: A web site of an airline Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

58 Service Oriented Architectures Example: Simple SOA Architecture Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

59 Service Oriented Architectures Facade Pattern Intermediary services often serve as facade for basic services They aggregate the functionality Example for a n-tier architecture Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

60 Service Oriented Architectures Example: Facade Pattern Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

61 Service Oriented Architectures Process-centric Services Optional component in SOA systems Process-centric services encapsulate process logic and application state An application frontend may delegate the process control to such a component Advantage: reuse when the process-centric services is shared by multiple clients Disadvantage: more complex system, process control might be split into multiple components Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

62 Service Oriented Architectures Example: Process-centric Services Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

63 Service Oriented Architectures Best practices Limit access to data Have a single service to manage the data For example, instead of two services with two interfaces provide a single service with two interfaces Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

64 Service Oriented Architectures Example of Cross-Cutting Concerns Example of how to tackle cross-cutting concerns with SOA: Logging of information, warning, failures, etc. Log locally, but view globally Each service uses a local logging functionality, logs are then aggregated Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

65 Service Oriented Architectures Security in SOA Additional security considerations for services How to protected against attacks? Trusted domain vs. securing every service Trust domains usually in use for base services Use unified security framework Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66

66 Section Service Oriented Architectures Questions? Denis Helic, Roman Kern (KMI, TU Graz) WWW Architecture II Dec 5, / 66