1 PART III - WEB SERVICES AND PRIMITIVE SOA. 2 Web Services INTRODUCTION.
-
Upload
elizabeth-stack -
Category
Documents
-
view
219 -
download
2
Transcript of 1 PART III - WEB SERVICES AND PRIMITIVE SOA. 2 Web Services INTRODUCTION.
1
PART III - WEB SERVICES AND PART III - WEB SERVICES AND PRIMITIVE SOAPRIMITIVE SOA
PART III - WEB SERVICES AND PART III - WEB SERVICES AND PRIMITIVE SOAPRIMITIVE SOA
2
Web Services Web Services INTRODUCTIONINTRODUCTIONWeb Services Web Services
INTRODUCTIONINTRODUCTION
3
Definizione di Web Service (W3C)There are many things that might be called "Web services" in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following 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.
4
Web Services are loosely coupled software
components delivered over standard Internet
technologies.
5
Loosely coupled, reusable software components that
semantically encapsule discrete functionality and
are distributed and programmatically
accessible over standard Internet protocols.
Brent Sleeper and Bill Robins, Stencil Group
6
A Web Service is any piece of software that makes itself available over the
Internet and uses a standardized XML messaging system
Ethan Cerami, in Web Services Essentials
7
Arbitrarily grouped set of resources intended for machine (not human)
manipulation, as a "Web site" is an arbitrary
grouped set of resources intended for human
manipulation
Paul Prescod in XML HANDBOOK
8
A cosa servono i web services
9
Aree Applicative dei Web Service
10
Rete vista da un utente
11
Rete vista da un componente software
12
13
Architettura Orientata ai Servizi
14
1. Web Services 1. Web Services FrameworkFramework
1. Web Services 1. Web Services FrameworkFramework
15
Framework
• A technology framework is a collection of things. (objects)
• It can include – one or more architectures – technologies– concepts– models– sub-frameworks
16
Web Services Framework (I)
• an abstract concept defined by standards organizations and implemented by (proprietary) technology platforms
• “core building blocks” that include Web services, service descriptions, and messages
• a communications agreement centered around service descriptions based on WSDL
• a messaging framework comprised of SOAP technology and concepts
17
Web Services Framework (II)
• a service description registration and discovery architecture sometimes realized through UDDI
• a well-defined architecture that supports messaging patterns and compositions
• a second generation of Web services extensions (also known as the WS-* specifications) continually broadening
18
Relazioni strutturali
19
Interoperating Applications
Your Web Your Web ServiceService
The Other The Other Guy’s Web Guy’s Web
ServiceService
XMLXML
SecuritySecurity
ReliabilityReliability
RoutingRouting
AttachmentsAttachments
What What Schemas?Schemas?
What Address?What Address?
What Pattern?What Pattern?
InspectionInspection
DiscoveryDiscovery
Copyright © 2001 Microsoft Corporation, All Rights ReservedCopyright © 2001 Microsoft Corporation, All Rights Reserved
20
Web Services Roadmap
DiscoveryDiscovery
InspectionInspection
Directory (UDDI)Directory (UDDI)
DescriptionDescription
Structure Structure (XML Schemas)(XML Schemas)
Service Service DescriptionDescription
(WSDL)(WSDL)
Process Flow Process Flow Pattern Pattern
DescriptionDescription
WireWire
Syntax (XML)Syntax (XML)
XML Protocol :XML Protocol :Envelope and Envelope and ExtensibilityExtensibility
(SOAP)(SOAP)
AttachmentsAttachments
RoutingRouting
SecuritySecurity
ReliabilityReliability
Copyright © 2001 Microsoft Corporation, All Rights ReservedCopyright © 2001 Microsoft Corporation, All Rights Reserved
21
Punti chiave 3.1
• First- and second-generation technologies, along with design-agnostic concepts and implementation-neutral architectures, form an form an abstract Web services frameworkabstract Web services framework.
• Protocols are not just individual messages, but patterns of messages.
• The Web Services Framework is an integrated design.– Each part needs to be designed and tested in the
context of the others.
• First- and second-generation technologies, along with design-agnostic concepts and implementation-neutral architectures, form an form an abstract Web services frameworkabstract Web services framework.
• Protocols are not just individual messages, but patterns of messages.
• The Web Services Framework is an integrated design.– Each part needs to be designed and tested in the
context of the others.
22
2. Services (as Web 2. Services (as Web services)services)
2. Services (as Web 2. Services (as Web services)services)
23
Differenza tra servizi web e web services
24
Web Service classification
• a temporary classification based on the roles it assumes during the runtime processing of a message
• a permanent classification based on the application logic it provides and the roles it assumes within a solution environment
SERVICE ROLE
SERVICE MODELS
25
Service roles
• A Web service is capable of assuming different roles,
depending on the context within which it is used.
• A service is therefore not labeled exclusively as a client
or server, but instead as a unit of software capable of
altering its role, depending on its processing
responsibility in a given scenario. ( cfr figure )
• It is not uncommon for a Web service to change its role
more than once within a given business task.
– It is especially not uncommon for a Web service within an SOA to
assume different roles in different business tasks.
26
Service role : provider
• The Web service is invoked via an external source, such as a service requestor
• The Web service provides a published service description offering information about its features and behavior
27
Service Role : requestor
• Any unit of processing logic capable of issuing a request
message that can be understood by the service provider
is classified as a service requestor.
– A Web service is always a service provider but also can act as
a service requestor.
• A Web service takes on the service requestor role under
the following circumstances:
a. The Web service invokes a service provider by sending it a
message [GO]
b. The Web service searches for and assesses the most suitable
service provider by studying available service descriptions
28
Services swapping roles – Case Study 3.2.1
29
Intermediaries
• Web services communication is based on the use of messaging paths because once a service provider submits a message, it can be processed by multiple intermediate routing and processing agents before it arrives at its ultimate destination.
• Web services and service agents that route and process a message after it is initially sent and before it arrives at its ultimate destination are referred to as intermediariesintermediaries or or intermediary servicesintermediary services.
• Because an intermediary receives and submits messages, it always transitions through service provider and service requestor roles [GO]
30
Types of intermediaries
• passive intermediary, – is typically responsible for routing messages
to a subsequent location – It may use information in the SOAP message
header to determine the routing path, – Either way, what makes this type of
intermediary passive is that it does not modify the message.[GO]
31
Active intermediaries
• Like passive intermediary services, active intermediaries also route messages to a forwarding destination.
• Prior to transmitting a message, however, these services actively process and alter the message contents – Typically, active intermediaries will look for particular
SOAP header blocks and perform some action in response to the information they find there.
– They almost always alter data in header blocks and may insert or even delete header blocks entirely [GO]
32
Case Study 3.2.2 Passive Intermediary
After shipping a TLS order, RailCo's Invoice Submission Service transmits a message containing an electronic invoice.
The first TLS Web service to receive the message is a passive
intermediary called the Load Balancing Service.
Its purpose is to provide load balancing logic by checking the current
processing statistics of available TLS servers. When the server with
the lowest usage is identified, this passive intermediary routes the
message accordingly.
Upon receiving the message from the Invoice Submission Service requestor, the passive Load Balancing intermediary acts as the service provider. After it has determined where the message is to be forwarded to, it changes its role to service requestor to forward the invoice document to the destination Accounts Payable Service provider.
33
Case Study 3.2.3 Active Intermediary
TLS employs a number of active intermediaries.
The Internal Policy Service, for example, examines the message to
determine whether it is subject to any internal policy restrictions. If it
is, the active intermediary inserts a new header block
containing one or more policy rules used by subsequent service
providers.
As with the passive intermediary example, the active intermediary
transitions through service provider and service requestor roles
before finally forwarding the message to the appropriate TLS service
provider.
34
Initial sender and ultimate receiver
• Initial senders are simply service requestors that initiate the transmission of a message. – Therefore, the initial
sender is always the first Web service in a message path.
• The counterpart to this role is the ultimate receiver. – This label identifies service
providers that exist as the last Web service along a message's path
35
Case Study 3.2.4
Expanding on the previous example that demonstrated the use of a passive
intermediary, let's take a look at all the services involved in that message
exchange. In this scenario, we had the RailCo Invoice Submission Service
(acting as the service requestor) initiating the message transmission. By
receiving the message, the Load Balancing intermediary acts as the service
provider. Upon routing the message, the intermediary temporarily assumes the
service requestor role and sends the message to the Accounts Payable
Service, another service provider
These three physical services created four logical roles to complete two service requestor-to-service provider transmissions. There was, however, only one Web service that initiated the transmission. This was the Invoice Submission Service, and it is therefore considered the initial sender. Similarly, there was only one Web service that ended the overall activity, which makes the Accounts Payable Service the ultimate receiver.
36
Service Composition
• This particular term does not apply to a single Web service, but to a composite relationship between a collection of services.
• Any service can enlist one or more additional services to complete a given task. Further, any of the enlisted services can call other services to complete a given sub-task. Therefore, each service that
participates in a composition assumes an individual role of service composition member [GO]
• The concept of service composability is very important to service-oriented environments
– In fact, service composition is frequently governed by WS-* composition extensions, such as WS-BPEL and WS-CDL, which introduce the related concepts of orchestration and choreography, respectively
37
Case Study 3.2.5
1. When the TLS Accounts Payable Service receives an invoice, it
invokes a series of additional services to fully process the invoice
contents:
1. It first uses the Vendor Profile Service to validate the invoice
header data and link the invoice document to a vendor account.
2. Next, the Accounts Payable Service extracts taxes and shipping
fees and directly logs all amounts into the appropriate A/P
accounts.
3. Finally, the Accounts Payable Service passes the Ledger Service
the invoice total, which it uses to update the General Ledger.
38
Service models
• The manner in which services are being utilized in the real world, though, has led to a classification based on the nature of the application logic they provide, as well as their business-related roles within the overall solution.
• These classifications are known as service models
39
Business service model• consolidate existing
functionality into unique business contexts;
• can play key roles in the support of new business processes.
• A service-oriented architecture will almost always contain a number of pure business services
40
Utility service model
• as services that enable the characteristic of reuse within SOA
• as services that promote the intrinsic interoperability characteristic of SOA
• as the services with the highest degree of autonomy
41
A utility service being shared by other Web services
42
A remote third-party utility service being incorporated by an
application.
43
Case Study 3.2.6
• In the examples we've gone through so far in this lesson, we've described eight Web services. Six of these are business services, while the other two are utility services, as follows:
– Accounts Payable Service = business service
– Internal Policy Service = utility service
– Invoice Submission Service = business service
– Ledger Service = business service
– Load Balancing Service = utility service
– Order Fulfillment Service = business service
– Purchase Order Service = business service
– Vendor Profile Service = business service
• The Load Balancing and Internal Policy Services are classified as utility services because
they provide generic functionality that can be reused by different types of applications. The
application logic of the remaining services is specific to a given business task or solution,
which makes them business-centric services.
• In the examples we've gone through so far in this lesson, we've described eight Web services. Six of these are business services, while the other two are utility services, as follows:
– Accounts Payable Service = business service
– Internal Policy Service = utility service
– Invoice Submission Service = business service
– Ledger Service = business service
– Load Balancing Service = utility service
– Order Fulfillment Service = business service
– Purchase Order Service = business service
– Vendor Profile Service = business service
• The Load Balancing and Internal Policy Services are classified as utility services because
they provide generic functionality that can be reused by different types of applications. The
application logic of the remaining services is specific to a given business task or solution,
which makes them business-centric services.
44
Controller Service Model
• to support and implement the principle of composability
• to leverage reuse opportunities
• to support autonomy in other services
45
Case Study 3.2.6
In our previous example we demonstrated how the Accounts
Payable Service initiated and coordinated a service
composition consisting of two additional composition
members.
That would classify the Accounts Payable Service as a
controller service. The fact that we already labeled this
service as a business service does not conflict with this new
classification; a single service can be classified as more than
one service model
46
Key points
• Web services can be labeled using temporary and permanent classifications.
• Temporary classifications relate to roles assumed by a service at runtime. • For example, an intermediary service can transition
through different roles while processing a message.• Service models refer to permanent classifications that
represent the logic housed by the service, as well as its role within the overall solution. • A service can belong to more than one service model.
• Web services can be labeled using temporary and permanent classifications.
• Temporary classifications relate to roles assumed by a service at runtime. • For example, an intermediary service can transition
through different roles while processing a message.• Service models refer to permanent classifications that
represent the logic housed by the service, as well as its role within the overall solution. • A service can belong to more than one service model.
Punti chiave 3.2
47
3. MESSAGING 3. MESSAGING (with SOAP)(with SOAP)
3. MESSAGING 3. MESSAGING (with SOAP)(with SOAP)
48
Messaging• All communication between services is message-based
, the messaging framework chosen must be standardized so that all services, regardless of origin, use the same format and transport protocol.
• The receipt of a message by a service is the most fundamental action within SOA and the sole action that initiates service-oriented automation messaging framework be extremely flexible and highly extensible.
• The SOAP specification was chosen to meet all of these requirements and has since been universally accepted as the standard transport protocol for messages processed by Web services.
49
Simple Object Access Protocol SOAP (I)
• SOAP specification's main purpose is to to define a standard message format. define a standard message format.
• SOAP mette a disposizione un meccanismo semplice, ma allo stesso tempo solido, che permette ad una applicazione di mandare un messaggio XML ad un’altra applicazione.
50
Simple Object Access Protocol SOAP (II) • Il protocollo risponde alla necessità di lavorare con
protocolli Web ma permettendo di specificare e progettare e gestire componenti e operazioni
• Soluzione per introdurre parametri e valori nei messaggi e per l'invocazione remota di oggetti basati su tecnologie Web
• Uso di XML per serializzazione dei dati e HTTP come protocollo di trasporto.
51
Basic Structure SOAP message (I)
• Every SOAP message is packaged into a container known as an envelopeenvelope.
• the envelope is responsible for housing all parts of the message
52
Basic Structure SOAP message (II)
• Each message can contain a headerheader, an area dedicated to hosting meta information. – In most service-oriented solutions, this
header section is a vital part of the overall architecture, and though optional, it is rarely omitted.
• The actual message contents are hosted by the message bodybody, which typically consists of XML formatted data. – The contents of a message body are often
referred to as the message payload
53
Framework SOAP messaging
• Envelope incapsula il contenuto del messaggio
• Header (opzionale) destinato a contenere informazioni aggiuntive ( es: informazioni accessorie di sicurezza)
• Body incapsula le richieste e le risposte (in genere, il messaggio da comunicare)
• Fault incapsula eventuali casi distinti di errore ed eccezione
54
SOAP come possibilità di riferire ambienti di nomi precisi
• Si definiscono e riferiscono almeno due namespace:– L’envelope SOAP trovato con identificatore di
namespace http://schemas.xmlsoap.org/SOAP/envelope/
– La serializzazione SOAP con un namespace http://schemas.xmlsoap.org/SOAP/encoding/
55
SOAP e XML request
56
SOAP e XML response
57
SOAP e XML errore
58
Soap e computazione (esempio)
• L’applicazione cliente costruisce una richiesta in XML usando la sintassi definita da SOAP
• L’applicazione cliente trasmette la richiesta ad un server Web usando HTTP
• Il server riceve ed interpreta la richiesta trasformandola in un comando che viene passato ad un’applicazione sul server
• L’applicazione sul server riceve il comando e ricava dal proprio database l’informazione richiesta
• L’applicazione sul server crea una risposta, sempre in formato XML e la restituisce al server Web
• Il server Web la restituisce all’applicazione client come risposta HTTP
59
Estendibilità Verticale• Supponiamo di voler certificare il contenuto dei nostri messaggi SOAP,
avvalendoci dei servizi efferti da una terza società.
• la soluzione migliore è sfruttare il supporto all’estendibilità dei messaggi offerto da SOAP, attraverso gli header blocks
• Estendibilità verticale perché gli header si aggiungono in cima al messaggio
<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header><notary:token xmlns:notary="http://notaries-r-us.com">XQ34Z-4G5</notary:token></soapenv:Header><soapenv:Body><PO>...normal purchase order here...</PO></soapenv:Body></soapenv:Envelope>
<soapenv:Envelopexmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"><soapenv:Header><notary:token xmlns:notary="http://notaries-r-us.com">XQ34Z-4G5</notary:token></soapenv:Header><soapenv:Body><PO>...normal purchase order here...</PO></soapenv:Body></soapenv:Envelope>
60
Utilizzo degli Header Blocks• Extending the messaging infrastructure.
– Infrastructure headers are typically processed by middleware.The application doesn’t see the headers, just their effects.
– They could be things like security credentials, correlation IDs for reliable messaging, transaction context identifiers, routing controls, or anything else that provides services to the application.
• Defining orthogonal data. – The second category of headers is application defined. – These contain data that is orthogonal to the body of the
message but is still destined for the application on the receiving side.
– An example might be extra data to accompany nonextensible schemas – if you wanted to add more customer data fields but couldn’t change the billTo element, for instance.
61
Header blocks suggestion summary
1. processing instructions that may be executed by service intermediaries or the ultimate receiver
2. routing or workflow information associated with the message
3. security measures implemented in the message
4. reliability rules related to the delivery of the message
5. context and transaction management information
6. correlation information (typically an identifier used to associate a request message with a response message)
62
Case Study 3.4.1
• Invoices sent via SOAP messages to TLS are required to contain a number of standard header blocks for them to be accepted and processed by the TLS Accounts Payable Service.
• Specifically, the required header blocks include:
– A correlation identifier that conforms to a standard format and is further extended with a value derived from the date and time of the message transmission. The correlation identifier therefore relates the original submission to the eventual response.
– Organization-level security credentials used for authentication purposes. Each vendor has a security account with the TLS B2B system, and the assigned credentials are required with every message transmission.
63
Il flag must Understand
In presenza del flag mustUnderstand settato a true, se il destinatario dell’header non è in grado di interpretare l’header allora non può continuare il processamento del messaggio.
64
Example
clientProxy/
gateway
purchasingserver
accountingserver
inventoryserverMessage addressed to Proxy
Contains: target dept (purchasing) client name, password request body Message addressed to target dept
Contains: authenticated Id request body
65
Example – Client MessagePOST /purchasing/retailSale HTTP/1.1 -- method invoked at final destinationHost: proxy.yourcompany.com -- initial destination intermediary …….<s:Envelope xmlns:s=….> <s:Header>
<td:targetdept xmlns:td=“….” s:role=“company-proxy.com” -- identifies intermediary s:mustUnderstand=“true” -- this header better be processed
purchasing -- identifies next node</td:targetdept><auth:authinfo=“….” s:role=“company-proxy.com” -- identifies intermediary s:mustUnderstand=“true” > -- this header better be processed
<auth:name> madonna </auth:name><auth:passwd> xxxxxx </auth:passwd>
</auth:authinfo> </Header> <s:Body> …… </s:Body></s:Envelope>
66
Processing Model• An intermediary has an assigned set of roles• On receiving a message, it identifies the
blocks whose role attribute matches an element of its set (or has value next)– Block without a role attribute targeted for final
destination
• The intermediary – can modify/delete its block – can insert new blocks– should retarget the message to the next
destination– can do anything (frowned upon)
67
Example – Proxy Message
POST /purchasing/retailSale HTTP/1.1 -- method invoked at destinationHost: purchasing.yourcompany.com -- initial intermediary …….<s:Envelope xmlns:s=….> <s:Header>
<cc:ClientCredentials xmlns:cc=“….” s:mustUnderstand=“true” > -- this block better be processed by
-- destination (no role specified)<cc:clientId> 122334 </cc:clientId>
</ cc:ClientCredentials > </Header> <s:Body> …… </s:Body> -- same body</s:Envelope>
68
Example – Proxy Message
• Proxy has deleted the two headers– Verified that user is valid using <name> and
<passwd> and determined Id– Retargeted message to final destination using
<targetdept>
• Proxy has inserted a new header containing Id– Final destination uses Id to determine
authorization
69
Attachments and Faults• SOAP attachment to facilitate requirements for
the delivery of data not so easily formatted into an XML document– Each provides a different encoding mechanism used to
bundle data in its native format with a SOAP message. – SOAP attachments are commonly employed to
transport binary files, such as images
• SOAP messages offer the ability to add exception handling logic by providing an optional fault section that can reside within the body area. – The typical use for this section is to store a simple
message used to deliver error condition information when an exception occurs.
70
Fault construct
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body> <env:Fault> <env:Code> <env:Value> env:VersionMismatch </env:Value> </env:Code> <env:Reason> <env:Text xml:lang="en"> versions do not match </env:Text> </env:Reason> </env:Fault> </env:Body></env:Envelope>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body> <env:Fault> <env:Code> <env:Value> env:VersionMismatch </env:Value> </env:Code> <env:Reason> <env:Text xml:lang="en"> versions do not match </env:Text> </env:Reason> </env:Fault> </env:Body></env:Envelope>
71
Case Study 3.4.2
• TLS accounting policy requires that all issued purchase orders in excess of $100,000 require the signature of a senior manager.
• Further, these purchase orders are not allowed to be issued in the standard electronic format, as the signature is required to be an ever-present part of the document. To accommodate this requirement, the Purchase Order Service was designed with an alternative operation.
• The accounting system currently used by TLS offers the ability to scan any accounting-related documents. The scanned images are archived on a separate server and linked to the corresponding accounting records via the archive image path.
• When PO cost totals exceed the $100,000 limit, a custom-developed extension to the accounting system invokes the alternative Purchase Order Service operation and passes it a copy of the signed PO document image.
• The service, in turn, generates a SOAP message in which the PO document image exists as a SOAP attachment
72
Case Study 3.4.3
• The before mentioned SOAP message containing a SOAP attachment is also outfitted with a fault area housing exception information relating specifically to the attached data.
• Should the recipient of the SOAP message be unable to properly process the attachment or should the attachment encounter delivery problems, standard fault codes and descriptions are used to generate a response message that is returned to TLS.
73
SOAP establishes two primary standard message formats
Due possibili modi di utilizzare la tecnologia SOAP:Document e RPC.
Nel primo caso il corpo del messaggio contiene un documento XML, mentre nel secondo vi si trova una rappresentazione in XMLdi una chiamata a procedura.
74
75
Nodes• Although Web services exist as self-
contained units of processing logic, they are reliant upon a physical communications infrastructure to process and manage the exchange of SOAP messages. – Every major platform has its own
implementation of a SOAP communications server
• In abstract, the programs that services use to transmit and receive SOAP messages are referred to as SOAP nodesSOAP nodes
76
Node types
77
Message paths
• A message pathmessage path refers to the route taken by a message from when it is first sent until it arrives at its ultimate destination.
• Therefore, a message path consists of at least one initial sender, one ultimate one initial sender, one ultimate receiver, and zero or more receiver, and zero or more intermediaries intermediaries
78
A message path consisting of three Web services
79
a message path is sometimes not predetermined
80
Case Study 3.4.4
• Revisiting our invoice submission scenario one last time, we can establish both logical and physical views of the path along which the invoice SOAP message travels.
• From a logical perspective, the message path is always the same. The RailCo Invoice Submission Service requestor acts as the initial sender and is therefore the starting point of the path.
• The first service provider the message encounters is the TLS Load Balancing intermediary. This service then becomes the next service requestor and forwards the message to the Accounts Payable Service provider.
• As the last service provider along the path, this Web service becomes the ultimate receiver. This establishes a logical message path consisting of three services.
• The corresponding SOAP message path is not as predictable. Because the Load Balancing Service will only decide which physical server to route a message to when it actually receives and processes the message, the ultimate SOAP receiver is not determined until runtime.
81
Intermediari nelle architetture SOA
• Gli intermediari possono essere classificati anche in funzione dell’utilizzo che fanno degli headers:
• Forwarding Intermediaries Intermediari che processano e operano sul messaggio secondo le indicazioni contenute negli header del messaggio stesso.
• Active Intermediaries Intermediari che processano e operano informazioni indipendentemente dai contenuti del messaggio SOAP.
• Gli intermediari possono essere classificati anche in funzione dell’utilizzo che fanno degli headers:
• Forwarding Intermediaries Intermediari che processano e operano sul messaggio secondo le indicazioni contenute negli header del messaggio stesso.
• Active Intermediaries Intermediari che processano e operano informazioni indipendentemente dai contenuti del messaggio SOAP.
82
Regole di rimozione degli header(I)
83
Regole di rimozione degli header(II)
84
Eccezioni
85
Processamento SOAP: all’arrivo di un messaggio SOAP un ”nodo” deve eseguire i seguenti passi:
1. Determinare l’insieme di ruoli che deve interpretare. A tal fine e’ lecito ispezionare l’intero messaggio SOAP.
2. Identificare tutti gli header blocks di cui risulta destinatario che hanno l’attributo mustUnderstand settato a true.
3. Qualora si ignori il significato di uno o pi`u blocchi tra quelli identificati al passo 2, generare un singolo SOAP fault, e interrompere il processamento del messaggio.
4. Processare tutti gli attributi identificati al passo 2, e in caso il nodo sia il destinatario finale processare il body. Un nodo SOAP pu`o anche decidere di processare gli header a lui indirizzati non obbligatori.
5. Nel caso il nodo sia un intermediario, applicare le regole di rimozione e inoltrare il messaggio lungo il SOAP path.
1. Determinare l’insieme di ruoli che deve interpretare. A tal fine e’ lecito ispezionare l’intero messaggio SOAP.
2. Identificare tutti gli header blocks di cui risulta destinatario che hanno l’attributo mustUnderstand settato a true.
3. Qualora si ignori il significato di uno o pi`u blocchi tra quelli identificati al passo 2, generare un singolo SOAP fault, e interrompere il processamento del messaggio.
4. Processare tutti gli attributi identificati al passo 2, e in caso il nodo sia il destinatario finale processare il body. Un nodo SOAP pu`o anche decidere di processare gli header a lui indirizzati non obbligatori.
5. Nel caso il nodo sia un intermediario, applicare le regole di rimozione e inoltrare il messaggio lungo il SOAP path.
86
Breve storia di SOAP
87
Punti chiave 3.4
• The SOAP messaging framework satisfay the need for SOA's confidence on "independent units of communication," by supporting the creation of intelligence-heavy, document-style, and highly extensible messages.
• SOAP messaging establishes a standard message structure that includes an extensible header section used by numerous WS-* extensions to implement enterprise-level features.
• The SOAP node view of the Web services framework abstracts the physical communications framework, which consists of a series of SOAP servers.
• The SOAP messaging framework satisfay the need for SOA's confidence on "independent units of communication," by supporting the creation of intelligence-heavy, document-style, and highly extensible messages.
• SOAP messaging establishes a standard message structure that includes an extensible header section used by numerous WS-* extensions to implement enterprise-level features.
• The SOAP node view of the Web services framework abstracts the physical communications framework, which consists of a series of SOAP servers.
88
4. Service descriptions 4. Service descriptions (with WSDL)(with WSDL)
4. Service descriptions 4. Service descriptions (with WSDL)(with WSDL)
89
WSDL definitions enable loose coupling between services
90
Case Study 3.3.1
91
Service endpoints and description
• A WSDL describes the point of contact for a service provider, also known as the service service endpointendpoint or just endpointendpoint.
• Provides a formal definition of the endpoint interface – requestors wishing to communicate with the service
provider know exactly how to structure request messages
• Establishes the physical location (address) of the service.
92
WSDL file describes
• What a service does - the operations (methods) the service provides
• How a service is accessed – details of the data formats and protocols necessary to access the service’s operations
• Where a service is located – details of the protocolspecific network address, such as a URL
93
WSDL document
consisting of abstract and concrete parts that collectively describe a service endpoint
94
Abstract description (I)
• Establishes the interface characteristics of the Web service without any reference to the technology used to host or enable a Web service to transmit messages.
• By separating this information, the integrity of the service description can be preserved regardless of what changes might occur to the underlying technology platform
95
Abstract description (II)
• portType section provides a high-level view of the service interface.
• Each operation represents a specific action performed by the service.
• An operation consists of a set of input and output messages. – Much like component methods, operations also have input and output
parameters. Because Web services rely exclusively on messaging-based communication, parameters are represented as messages.
96
Concrete description (I)• For a Web service to be able to execute any of
its logic, it needs for its abstract interface definition to be connected to some real, implemented technology.
• Because the execution of service application logic always involves communication, the abstract Web service interface needs to be connected to a physical transport protocol.
• This connection is defined in the concrete description portion of the WSDL file, which consists of three related parts
97
Concrete description (II)
• binding describes the requirements for a service to establish physical connections. – In other words, a binding represents one possible transport technology the service can use to
communicate. – A binding can apply to an entire interface or just a specific operation.
• Related to the binding is the port, which represents the physical address at which a service can be accessed with a specific protocol.
– This piece of physical implementation data exists separately to allow location information to be maintained independently from other aspects of the concrete description.
– Within the WSDL language, the term service is used to refer to a group of related endpoints.
98
Case Study 3.3.2
• The TLS Accounts Payable Service was created to receive invoices submitted by numerous vendors.
• Its associated service description therefore has a simple abstract description consisting of one interface definition that contains a single operation called SubmitInvoice.SubmitInvoice.
• Specified within the operation is one input and one output message. – The input message is responsible for accepting the invoice document
from a vendor service requestor (such as the RailCo Invoice Submission Service).
– The output message is used by the Accounts Payable Service to send a message of acknowledgement indicating that the submitted invoice document has been successfully received and that its contents are valid.
• The concrete part of this service description simply binds the operation to the SOAP protocol and provides a location address for the Accounts Payable Service.
99
Se si vuole usare un web service non noto
• si richiede il file WSDL• si analizza il documento WSDL per determinare
– locazione del servizio– chiamate dei metodi con i parametri– come accedere ai metodi
• si crea una richiesta SOAP• si invia la richiesta SOAP al servizio e si
attende la risposta• La logica è quella di avere il massimo del
supporto e della facilità nel procedere, fino alla completa automazione da parte di un middleware
• si richiede il file WSDL• si analizza il documento WSDL per determinare
– locazione del servizio– chiamate dei metodi con i parametri– come accedere ai metodi
• si crea una richiesta SOAP• si invia la richiesta SOAP al servizio e si
attende la risposta• La logica è quella di avere il massimo del
supporto e della facilità nel procedere, fino alla completa automazione da parte di un middleware
100
WSDL specification in a nutshell
101
Elementi di base
102
Basic WSDL Example:HelloService.wsdl
• HelloService Web service provides a single publicly available function, called sayHello
• The function expects a single string parameter, and returns a single string greeting
• For example, if you pass the parameter “world”, the service returns the greeting, “Hello, world!”
103
A bird’s-eye view
104
HelloService.wsdl (1di 2)
105
HelloService.wsdl (2 di 2)
106
Definitions element
• The root of all WSDL documents
• defines name of web services
• Declares multiple namespaces used
107
Message element
• It describes a oneway message, whether it is a single message request or a single message response
• It defines the name of the message and contains zero or more message part elements, which can refer to message parameters or message return values
108
portType element
• The portType element combines multiple message elements to form a complete oneway or roundtrip operation (4 operation patterns supported)
• portType can (and frequently does) define multiple operations
109
Operation patterns supported
110
Binding element (1/3)
• It describes the concrete specifics of how the service will be implemented on the wire (HTTP GET, HTTP POST, SOAP…)
• WSDL includes builtin extensions for defining SOAP services, and SOAP specific information therefore goes here
111
Binding element (2/3)
112
Binding element (3/3)
• soap:binding indicates that the binding will be made available via SOAP
• soap:operation indicates the binding of a specific operation to a specific SOAP implementation
• soap:body enables you to specify the details of the input and output messages
113
Service element
• The service element defines the address for invoking the specified service.
• Most commonly, this includes a URL for invoking the SOAP service.
114
Summary
• A service definition can be represented by the contents of a WSDL document, as defined within the definitionsdefinitions construct.
• The abstract interface definition is described by the interface, messageinterface, message, and typestypes constructs. This part of the WSDL document provides a platform-independent description of the Web service interface.
• Concrete implementation information is contained within the binding, service binding, service elements. This part of the WSDL document is used to bind an abstract interface to specific protocols, such as SOAP and HTTP.
• A service definition can be represented by the contents of a WSDL document, as defined within the definitionsdefinitions construct.
• The abstract interface definition is described by the interface, messageinterface, message, and typestypes constructs. This part of the WSDL document provides a platform-independent description of the Web service interface.
• Concrete implementation information is contained within the binding, service binding, service elements. This part of the WSDL document is used to bind an abstract interface to specific protocols, such as SOAP and HTTP.
115
Metadata
• We have up to three separate documents that each describe an aspect of a service:– WSDL definition– XSD schema– Policy
• Each of these three service description documents can be classified as service service metadatametadata, as each provides information about the service.
116
Service contracts
• Service description documents can be collectively viewed as establishing a service service contractcontract– a set of conditions that must
be met and accepted by a potential service requestor to enable successful communication
117
Service description advertisement and discovery
• locate the latest versions of known service descriptions
• discover new Web services that meet certain criteria
La tecnologia che si occupa di questo aspetto è UDDI.UDDI (Universal Description, Discovery and Integration), che è basato su XML ed utilizza SOAP per le comunicazioni da e verso l’esterno, definisce un meccanismo comune per pubblicare e trovare informazioni sui Web Services, in base alle loro descrizioni WSDL
118
Service description locations centralized in a registry
These registries can be searched manually and accessed programmatically via a standardized API.
119
Modalità di utilizzo del registro
• Le API sono classificabili in due principali categorie:– Inquiry API;Inquiry API;– Publish API;Publish API;
• Le prime sono utilizzate per effettuare ricerche sul registro al fine di ottenere informazioni relative alla descrizione di un servizio o dell’organizzazione che distribuisce il servizio, mentre le seconde vengono utilizzate per pubblicare nel registro informazioni relative a servizi o ad organizzazioni.
120
Private and public registries
• Public registries accept registrations from any organizations, regardless of whether they have Web services to offer. – Once signed up, organizations acting as service
provider entities can register their services.
• Private registries can be implemented within organization boundaries to provide a central repository for descriptions of all services the organization develops, leases, or purchases.
121
UDDI registry records (1 of 2)
• Business entities– Each public registry record consists of a
business entity containing basic profile information about the organization (or service provider entity).
– Included in this record are one or more business service areas, each of which provides a description of the services offered by the business entity.
• Business services may or may not be related to the use of Web services.
122
UDDI registry records (2 of 2)
• Registry records store binding information in a separate area, called the binding template.– Each business service can reference one or more
binding templates. – The information contained in a binding template may
or may not relate to an actual service. (For example, a binding template may simply point to the address of a Web site. )
• If a Web service is being represented, then the binding template references a tModel. – The tModel section of a UDDI record provides
pointers to actual service descriptions
123
Basic Structure of UDDI business entity record
124
Principali Entità gestite dal registro UDDI
125
UDDI data types
126
Modello dei dati di un registro UDDI
127
modalità di interazione tra un registro UDDI e soggetti esterni.
Una delle differenze sostanziali tra le funzioni di interrogazione e quelle di pubblicazione sta neldiverso livello di sicurezza richiesto.Mentre le funzioni di ricerca consentono a chiunque di ottenere informazioni relative aorganizzazioni o servizi pubblicati in un registro UDDI, le funzioni di pubblicazione richiedono unprocesso di autenticazione e autorizzazione
128
Schemi logici di organizzazione
• White PagesWhite Pages, contengono le informazioni anagrafiche di una organizzazione, quale il nome, l’indirizzo, il numero di telefono oltre ad identificativi del settore
• Yellow PagesYellow Pages, contengono le informazioni sui vari servizi messi a disposizione dalle organizzazioni;
• Green PagesGreen Pages, contengono le informazioni tecniche sul servizio Web e possono includere anche la descrizione tecnica del servizio (WSDL). – Le “Green Pages” contengono informazioni relative a protocolli o
specifiche necessarie per accedere ai servizi.
• White PagesWhite Pages, contengono le informazioni anagrafiche di una organizzazione, quale il nome, l’indirizzo, il numero di telefono oltre ad identificativi del settore
• Yellow PagesYellow Pages, contengono le informazioni sui vari servizi messi a disposizione dalle organizzazioni;
• Green PagesGreen Pages, contengono le informazioni tecniche sul servizio Web e possono includere anche la descrizione tecnica del servizio (WSDL). – Le “Green Pages” contengono informazioni relative a protocolli o
specifiche necessarie per accedere ai servizi.
129
Schema logico e schema fisico
130
Case Study 3.3.3
At any given time there are several concurrent development and integration projects underway at TLS. Almost every project results in the creation of new services. Some are developed as part of service-oriented solutions, while others originate from legacy adapters and ancillary services appended to older distributed systems. The net result is a constantly growing pool of unmanaged services.After a year-end review of past development initiatives, it was discovered that several project teams had inadvertently built Web services with very similar functionality. To avoid a recurrence of redundant effort, a private registry was created . Project teams responsible for any currently active service descriptions were required to register their services in the registry (and this registration process became part of the standard development lifecycle from there on).
131
Punti chiave 3.4
• The two other primary service description documents are XSD schemas and policies.
• Service descriptions can be dynamically discovered by humans or applications, using private or public service registries.
• The two other primary service description documents are XSD schemas and policies.
• Service descriptions can be dynamically discovered by humans or applications, using private or public service registries.
132
Integrazione di protocolli
133
http://82.191.106.182:8080/
Riferimento: Catalogo Web Services (Elenco online di web
services per enti comunali)
134
135
The sender of the request message is classified as a service requestor
( service consumer)
136
The intermediary service transitions through service provider and service requestor roles while
processing a message.
137
A passive intermediary service processing a message without altering its contents.
138
An active intermediary service
139
A service composition consisting of four members
140
A SOAP node transmitting a
SOAP message received by the service logic.
141
142
The utility service model.