Gibbins, Nicholas

English

EdShare

Topics on  Web Services COMP6017 Dr Nicholas Gibbins – nmg@ecs.soton.ac.uk 2013-2014 Module Aims 2 • Introduce you to service oriented architectures • Introduce you to both traditional and RESTful Web Services • Give you in-depth knowledge of Web Services • Give you practical hands-on experience of RESTful Web Services People 3     Office hours for nmg: Friday 1100-1200 Nick Gibbins Enrico Costanza Module Structure 4 One double lecture each week – Friday 0900-1100, 05/2015 – Note: extra slots in timetable in week 4 are incorrect  Assessment – 75% Exam – 25% Group Coursework Coursework 5 One coursework worth 25% of your final mark – Groups of three – Construct a RESTful web service and client using JavaScript and node.js – Coursework specification published on Friday of week 5 – Deadline on Tuesday of week 11 (10th December) – Feedback by the end of week 12 Teaching Schedule 6 Week 1  Overview   Web Services Architecture   Architecture of the World Wide Web Week 2  CANCELLED   Week 3  Web Protocols: HTTP   REST and Resource Oriented Architectures Week 4  Web Protocols: SOAP   REST in Practice Week 5  Service Description: WSDL      Introduction to JavaScript and node.js    Teaching Schedule 7 Week 6  Service Discovery: UDDI    Coursework Briefing Week 7  Addressing and Policy   Coursework Support Week 8    Security   Coursework Support Week 9-11  Coursework Support Week 12  Review Service Orientation Service Orientation • Component-based software design paradigm • Organise and use heterogeneous distributed capabilities • Many existing technologies: – Java RMI, CORBA, DCOM, WCF, Web Services, REST What is a service? 10 • Services as contractually defined behaviours • Services as task-performing components • Services as collections of related capabilities • Services combine information and behaviour 8 Principles for Service Orientation • Loose coupling • Shared formal contracts • Abstraction • Composability • Reusability • Autonomy • Statelessness • Discoverability 11 Loose Coupling 12 Coupling is a measure of the degree of dependency between components – Tight coupling limits flexibility – Loose coupling promotes ad hoc reuse of components Shared Formal Contract 13 Services have descriptions that document: – programmatic interface – communication requirements and protocols – constraints – usage policies Abstraction 14 Service contract describes the external view of a service – service internals are hidden – limits formation of dependencies (loosens coupling) Service internals may change with minimal impact on clients Composability 15 Service abstraction allows the encapsulation of other services – internally, a service may be a client of other services – services may aggregate several services Reusability 16 Separation of concerns encourages reuse of components – Service contracts describe services to clients Autonomy 17 Services exist independently  Services control their underlying logic – subject to commitments made in service contracts Statelessness 18 State consists of data specific to current activity – State management consumes resources  Statelessness increases scalability and availability Discoverability 19 Service discovery is key to SOA – service contracts describe services to facilitate consumption by potential clients – clients may search for services by the features of their contracts Architecture 20 What is an architecture? • Logical architecture  • Process architecture • Development architecture  • Physical architecture 21 Logical Architecture Primarily supports the functional requirements – i.e. what the system should provide in terms of services to its users.   The system will be decomposed into a set of abstractions, and their high level interactions will be identified 22 Process Architecture Takes into account some non-functional requirements, such as performance and availability  Addresses issues of concurrency and distribution, of system integrity, of fault-tolerance 23 Development Architecture Focuses on the actual software module organisation, including libraries 24 Physical Architecture Takes into account primarily the non-functional requirements of the system – availability – reliability – performance – scalability 25 … what about COMP6017? 26 • We are essentially going to cover a logical architecture, identifying core functionality offered by Web Services.   • Some elements of process architecture, and in particular concurrency and distribution, will be addressed too.   • We discuss the development architecture, when investigating REST. Introduction to  Web Services Web Service Definition • 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.       (Web Service Glossary) 34 Discussion   • Not universally accepted • Too minimalist: does not mention policies, choreography, security • Too specific, refers to standards that are not universally accepted (e.g., wsdl) 35 Service Definition • A service is a mechanism to enable access to a set of capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.  • A service is provided by one entity for use by others, but the eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. (OASIS SOA Reference Model) 36 Engaging a Web Service 37 Roles (1): service vs. agent 38 • A Web Service is an abstract notion that must be implemented by a concrete agent. • The Agent is the concrete piece of software that sends and receives messages, while the service is the resource characterized by the abstract set of functionality that is provided Roles (2): provider vs requester 39 • The service provides functionality on behalf of its owner (a person or organisation): the provider entity. • A requester entity is a person or organization that wishes to make use of a provider entity's Web service. • A requester entity uses a requester agent to exchange messages with the provider entity's provider agent. Roles (3): description 40 • The mechanics of the message exchange are documented in a Web Service description. • It defines the  – message formats,  – datatypes,  – transport protocols, and –  transport serialization formats that should be used between the requester agent and the provider agent. Roles (4): semantics 41 • The semantics of a Web service is the shared expectation about the behaviour of the service, in particular in response to messages that are sent to it. • In effect, this is the contract between the requester entity and the provider entity regarding the purpose and consequences of the interaction. Engaging a Web Service 42 1.  The requester and provider entities become known to each other (or at least one becomes known to the other);  2.  The requester and provider entities somehow agree on the service description and semantics that will govern the interactions between them; 3.  The service description and semantics are exploited by the requester and provider agents;  4.  The requester and provider agents exchange messages. (I.e., the exchange of messages with the provider agent represents the concrete manifestation of interacting with the provider entity's Web service.)  Web Service Models 43 Web Service Models • Message Oriented Model • Service Oriented Model • Resource Oriented Model • Policy Model 44 Focuses on messages, message structure, message transport and so on Message Oriented Model 45 Focuses on aspects of service, action and so on.  - In any distributed system, services cannot be adequately realized without some means of messaging, the converse is not the case: messages do not need to relate to services. Service Oriented Model 46 Focuses on resources that exist and have owners. Resource Oriented Model 47 Focuses on constraints on the behaviour of agents and services.  - Generalize to resources  - Policies can apply equally to documents (such as service descriptions) as well as  active computational  resources. Policy Model 48 Conclusion 49 • No agreed definition of what a Web Service is, but a reasonable intuition • Not a single vision for Web Services (multiple standardisation committees, etc) • Multiple  and competing WS stacks • Architecture does not discuss resources with state 

Overview and Introduction to Web Services

Abstract

Similar works

Full text

Available Versions

EdShare