Web Services

SOA Web Services
Development & Deployment
SOA Services - TEG

December 2008
10 April 2009
TCS Public
Contents
Fundamentals of Web Services Web Services Technology Stack Web Services Core Technologies Web Services Design Web Services Deployments
10 April 2009
[SOA Services - Technology Excellence Group SOA Implementation Technologies : Web Services E1:Module 1]
Contents
10 April 2009
Collaborative Business Scenarios

Inter Enterprise Business Processes
Flight Reservation Ordering Cruise Reservation

Single Integrated Travel Web Site
Inventory
Hotel Reservation Manufacturing
Logistics
Car Rental
Drastic changes have taken place in the traditional business processes To stay competitive, enterprises need to integrate with customer, suppliers and trading partners Web Technologies and Enterprise Integration techniques have enabled enterprises to achieve the collaborative business scenarios
10 April 2009
Present-day influences on Business

Web Technologies
INTRANET Focus: Internal Private network that is restricted to a particular group of users, typically employees of a single organization Internal communication vehicles and knowledge bases that serve as a company-wide information system Intranets improve information flow, empower staff to make informed decisions Leads to lower costs and improved productivity within a company Characteristics: can enforce own set of standards, users are known Typical Uses: document distribution, surveys, training, intra-company communication, internal applications INTERNET Focus: customers, to be closer to clients Global network of interconnected networks Accessible to anyone who knows their Internet Protocol (IP) address Internet relates to the hardware, software involved, as well as the WWW, FTP, email and newsgroups WWW is the graphical user interface for the technologies and protocols underpinning the internet Characteristics of users/clients: unknown platform, wide variety, business logic needs to be on server
Internet Intranet
Extranet Partner
Our Company
EXTRANET Focus: closer relationship with partners, convenience, data sharing Extension of a companys intranet out onto the internet to allow selected partners to access companys (private) data and applications (via the World-Wide Web) Improves sales, marketing, supplier and customer service channels when accessed by relevant user groups - business partners, customers, suppliers
10 April 2009
Need for Web Services

Today, business deals with information across the globe having Different data formats Different Networks Different Platforms
Documents
There is a need to fundamentally change the way applications communicate.

Spreadsheets Product Data
Web services have the ability to bring this change!
10 April 2009
Technology Evolution
Distributed Component Architecture evolution
Proprietary Private, Static Proprietary, binary Private Networks
Interface Definition Function Accessibility
OPEN Standard Public & Dynamic OPEN Text Firewall Friendly
Interface Format
Messaging Protocol
J2EE/ EJB COM/ DCOM CORBA
Web Services
10 April 2009
Web Services
What is a Web Service
Mechanism for delivering cross-platform, cross-language services and business content to any Web based application or device URL-addressable software components that are connected by a common protocol, and which allow applications and services to access them over the Internet Based on XML envelopes containing either documents or procedures and data structures Allows applications to interact with one another in a very loosely-coupled manner over a networked environment When listed in a registry, it can then be found or discovered, bound and then invoked by a service consumer
Feature Summary
Services as Components promoting reuse Platform-Free Based on Open Standards such as SOAP, UDDI, WSDL etc. Promotes loose coupling Dynamic Integration Interoperability Incremental Deployment Enables collaborative business models
10 April 2009
Web Applications vs. Web Services

Web Services Interface Integration of Components Functionality Language Service Index Application domain Protocols Program-Program Dynamic Aggregation XML Search via UDDI B2B SOAP + HTTP/HTTPS/SMTP Web Application Human-Program Static Monolithic HTML Search via search engine B2C HTTP/HTTPS
10 April 2009
Web Services - Key Terms

Web Service Model Producer Consumer Registry/Directory Message/Payload Protocol Endpoint Contract
1. Publishes Contract (WSDL) Service Provider
- Key Components Publish Find Bind
Are there services that meet my needs 2. Discovers (WSDL) 3. Binds Messages (SOAP) 4. Communicates Endpoint Address Service Consumer
Service Directory* (UDDI)
Producer
These are my services
An application whose function is packaged as a reusable component (Web Service) for use in a business process. The service either provides information or facilitates a change to business data from one valid and consistent state to another. A producer can also be a consumer of services exposed by some other producer
Consumer
An application that a locates a Web Service and invokes the operations it provides. A consumer can be producer of some other services
10 April 2009
10

Registry/Directory
Identifies and catalogs Web Services so they can be easily found online. The basis of the directory is a Web services specification called Universal Description, Discovery and Integration (UDDI)
Message/Payload
Refers to the "actual data" in a message minus all headers attached for transport and minus all descriptive meta-data
Protocol
Is a set of formal rules describing how to transmit data, especially across a network. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, character sets, sequencing of messages etc
Contract
Describes Functional requirements (what a provider will give to any consumer that chooses to abide by the terms of the contract) Specifies Non Functional Requirements (this includes information both about the responsibility of the providers for providing their functionality and/or data as well as the expected responsibilities of the consumers of that information and what they will need to provide in return, such as availability, security, and other quality of service considerations) Specifies the rules of engagement between consumers and providers, known as policies that govern who can access a provider, what security procedures the participants must follow, and any other rules that apply to the exchange
10 April 2009
11

Endpoint
Is an association between a binding and a network address, specified by a URI, that may be used to communicate with an instance of a service. An end point indicates a specific location for accessing a service using a specific protocol and data format
Publish
Refers to the interaction between Service provider and registry. The service provider publishes the service description to the service registry. Standards involved WSDL and UDDI
Find
Refers to the interaction between Service requestor and registry when the requester is trying to discover the required services. Standards involved WSDL and UDDI
Bind
Represents the interaction between Service provider and requestor. It is the step that allows an application to connect to a web service at a particular web location and start interacting with it. Standards involved are WSDL, SOAP/REST
Namespace
Just as a Java package is used for qualifying a Java class, allows the Java class to reside under a distinct hierarchical namespace and to avoid naming conflicts between classes, methods, etc., an XML namespace serves the same purpose for Web services. It qualifies the name for an XML element or attribute and helps avoid naming conflicts. XML namespaces are based on the need that URLs should be universally unique. However, the way that URLs are interpreted and mapped in the native code differs between platforms
10 April 2009
12
Adoption Trend Web Services

Highlights the adoption themes Degree of adoption for a theme
Source: Forrester While this report is from year 2004, the basic themes are still predominant
10 April 2009
13
Prevalence of Web Services

Key Element in contemporary SOA
Web Services resulted from the convergence of three important events Emergence of internet as a cost-effective and widespread infrastructure Extensive adoption of XML as a standard Emergence of a set of common Web services standards Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL) which have been accepted by major platform vendors in place of proprietary standards such as CORBA and DCOM
Web services are the most attractive and popular implementation mechanism for SOA
Well-suited for connecting heterogeneous worlds Simple and tool supported Standards-based, platform-independent service description Web Services design has built-in flexibility for loose-coupling
Most widely accepted set of standards across the industry
Building blocks are XML, SOAP, REST, WSDL, UDDI
10 April 2009
14
Contents
10 April 2009
15
Web Services Technology Stack

MESSAGING Network is the foundation layer for the Web services programming stack. All Web services must be available over some network. The network is often based on an HTTP protocol, but other kinds of network protocols, such as the Internet Inter-ORB Protocol (IIOP) or the IBM MQSeries, are also used XML-based Messaging layer that facilitates communications between Web services and their clients. The messaging layer is based on SOAP or REST Service Description defines metadata that fully describes the characteristics of services i.e. what a service can do, how the service delivers its interface, what the service expects of the caller when it uses the service, where it resides, and how to invoke it. WSDL is an XML format for describing the service
Composition
Infrastructure
Messaging
Discovery
10 April 2009
16
Web Services Technology Stack (continued..)

DISCOVERY Service Publication is any action by the service provider that makes the WSDL document available to a potential service requester e.g. publishing in a UDDI registry is one way of doing it Service Discovery is any action that gives the service requester access to the WSDL for a service. The action may be as simple as accessing a file or URL containing the WSDL or as complex as querying a UDDI registry and using the WSDL files to select one of many potential services COMPOSITION Service Flow facilitates the composition of Web services into workflows and the representation of this aggregation of Web services as a higher-level Web service INFRASTRUCTURE Security, Management and Quality of Service of web services need to be addressed in every layer of the stack and are essential to fulfill the business needs
Composition
Infrastructure
Messaging
Discovery
10 April 2009
17
Contents
10 April 2009
18
Web Services Standards
(WS-Security)
(WS-Reliability)
(WS-Transaction)
10 April 2009
19
Web Services Key Artifacts

XML (Extensible Markup Language) This a structured way of representing data. The structure is self describing. Example <name> <first>Bill</first> <last>Gates</last> </name> XML is Extensible Example <name> OR <first>Warren</first> <last>Buffet</last> </name> XML is machine readable and Transformable.
<name> <fullName>Bill Buffet</fullName> </name>
10 April 2009
20

XSD (XML Schema Definition) Represent a set of rules that defines an XML document. Categories of Rules Rules pertaining to Document Structure. Rules pertaining to Type of Data XML would contain.
Example Translates To <element name="name"> <sequence> <element name="first" type="string"/> <element name="last" type="string"/> </sequence> </element>
<name> <first>..</first> <last></last> </name>
10 April 2009
21

WSDL (Web Service Definition Language) WSDL is a document that contains a set of details that define a Service interface. Service definition has the following parts Types Provides data type definitions used to describe the messages exchanged. It represents the data structure that constitute the service signatures. Message Represents an abstract definition of the data being transmitted. It is the service data elements or I/O signature of service. PortType represents one or more Operation / methods exposed by a service, as well as the Message type associated with a that method. Each operation refers to an input message and output messages Binding Specifies concrete protocol and data format specifications for the operations and messages defined by a particular portType. It represents what interaction capabilities exposed by the service to consumers / clients. Capabilities could include SOAP, HTTP, JMS, EJBetc. Port - Specifies an address for a binding, thus defining a single communication endpoint. Endpoint - means URL to which the client needs to post the message to invoke the service Service Is used to aggregate a set of related ports and represents the Endpoint Address of a service. Service can have multiple Endpoints based on Bindings
Service Implementation Definition
Service
Port Binding
Service Interface Definition
Port Type Message Type
10 April 2009
22

Sample WSDL
10 April 2009
23

Logical WSDL Represents the abstract definition of a Service. WSDL does not contain any Binding or Endpoint details
10 April 2009
24

Concrete WSDL Represent a complete definition of a Service with Bindings and Endpoint URLs. Attaching the Binding and Service details to a Logical WSDL, creates a Concrete WSDL
10 April 2009
25

How WSDL works
10 April 2009
26

Standard Mappings from WSDL
Interoperability, is an ongoing challenge between SOAP implementations Basic mapping between Java types and WSDL/XSD/SOAP and care about specifying the namespace can be kept in mind while designing If the WSDL says that an object can be nillable, that is the caller may choose to return a value of nil, then the primitive data types are replaced by their wrapper classes, such as Byte, Double, Boolean The following is a mapping for quick reference
xsd:base64Binary byte[]
xsd:boolean
xsd:byte xsd:dateTime xsd:decimal
boolean
byte java.util.Calendar java.math.BigDecimal
xsd:double
xsd:float xsd:hexBinary xsd:int xsd:integer xsd:long xsd:QName xsd:short xsd:string
double
float byte[] int java.math.BigInteger long javax.xml.namespace.QName short java.lang.String
10 April 2009 27

Client Side Stubs
Client side stubs are local programs that facilitate invoking the methods of remote Web Services - a proxy to invoke the methods of a Web Service through a local interface Stub has the same API as that of its corresponding Web Services but the stub does not actually implement any of the business logic of the Web Service It forwards the method invocation using the appropriate protocol to the actual Web Service which processes the request and formulates the response and stub forwards it back to the calling application Client side stubs are generated from the WSDL file of the service Web Service platform provides tools that automatically generate these files facilitating developer's work e.g. Axis has WSDL2Java tool Once the client stubs classes are generated, include the directory containing the stub classes into the classpath The following is a summary of the type of classes that will be present in the client side
WSDL clause For each entry in the type section Java class(es) generated A java class A holder if this type is used as an inout/out parameter For each portType For each binding For each service A java interface A stub class A service interface A service implementation (the locator)
10 April 2009
28

Server Side Skeletons
A skeleton is a Java framework for the server side Server side skeletons derived from the WSDL file of the service Skeleton bean contains a set of methods that correspond to the operations described in the WSDL document The skeleton Java bean generated from WSDL file by tools has only a trivial implementation of each method that needs to be replaced with implementation logic before publishing the Web service The following is a summary of the type of classes that will be present in the server side WSDL clause For each binding Java class(es) generated A skeleton class An implementation template class
For all services
One deploy.wsdd** file

One undeploy.wsdd file
**Web Service Deployment Descriptor (WSDD)
10 April 2009
29
Web Services Key Artifacts WSDL Styles

Messaging Style
Web Services Description Language (WSDL) binding style can be RPC or document. A WSDL binding describes how the service is bound to a messaging protocol, particularly the SOAP messaging protocol. RPC - The RPC style specifies that the <soap:body> contains an element with the name of the Web method being invoked. This element in turn contains an entry for each parameter and the return value of this method Document - The message parts appear directly under the <soap:body> element. There are no SOAP formatting rules for what the <soap:body> contains. The server application is responsible for mapping the server objects (parameters, method calls, and so forth) and the values of the XML documents
Encoding Style
Encoding - Each message part references an abstract type using the "type" attribute instead of a schema. Applications using SOAP encoding are focused on remote procedure calls and will likely use the RPC message style Literal - Each part references a concrete schema definition using either the element or type attribute; in other words, data is serialized according to a given schema
WSDL Style/Model
It is a combination of Messaging Style and Encoding Style RPC/encoded, RPC/literal, Document/literal, Wrapped Document/literal exist. The choice depends on the needs though Wrapped Document/literal is most popular
10 April 2009
30

RPC/encoded
Complete method is specified in the WSDL file and in the SOAP body and includes the sent parameters and the return values. There is rather tight coupling with this style. The SOAP message will contain the encoded type information such as xsi:type="xsd:int", xsi:type="xsd:string", xsi:type="xsd:double"
Strength The operation name appears in the message, so that the receiver has an easy time dispatching the message to its implementation. If you are using data graphs or polymorphism in your service, this is the only possible style that can be used Weakness The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance. You will not be able to validate using a schema because the type information is stored in the message and not a schema. This will make validation more difficult. Any changes to the interface would break the contract between the service and the client since there is a tight coupling between service provider and client. It is not WS-Interoperability (WS-I) compliant Message <soap:envelope> <soap:body> <myMethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </myMethod> </soap:body> </soap:envelope>
WSDL <message name="myMethodRequest"> <part name="x" type="xsd:int"/> <part name="y" type="xsd:float"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../>
10 April 2009
31

RPC/literal
Style will remain RPC but the WSDL will now have the 'use' setting changed from 'encoded' to 'literal' in the soap:body. Which means the data is serialized according to the given schema
Strength The operation name still appears in the SOAP message Higher throughput performance since the type encoding is removed from the message Weakness Any changes to the interface would break the contract between the service and the client because there is a tight coupling between the service provider and the client. The schema describing an RPC/Literal message is not sufficient to validate that message. Is not supported by the WSI conformance standard Message <soap:envelope> <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body> </soap:envelope>
WSDL <message name="myMethodRequest"> <part name="x" type="xsd:int"/> <part name="y" type="xsd:float"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../>
10 April 2009
32

Document/literal
The client sends standard XML document to the server. The server application is responsible for mapping the server objects (parameters, method calls, and so forth) and the values in XML documents. The protocol places no constraint on how the document needs to be structured. Data is serialized according to the given schema
Strength No type encoding information in the SOAP message (Smaller footprint). You can always validate the message with a XML Schema. Since everything within the SOAP body is defined in the schema. The rules are less rigid and many enhancements and changes can be made to the XML schema without breaking the interface. WS-I compliant WSDL
<types> <schema> <element name="xElement" type="xsd:int"/> <element name="yElement" type="xsd:float"/> </schema> </types> <message name="myMethodRequest"> <part name="x" element="xElement"/> <part name="y" element="yElement"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> 10 April 2009
Weakness WSDL is a bit more complicated. The operation name in the SOAP message is lost. Without the name, dispatching can be difficult, and sometimes impossible
Message <soap:envelope> <soap:body> <xElement>5</xElement> <yElement>5.0</yElement> </soap:body> </soap:envelope>
33

Wrapped Document/literal
The input message has a single part which is an element. The element has the same name as the operation. The element's complex type has no attributes
Strength Contains all the strengths of Document/Literal style. The method name appears in the SOAP message WSDL
<types> <schema> <element name="myMethod"> <complexType> <sequence> <element name="x" type="xsd:int"/> <element name="y" type="xsd:float"/> </sequence> </complexType> </element> <element name="myMethodResponse"> <complexType/> </element> </schema> </types> <message name="myMethodRequest"> <part name="parameters" element="myMethod"/> </message> <message name="empty"> <part name="parameters" element="myMethodResponse"/> </message> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> 10 April 2009
Weakness If you have overloaded operations in your Web Service, you cannot use this style because WSDL requires an element to have the same name as the operation Message <soap:envelope> <soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body> </soap:envelope
34

SOAP (Simple Object Access Protocol) Messaging protocol that allows applications residing on one computer to interact with other applications residing on another computer
Other Definitions SOAP is based on XML format. SOAP is a format for sending messages between systems / applications. SOAP is platform independent. SOAP is language independent. SOAP is extensible protocol Parts of SOAP SOAPBody represents application data. SOAPHeader consist of data that is injected either at runtime or as per definition in WSDL. SOAP Envelope wraps SOAPHeader and SOAPBody. Attachments like .pdf, .txt, .xml files can be attached to SOAP Message in MIME format
SOAP Message has multiple parts
10 April 2009
35

UDDI (Universal Discovery, Description & Integration) Open Standard protocol that allows a service to be registered in UDDI compliant software application, so that it can be discovered in a systemic manner
UDDI is essentially used by client programs to dynamically discover services in their organization and to invoke them based on the binding details obtained, at runtime UDDI help establish the relationship of registered services with higher level business entities, thus helping efficient cataloging and searching of service in an Organization UDDI is one of the fundamental building block of Service Governance Methodologies UDDI specification is operationally supported by established standards like SOAP, WSDL, XML etc
UDDI
(2) Service Lookup
(1) Service Register
Client
(3) Service Invoke
Service
10 April 2009
36
UDDI Registry Data
White Pages
Businesses register public information about themselves
Yellow Pages Green Pages
Standards bodies, Programmers, Businesses register information about their Service Types
Service Type Registrations
10 April 2009
37
Pages
White Pages Business Name Text Description list of multi-language text strings Contact info names, phone numbers, fax numbers, web sites Known Identifiers list of identifiers that a business may be known by - DUNS, Thomas, other Yellow Pages Business categories 3 standard taxonomies in V1 Industry: NAICS (Industry codes - US Govt.) Product/Services: UN/SPSC (ECMA) Location: Geographical taxonomy Implemented as name-value pairs to allow any valid taxonomy identifier to be attached to the business white page Green Pages New set of information businesses use to describe how to do e-commerce with them Nested model Business processes Service descriptions Binding information Programming/platform/implementation agnostic Services can also be categorized
10 April 2009
38
UDDI Components
businessEntity
Peter Smythe 872-6891 4281 Kings Blvd, Sydney, NSW Peter@harbourmetals.co.au
TB993 Harbour Metals www.harbourmetals.co.au contacts businessServices identifierBag categoryBag
Serving Inner Sydney Harbour for
businessService businessService 23T701e54683nf Key Online Name catalog Website Descriptionwhere you can BindingTemplates BindingTemplates
BindingTemplate 5E2D412E5-44EE- http://www.sydneynet/harbour tModelInstanceDetails tModelInstanceInfo 4453D6FC-223C-3ED0 http://www.rosetta.net/catalogPIP
keyedReference
EE123 NAICS 02417 keyedReference DFE-2B DUNS 45231
tModelKeys
10 April 2009
39

Interoperability
Providing interoperability implies providing seamless and automatic connections from one software application to another SOAP, WSDL, and UDDI protocols define a self-describing way to discover and call a method in a software application regardless of location or platform. Data is marshaled into XML request and response documents and moved between software packages using HTTP or message-based protocols. All these aid interoperability Despite this, Interoperability problems creep in WS Definition Poorly constructed WSDL can cause interoperability problems Usage of custom data types are a challenge to interoperability testing WS Discovery UDDI enables businesses to host on-line registries of available Web services. Problem lies in the categorization of functions (based on what they do) so that they may be found UDDI defines TModels that are taxonomies to describe the location, path and character of the function but it allows multiple taxonomies and expects self-policing for mistaken entries in the registry. Problem!!! Atleast until the taxonomy experts add their practical knowledge of developing and maintaining directory structures in UDDI WS Message Exchange - Request/Response SOAP requests are basically XML documents. The flexibility of XML can be a problem for SOAP interoperability Some SOAP tools add explicit typing information into the request and response document and many others do not. If the WSDL does not define a response type then it is anyone's guess what type of object will be returned
10 April 2009
40

Representational State Transfer (REST) Application architecture modeled after the way data is represented, accessed, and modified on the web Outlines how to define and address sources of information known as resources (data and functionality) with a URI Describes the interface used to transmit domain-specific data over HTTP without the need for additional messaging layers or session tracking REST-based architectures communicate primarily through the transfer of representations of resources In the REST model, Resources are acted upon by using a set of simple, well-defined operations - GET, POST, PUT, and DELETE mapping to HTTP methods RESTful services are stateless
RESTful application are widely used for blogs as it simplifies the process of publishing information, For example, the Atom Publishing Protocol REST Principles imply that applications will be simple, lightweight, and have high performance
10 April 2009
41

REST can be used when Focus is on resource Web services are completely stateless A caching infrastructure can be leveraged for performance Service producer and service consumer have a mutual understanding of the context and content being passed along Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style Bandwidth is particularly important and needs to be limited. REST is particularly useful for limitedprofile devices such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted SOAP can be used when Focus is on activity A formal contract must be established to describe the interface that the web service offers (WSDL) Architecture must address complex nonfunctional requirements. Examples include Transactions, Security, Addressing, Trust, Coordination, and so on Architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards such as WSRM and APIs such as JAX-WS with their client-side asynchronous invocation support can be leveraged out of the box
10 April 2009
42

Security Common Security Requirements - Authentication, Authorization, Audit, Integrity, confidentiality, and nonrepudiation There are three fundamental concepts related to security: the resources that must be secured; the mechanisms by which these resources are secured (i.e., policy guards); and policies that describe constraints on these resources. Design Areas - Access Control, Security Policies, Distributed security policy enforcement, Message level security and Transport level security Message level security Refers to securing the content of the message by encryption XML Signature and XML Encryption are for XML security WS-Security is about SOAP security. WSSecurity is a broad description of a framework indicating how to secure Web services. It provides mechanism that allows
Digitally signing (using XML Signature) all or part of a SOAP message and passing the signature in the SOAP header Encryption (using XML Encryption) of all or part of a SOAP message
10 April 2009
Transport-level security Refers to securing the connection and complete communication between a client application and a Web Service Uses either HTTP Basic authentication, alone or in combination or Secure Sockets Layer (SSL)
43

Security Techniques used
Feature Encryption Digital Signature Authorization Technique XML-Encryption [XENC] W3C XML Signature [XSSP] Attribute certificate ("push" model) Description Enables a user to encrypt any element in the SOAP Envelope SOAP Header can be used to carry an XML Signature within the message and URI of an entity who is intended to validate it Obtain attribute certificates (or credentials) from an AA, which convey authorization information securely, and send the credential together with the request. The service provider checks the validity of the credential and allows access based on it. The SOAP Header can be used to attach such attribute certificates to SOAP messages and indicate the URI of an entity who is intended to validate it. If necessary, we should encrypt the certificates using the specified actor's public key
Related SOAP Elements Namespace prefix is SOAP-SEC Three SecTags <Encryption>, <Signature> and <Authorization>
10 April 2009
44

Reliability Web Services Reliability (WS-Reliability) is a generic and open model for ensuring reliable message delivery for Web Services. It defines reliable message delivery as the ability to guarantee message delivery to software applications with a chosen level of quality of service (QoS)
Guaranteed Delivery - ensure that all information to be sent actually received by the destination or error reported. Duplicate Elimination - ensure that all duplicated information can be detected and filtered out Ordered Message Delivery - ensure that Message Exchanges are forwarded to the receiver application in the same order as the sender application issued Crash tolerance - ensures that all information prescribed by the protocol is always available regardless of possible physical machine failure State synchronization ensures delivery status awareness for sender and receiver applications and reset Message Acknowledgement and Resending enabling an acknowledgment of receipt and resend models in case of error report
WS-Reliability specification Provides WSDL definitions for reliable messaging Provides message formats specified as SOAP headers and/or body content. Addresses the dependencies between the capacity of the messaging nodes (persistence, message processing) and the level of QoS that can be provided
WS-ReliableMessaging is the relevant OASIS standard
10 April 2009 45
Source: OASIS WSRM TC

Sample - Request Response Reliable Messaging
Notice the WSRM tags in the adjacent message!
Source: OASIS WSRM TC
10 April 2009
46

Transaction In service-oriented environments, operations commonly span across multiple, independent services There is a requirement for consistency in these situations i.e. all individual operations should succeed, or, if something goes wrong, no operation should be completed Web Services Transactions specifications Define mechanisms for transactional interoperability between Web services domains Provide a means to compose transactional qualities of service into Web services applications Needs for transactional behaviour depend on the types of scenarios present: Short duration ACID transactions Longer running business transactions WS-Coordination and WS-Transaction define a mechanism for maintaining coordination context across different SOAP messages, enabling a transaction-like scenario in web services Specifications for different coordination types are: WS-AtomicTransaction (Short duration), WSBusinessActivity (Longer running business transactions)
Source: David Chappell, IBM
10 April 2009
47

WS-Coordination Involves an activation service to create a business activity Provides a registration service that allows systems to register themselves with the coordinator and indicate the Interaction protocol Coordinator interacts with the participating systems based on the contacts and interaction model provided at the time of registration WS-Atomic Transaction Involves a commit or rollback a transaction across multiple systems Basis is two-phase commit Ensure ACID properties 2 Phase is prevalent and shown in Figure Protocols Possible Completion protocol A participating Application decides to trigger the completion Asks coordinator to either commit or rollback the changes
Protocol in short duration Atomic Transaction
2 Phase protocol Coordinator sends prepare, rollback or commit messages to the core systems
10 April 2009
48

WS-Business Activity Each business activity consists of independent business tasks Each business task is owned and carried out by a participating application Compensation mechanisms are defined upfront as a means of maintaining consistency Participating applications send coordinator fault or completed messages to indicate the outcome of the business task When completed messages from all core systems is received, coordinator sends close messages to them to end their business tasks If applications have fault message, the coordinator sends compensate messages to systems that had completed their business tasks to get reverse the effects of the tasks they performed
Protocol in long running Business Activity
10 April 2009
49

Orchestration Services based architectures need Orchestration for various reasons: To compose Business processes from services and human activities To create coarse grained business services from fine grained services To provide Integration flows to integrate various applications The architected processes need to be orchestrated for providing agility, end-to-end control, visibility, and exception management. Orchestration requirements include: Execution sequencing - serial, parallel, or other kinds of control flow dependency patterns Exception handling including transactions and compensations Data flow and manipulation Event handling including timers and other out-of-band events WS-BPEL defines the standard or model and a grammar for describing the behavior of a business process based on interactions between applications, systems, and people such that they achieve a business goal
10 April 2009
50

Orchestration Example Scenario Order Booking
SHOPPING PORTAL
ESB
Order Booking BPEL PROCESS
receive
Order DB
Insert Order
Rules repository
Rule Author
Web Services Interface: XML, SOAP, WSDL, WSIF
getCustInfo
Rules Engine
EJB 3.0 Customer service
Decision Service
Manual Review ?
Rapid Dist.
Select Mfr
Approval (Rich Workflow)
invoke
invoke
5-15 min
ESB
receive
receive
Product Suppliers
Fulfill Order FedEx USPS
Notify Cust
Notification Service
end
Source: Oracle
10 April 2009
51

BPEL Tool Graphical Editor View
Source: Oracle
10 April 2009
52

Introduction to Service Component Architecture (SCA)
Provides a model for the assembly of composite application development and forms the basis of most SOA deployments. These composite applications may be based on collections of individual services. Emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services Addresses the need for control over access and security, while simplifying the development of creating business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats. SCAs Java programming model relies on annotations rather than API calls and this approach makes creating a basic service quite easy The specification is not limited to Java environments SCA divides up the steps in building a service-oriented application into two major parts:
Implementation of service components which provide services and consume other services. Assembly of sets of components to build business applications, through the wiring of service references to services
10 April 2009
53

Introduction to Service Component Architecture (SCA) .continued Definitions
SCA defines a generalized notion of a component. Every SCA application is built from one or more components It also specifies how those components can be combined into larger structures called composites Both components and composites are contained within a larger construct called a domain A given environment that installs a group of SCA products is known as runtime Each component typically implements some business logic, exposed as one or more services Binding specifies how communication should be done between an SCA component and something else SCA allows each remotable service and each reference to specify multiple protocols it supports using bindings
10 April 2009
54

Introduction to Service Data Objects (SDO) SDO is a specification for a programming model that unifies data programming across data source types Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web services, and enterprise information systems It has a composable (as opposed to monolithic) architecture It provides the base APIs that are applicable to all types of data sources and does not presume a particular query language or a particular back-end store Access to data sources is provided by a class of components called data mediator services. A data mediator service is responsible for querying data sources, creating graphs of data containing data objects, and applying changes to data graphs back to data sources Benefits Decoupling of application code from data access code Unified data access to heterogeneous data sources Support for custom data access layers based on common design patterns
Source: BEA, IBM
10 April 2009
55
Contents
10 April 2009
56
Messaging Models
Request-Response
Most frequently used model where the Service Consumer makes a request to the Service Provider and receives a response in return from the Service Consumer Response can be the results of business processing the message, an acknowledgment of receipt or description of an error condition In WSDL, input, output and fault elements are defined for such an operation
Some form of time-out and retry management needs to be designed for robustness Synchronous and Asynchronous forms of this model exist Asynchronous model is used in long running interaction and requires the consumer to have the capacity to pass a reply address and match response to initial request (correlation)
One-way/Fire-and-Forget
Unidirectional where there is no reply expected from the Service for the submitted message In WSDL, only input element is defined for such an operation Typical implementation for asynchronous scenarios Stateless and scalable Drawback is that error handling is not possible and different mechanism for handling invalid message or processing errors has to be created
10 April 2009
57
Messaging Models
Notification
Unidirectional invocation where message is only sent In WSDL, only output element is defined for such an operation
Typical implementation for an alert/notification scenarios that are needed while building agents A variant of this model is a Solicit-Response model where there is a reply returned. In this the initial message will have only output element populated and the reply has the input element populated
Subscribe-Push
Combination of message models Typical implementation for an subscribe/notification scenarios A Subscribe is initially sent. This is commonly a Oneway message or at times it is a Request-response where an acknowledgment of the subscription is sent back. A Subscribe message may enlist one or more parties based on how the message or service is structured When the corresponding event occurs, a Notification message is pushed to the subscribers
10 April 2009
58
Discovery Models
Property File Lookup
Sample and straight forward to implement Property file contains target service (key) and endpoint URL (value) for the services Setting up complex look-up criteria might difficult, since details are set as key / value pair
Database Lookup
Simple and straight forward, with custom schema to hold service details Provider service Name or ID is mapped to endpoint URL for service lookup Relatively complex service look-up criteria can be modeled Database could be extended to act as custom service repository
Service Registry Lookup

Provider publishes service details as part of a centralized registry and consumers dynamically look-up for the required service When Producers periodically pushes changes to the registry, the Consumers are notified of the changes and their client configuration can reflect the changes Public Registries (typically UDDI) maintained and synchronized by companies are available, at no charge, to all users Private Registries - Individual enterprises or industry consortiums maintain these registries, control what service data are registered and who can access the data
Source: Adobe
10 April 2009
59
Discovery Models
Inspection
Based on WSIL, it is a distributed model for service discovery Service descriptions can be stored at any location, and requests to retrieve the information are made directly to the service provider to ask for the services it provides Simple and Extensible definition where users can incorporate custom service attributes specified by a custom namespace Enables focused discovery to be performed on a single target
Probe and Match

Based on WS-Discovery (dynamic discovery) standard Client sends a broadcast message to a set of endpoints prompting them to respond to a set of criteria Endpoint where the probe matches responds to help locate the service Can be network intensive and hence less preferred than Registry lookup Variant of this model can be to a probe on multiple registries simultaneously instead of the service endpoints
10 April 2009
60
Service Contracts
Definition
Describes Functional features Determines the interface it provides Specifies the rules of engagement between consumers and providers i.e. policies Outlines the Non-functional features i.e. security, quality-of-service (QoS), transactional characteristics
While designing Web Services, attention is paid to the following contract types: Service Contract
Describes
Capabilities or operations supported Message exchange pattern/messaging models supported Invocation mechanism and format of each message
Fault Contract
Describes
How error conditions are handled Details about the exception & associated data to be sent
Care should be taken about sending too much information
It is the driver for generating a service description so a service must implement at least one service contract
Data Contract
Describes
Message interchange format using the XML Schema
Message Contract
Describes
How the SOAP message is built i.e. how/when to add custom SOAP headers to incoming and outgoing messages
It typically maps to the <type> element in the WSDL
10 April 2009
61
Web Services Versioning

Types of Versioning
Implementation Type Contract Degree of Impact
Implementation Change
Change to internal implementation can be for Performance enhancements Better algorithms Security enhancements More data sources No breaking changes No change to message schema or contract Therefore the invoker does not perceive it as a version change at all
Source: Microsoft
10 April 2009
62

Types of Versioning
Type Change
Achieved by using very loosely defined types as arguments to methods i.e. the message schema will indicate that the method can take XmlAny as an argument Advantage is that it is very easy to version the service and accept different data over time. Disadvantages is that you must continue to fully support all versions of messages This mechanism does not provide any information to the invoker about the message schema
[WebMethod()] [SoapDocumentMethod(ParameterStyle=ParameterStyle.Bare)] public string AddPerson(object person) {...} [WebMethod()] [SoapDocumentMethod(ParameterStyle=ParameterStyle.Bare)] public string AddPerson(string person) {...} [WebMethod()] [SoapDocumentMethod(ParameterStyle=ParameterStyle.Bare)] public string AddPerson(XmlElement person) {...}
Source: Microsoft
10 April 2009
63

Types of Versioning
Type Change (continued)

Achieved by using Open Content Model i.e. Extensible Design Pattern Core type is described in the message schema Type is extensible allowing additional data to be provided over time Type can also contain a version field so that different versions can be intelligently processed
[XmlType(Namespace="http://people")] public class person { public string version; public string name; public string ssn; [XmlAnyElement()] public XmlElement[] Any; [XmlAnyAttribute()] public XmlAttribute[] AnyAttr; }
Source: Microsoft
10 April 2009
64

Types of Versioning
Type Change (continued)

Achieved by determining version at runtime and handling version of type appropriately
public string AddPerson([XmlElement(Namespace="http://people")] Person person) { switch (person.version) { case "1.0": return DoAddPersonV1(person); default: return DoAddPersonV2(person); } }
Source: Microsoft
10 April 2009
65

Types of Versioning
Contract Change
Version the URI when backward compatibility cannot be maintained. Do this by using a date or version encoded URI Date Encoded: http://foo.org/2003/05/23/Invoice Version Encoded: http://foo.org/v2.0.4822.2/Invoice Contract is bound to the URI, hence when changing the URI, contract can also be changed When the client wants to use the newer service, they can make the necessary changes to make the client compatible with the newer version of the service, then switch over to the new URI Useful when need to maintain multiple versions of service side-by-side
Source: Microsoft
10 April 2009
66
Web Services Design Considerations

Common
Match the Web Services protocol to the application needs
Keep the Web Services interaction stateless so that it is easier to scale and make fault tolerant by increasing redundancy
Choose the right layer for implementing the Web Services. The deeper the architectural layer you expose through your Web service, the more you sacrifice scalability, greater the security requirements are, and deeper the dependency between the Web service and the consumers. But it provide consumers with greater control over how they use your application's services
Prefer toolkits where there is no vendor lock-in Pay attention to interoperability. Test in heterogeneous environment to be sure Plan for security requirements and evaluate if there is a need for encryption in addition to the transmission level security provided by using SSL (HTTPS) Carefully choose between synchronous and asynchronous implementations Incorporate Error Handling. A robust mechanism is to translate FAULT SOAP responses to exceptions on the client end, and to catch exceptions and return FAULT responses on the server end
10 April 2009
67
Web Services Design Considerations

Interoperability
Design the XSD and WSDL first, and program against the schema and interface If at all possible, avoid using the RPC/encoded style Wrap any weakly-typed collection objects with simple arrays of concrete types as the signature for Web service methods Avoid passing an array with null elements between Web services clients and servers Do not expose unsigned numerical data types in Web services methods. Consider creating wrapper methods to expose and transmit the data types Take care when mapping XSD types to a value type in one language and to a reference type in another. Define a complex type to wrap the value type and set the complex type to be null to indicate a null value. Because base URIs are not well-defined in WSDL documents, avoid using relative URI references in namespace declarations To avoid conflicts resulting from different naming conventions among vendors, qualify each Web service with a unique domain name. Some tools offer custom mapping of namespaces to packages or provide refactoring of package names to resolve this problem Develop a comprehensive test suite for Web Services Interoperability Organization (WS-I) conformance verification
Source: developerFusion
10 April 2009
68
Web Services Design Considerations (continued..)

Performance
XML traffic is 15 to 20 times larger in payload than binary-encoded traffic. The network and processing overhead associated with XML is one of the major hindrances to Web services performance. There may be a need to balance tradeoff between performance and interoperability, good application design can maximize both. Solution options Vertically scale application by adding more central processing units, memory and storage, or horizontally scale it through techniques such as clustering (primarily for stateless applications) Include XML-aware switching products, such as those offered by Cisco appliances, to get closer to the network layer and improve the performance and security of exchanging XML messages Use specialized hardware accelerators to distribute XML processing by using appliances and accelerators in the presentation and application layers of the network, such as those offered by DataPower and Reactivity Use an optimized software and compression approach, or use binary XML to replace the unparsed, text-based XML format Perform certain activities early in the development lifecycle, such as modeling for performance and capacity
Chatty calls. Network round trips to and from a Web service can be expensive. This issue is magnified if clients need to issue multiple requests to a Web service to complete a single logical operation. Solution options
Design chunky interfaces by exposing Web methods that allow your clients to perform single logical operations by calling a single Web method. Provide methods that accept multiple parameters to reduce roundtrips. Design Web services that wrap a set of business objects instead of creating a Web service for each of your business objects. Use Web services to abstract these objects and increase the chunkiness of your calls
10 April 2009
69
Web Services Design Considerations (continued..)

Performance (continued..)
Lack of caching or inefficient caching. In many situations, application or perimeter caching can improve Web services performance. Solution must take into account Caching-related issues that can significantly affect Web services performance are failure to use caching for Web methods, caching too much data, caching inappropriate data, and using inappropriate expiration settings Caching design for a Web service must consider issues such as how frequently the cached data needs to be updated, whether or not the data is user-specific or application-wide, what mechanism to use to indicate that the cache needs updating
Inefficient Web method processing where schema is not used to validate input upfront. This issue can be significant because the Web method may de-serialize the incoming message and then throw exceptions later on while processing the input data
It can be more efficient to accept the validation overhead to eliminate unnecessary downstream processing Unless there is a probability of receiving invalid input frequently, avoid schema validation due to the significant overhead that it introduces
Bulk Data Transfers. Approaches to optimize Bulk Data Transfer and Attachments
Send the data one chunk at a time. Offload the transfer and return a URL from your Web service which points to the file to be downloaded Use Compression when you are constrained primarily by network bandwidth or latency e.g. use a SOAP extension to compress the SOAP messages
Avoid Calling Local Web Services. Calling a local Web service means that the request goes through the entire processing pipeline and unnecessarily incurs overhead, including serialization, thread switching, request queuing, and de-serialization
Source: Microsoft
10 April 2009
70
Contents
10 April 2009
71
Web Services - Environment

Deployment Environment
Component Deployment consisting of tools that will expose existing application parts (components, programs, and objects) as Web Services. The capabilities include creating WSDL, the wrapper, and the SOAP interface for each Web Service, and listing the service on a UDDI registry or other directory WSDL and XML Schema Support to provide descriptions of all deployed Web Services for potential clients, and support the XML data typing system. SOAP Support to provide, or integrate with, a SOAP Service that manages the sending, routing and receiving of SOAP messages, XML-to-language type mapping, application invocation, and propagation of error messages Runtime to provide an application runtime environment for Web Services with configuration and lifecycle management, provide fault tolerance and recovery, log, trace, and enable performance tuning of active environment Security to provide runtime services for providers and requestors to verify authentication, proof of origin, message integrity, and message privacy
APPLICATION SERVER
Development Environment
WSDL/XSD editor (possibly graphical) for
Building WSDL and XSD files without knowing the XML syntax underneath Visualizing Web services their interfaces, data structures, etc.
Validation tools for XML schema, WSDL files, WS-I compliance Wizards to create Web services
Top-down Start with a WSDL interface, go to code Bottom-up Start with code, generate the WSDL interface
Supports for SOAP Engine e.g. Apache Axis
Runtime
Security
Component Deployment SOAP Description
DIRECTORY SERVICES
Web Services Deployment
UDDI
Source: Adobe
10 April 2009
72
Sample Web Services Deployment Topology

SIMPLE TOPOLOGY
SERVICE CLIENTS
SERVICES WEB SERVERS
DB SERVERS
10 April 2009
73
Sample Web Services Deployment Topology

SAMPLE TOPOLOGY
SERVICE CONSUMER SERVICE CLIENTS External Systems External Systems SERVICE PRODUCER
APPLICATION SERVER
WEB SERVER
Enterprise Applications
Security Services
Enterprise Services
LDAP SERVICE CONSUMER IDENTITY & ACCESS MANAGEMENT
ADAPTER
ADAPTER
ADAPTER
ADAPTER
Siebel
SAP Others SERVICE PRODUCERS
Databases
10 April 2009 74
Web Services in Legacy Asset Wrapping Scenario

Exposing existing application as Services
Sample scenario where the functionality of a CICS application needs to be reused Application is exposed as a Web Service and consumed by the Consumer application Consumer sends a SOAP message to a CICS Transaction Gateway using HTTP or Websphere MQ On receiving the SOAP request, CICS converts the information from the SOAP message to data in the COMMAREA and executes the CICS transaction When the transaction completes, CICS uses the data in the COMMAREA to create a SOAP response, which is sent back to the service consumer
Key considerations for using the direct exposure pattern:

The service requirements map closely to the application functionality and data. Thus, there is no need to access other capabilities using Java. hence the direct exposure as service There is no requirement to customize the information going to and coming from the realization asset Since there was no requirement to write additional code, direct exposure will save development and testing time
Source: IBM Redbooks
10 April 2009
75
Web Services in a Portal Scenario

Objectives for the Web Services Standard
Any party should be able to create and publish their content and applications as user-facing web services that can be easily plugged into standards-compliant portals Enable browsing of directories for WSRP services to plug into portals without significant programming effort Enable portals publish portlets so that they can be consumed by other portals without programming
Web Services for Remote Portlets (WSRP)

Web services protocol for aggregating content and interactive web applications from remote sources Standard for interactive, user-facing web services that plug and play with portals It defines:
A WSDL interface description for invocation of WSRP services How to Publish, Find, Bind WSRP services and metadata Markup Fragment Rules for markup emitted by WSRP services and applicable Security
Source: OASIS WSRP TC
10 April 2009
76
Web Services in a Portal Scenario (continued..)

WSRP Architecture
WSRP Producer: Web service that offers one or more portlets and implements a set of WSRP interfaces, thus providing a common set of operations for consumers. WSRP Portlet: A WSRP portlet is a pluggable user interface component that lives inside of a WSRP producer and is accessed remotely through the interface defined by that producer. WSRP Consumer: Web service client that invokes producer-offered WSRP Web services and provides an environment for users to interact with portlets offered by one or more such producers
Sample usage scenario:
10 April 2009
77
Thank You
SOA Services Team TEG
With inputs from:

EAI Services Team TEG Foundation J2EE Services Team J2EE

See Also
https://knowmax.ultimatix.net/sites/learning-corpfn/clp/tm/default.aspx?RootFolder=/sites/learningcorpfn/clp/tm/Technology%20Training%20Program%20Material/Instructor%20Led%20Courseware/Web%20Technologies&FolderCTID=&View={292FB5900BE3-4F2D-9BC2-3C15E4E67CB5}
10 April 2009
TCS Public

Web Services

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Web Services

Hochgeladen von

Copyright:

Verfügbare Formate

SOA Web Services

Development & Deployment

SOA Services - TEG

Collaborative Business Scenarios

Flight Reservation Ordering Cruise Reservation

Hotel Reservation Manufacturing

Present-day influences on Business

Need for Web Services

There is a need to fundamentally change the way applications communicate.

Web services have the ability to bring this change!

Proprietary Private, Static Proprietary, binary Private Networks

Interface Definition Function Accessibility

OPEN Standard Public & Dynamic OPEN Text Firewall Friendly

J2EE/ EJB COM/ DCOM CORBA

Web Applications vs. Web Services

Web Services - Key Terms

- Key Components Publish Find Bind

Service Directory* (UDDI)

These are my services

Web Services - Key Terms

Web Services - Key Terms

Adoption Trend Web Services

Prevalence of Web Services

Most widely accepted set of standards across the industry

Building blocks are XML, SOAP, REST, WSDL, UDDI

Web Services Technology Stack

Web Services Technology Stack (continued..)

Web Services Standards

Web Services Key Artifacts

<name> <fullName>Bill Buffet</fullName> </name>

Web Services Key Artifacts

<name> <first>..</first> <last></last> </name>

Web Services Key Artifacts

Service Implementation Definition

Service Interface Definition

Port Type Message Type

Web Services Key Artifacts

Web Services Key Artifacts

Web Services Key Artifacts

Web Services Key Artifacts

Web Services Key Artifacts

Web Services Key Artifacts

Web Services Key Artifacts

For all services

One deploy.wsdd** file

Web Services Key Artifacts WSDL Styles

Web Services Key Artifacts WSDL Styles

Web Services Key Artifacts WSDL Styles

Web Services Key Artifacts WSDL Styles

Message <soap:envelope> <soap:body> <xElement>5</xElement> <yElement>5.0</yElement> </soap:body> </soap:envelope>

Web Services Key Artifacts WSDL Styles

Web Services Key Artifacts

Web Services Key Artifacts

(2) Service Lookup

(1) Service Register

(3) Service Invoke

UDDI Registry Data

Yellow Pages Green Pages

Service Type Registrations

TB993 Harbour Metals www.harbourmetals.co.au contacts businessServices identifierBag categoryBag

Serving Inner Sydney Harbour for

Web Services Key Artifacts

Web Services Key Artifacts

Web Services Key Artifacts