Transcript ppt

EMTM 600
Software Development
Spring 2011
Lecture Notes 4
Assignments for next time
•
Read chapters 1, 2, and 4 from the Cloud Computing textbook. Two days
before the next lecture email me THREE OR MORE QUESTIONS about
stuff you didn’t understand. Each student.
EMTM 600 2011
Val Tannen
2
What is a service?
1.
2.
3.
4.
A software component …
… grouping a set of related capabilities …
... whose interface is not programming language-specific …
... and able to function independently in a distributed
environment.
If there was only 1. and 2. then any software module would do!
Part 3. of the definition usually also means “loosely coupled” to specific
operating systems, not just language-independent.
But it doesn’t preclude interface languages (eg. IDL for CORBA or XML)
Part 4. of the definition often comes with the addition: “loosely coupled” to
other components/services.
EMTM 600 2011
Val Tannen
3
What is Service-Oriented Architecture
(SOA)?
•
Software architecture whose building bricks are (mostly) services.
•
Service capabilities are typically invoked in a distributed manner, over
networks.
•
A convenient way to integrate existing (legacy) applications by
packaging their use into one or more services.
•
SOA describes how services provide their capabilities by consuming the
capabilities of other services, etc. (Just like software modules use each
other.) In particular, it can describe service composition, yielding more
complex services by combining simpler ones.
•
Group of services toward a common goal: service inventory, described
by a service catalog.
•
The usual principles of good software development apply: abstraction,
modularity, reusability, incrementality, etc.
EMTM 600 2011
Val Tannen
4
Service Implementations
1) Certain kinds of components of software frameworks:
•
•
•
CORBA server objects (not a CORBA “service”)
Java EE session EJBs
.NET “serviced components” (using COM+ services)
Capabilities are just OO methods, much like an API, can be invoked
directly from other programs. Interfaces are framework-specific,
even language-specific. Often ties development to proprietary
solutions.
2) (SOAP) Web Services
Capabilities are “operations” with XML arguments and XML results.
Interfaces are described with WSDL and XML Schema. Vendorneutral.
3) REST Services (a.k.a. RESTful web services or web API)
Capabilities consist of retrieving/updating “resources” identified by URIs.
EMTM 600 2011
Val Tannen
5
SOA for (SOAP) Web services (1.0)
Web services need to be described, located and invoked.
SOA for Web services is a collection of specifications for these three
functionalities. The big players are:
SOAP = Simple Object Access Protocol (pretty stupid name, no?), an XML
messaging protocol
WSDL = Web Services Description Language, a language for specifying
the “types” of the operations offered by a Web service
A service registry, encompassing a service inventory and a service
catalog that collects the metadata , i.e. the (WSDL) descriptions.
Originally proposed via UDDI = Universal Description Discovery and
Integration, now less automated and more manual…
EMTM 600 2011
Val Tannen
6
SOA 1.0: how it works
Service
Service
“contract”
Service“contract”
“contract”
Service
Registry
UDDI Business Registries
IBM, Microsoft, HP, SAP, etc
Publish
Find
WSDL
Service
“contract”
Service
Provider
Bind/Invoke
SOAP
EMTM 600 2011
Val Tannen
Service
Service “contract”
Consumer
WSDL
7
XML Messaging
 XML Messaging means that XML documents are exchanged
between applications
 How could we define a concept of the end-to-end message path in
a transport independent manner?
Document Centric Messaging
XML
XML
XML
Document
Document
Document
A new defined layer
HTTP
Programming
Programming
Programming
API
API
API
SOAP
SMTP
Application
Messaging
IIOP
Transport
Fast!
EMTM 600 2011
Val Tannen
8
Communication Protocol Suites (Stacks)
…
Web service
.NET comp.
SOAP
RESTful
VoIP
JavaEE comp.
DNS
HTTP
RMI
SSH
TCP
UDP
IP
Application
IIOP
Messaging
“Application”
Transport
Internet
…
EMTM 600 2011
Val Tannen
9
SOAP
 SOAP provides a simple and lightweight mechanism for exchanging
structured and typed information between nodes in a decentralized,
distributed environment by using XML
 The main use for SOAP is RPC (Remote Procedure Call) which
originated in the 1970’s with efforts to expand the functionality of the
ARPANet (later became the Internet).
 Warning: SOAP does not itself define any application semantics
such as a programming model or implementation specific
semantics!
EMTM 600 2011
Val Tannen
10
SOAP Features
Platform independent
Language independent
It is transport agnostic but most used is its binding to
HTTP
It is defined by W3C at
http://www.w3.org/TR/SOAP/
Extension for carrying attachments (like email)
Used for RPC (Remote Procedure Call) but with XML
arguments and XML result
EMTM 600 2011
Val Tannen
11
SOAP Blocks
 Envelope element (required) that identifies the XML document as a
SOAP message
 Header element (optional) that contains header information
 Body element (required) that contains contains mandatory
information for the message receiver
 Fault element (optional) that provides information about errors that
occurred while processing the message
EMTM 600 2011
Val Tannen
12
Sample Encoding of Call Requests (*)
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI"SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>SUNW</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
EMTM 600 2011
Val Tannen
13
Sample Encoding of Response (*)
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI"
xsi:type="xsd:int" mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>3.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
EMTM 600 2011
Val Tannen
14
WSDL
WSDL stands for Web Services Description Language
WSDL is written in XML (it’s an XML document)
WSDL is used to describe Web services
WSDL is also used to locate Web services
EMTM 600 2011
Val Tannen
15
WSDL Description
WSDL defines an XML grammar for describing network services as
collections of communication endpoints capable of exchanging
messages
A WSDL document defines services as collections of network
endpoints, or ports
Messages are abstract descriptions of the data being exchanged
Port types are abstract collections of operations
The concrete protocol and data format specifications for a particular
port type constitutes a reusable binding
A port is defined by associating a network address with a reusable
binding. A collection of ports define a service
EMTM 600 2011
Val Tannen
16
WSDL Architecture
 WSDL is a layered approach to defining a service
interface
Abstract – logical view of the service
Messages: representing data flows to and from the service
Port Type: representing a set of operations supported by one or
more endpoints
Concrete – physical view of the service
Binding: defines the specific network protocol and data format
used for a given port type
Port: defines a single endpoint for a given binding
EMTM 600 2011
Val Tannen
17
WSDL – Logical – Physical
7
1
2
6
3
5
4
EMTM 600 2011
Val Tannen
18
2
EMTM 600 2011
<message> Element
Val Tannen
19
3
EMTM 600 2011
<operation> Element
Val Tannen
20
WSDL Operation patterns
<input>
One-way
Client
<input>
Request-Response
1
Solicit-Response
EMTM 600 2011
Val Tannen
B
Service
C
Service
D
<output>
Client
Client
Service
<output>
<input>
Notification
A
1
Client
2
Service
<output>
2
21
Binding to SOAP Example (*)
<message name="getGradeRequest">
<part name="grad" type="xs:string"/>
</message>
<message name="getGradeResponse">
<part name="value" type="xs:float"/>
</message>
<portType name="courseGrades">
<operation name="getGrade">
<input message="getGradeRequest"/>
<output message="getGradeResponse"/>
</operation>
</portType>
<binding type="courseGrades" name="b1">
<soap:binding style="document” transport="http://schemas……" />
<operation>
<soap:operation soapAction="http://EMTM600/getGrade"/>
<input> <soap:body use="literal"/> </input>
<output> <soap:body use="literal"/> </output>
</operation>
</binding>
EMTM 600 2011
Val Tannen
22
Good Practices
EMTM 600 2011
Val Tannen
23
UDDI
 Universal Description, Discovery, and Integration
A project to speed interoperability and adoption for
web services
Standards-based specifications for service description
and discovery
Shared operation of a Business Registry on the web
Partnership among industry and business leaders
EMTM 600 2011
Val Tannen
24
UDDI Implementation
UDDI Business Registry
Manufacturers
Programmatic descriptions of
web services
Programmatic descriptions of
businesses and the services they
support
Programming model, schema,
and platform agnostic
Uses XML, HTTP, and SOAP
Free on the Internet
Flower Shops
Marketplaces
EMTM 600 2011
Val Tannen
25
SOA 2.0: just compose Web services!
Service
Registry
Publish3
Publish1
Find 1,2,3
Service
Requester
Bind1/
Invoke1
Service
Provider1
Compose
BPEL
Bind2/
Invoke2
Service
Provider2
Publish2
EMTM 600 2011
Val Tannen
Bind3/
Invoke3
Service
Provider3
Business Process
Execution Language
26
WS-BPEL and WS-CDL
 WS - Business Process Execution Language
 WS - Choreography Description Language
 Languages for “orchestrating” the composition of web services
 XML-based syntax
 WS-CDL standardized by W3C
 BPEL 1.0 was developed jointly by IBM, BEA, SAP, Siebel, and Microsoft
 Standardized by OASIS (org “rival” to W3C!) as WS-BPEL 2.0
 Practically full-fledged programming languages
 Control constructs for testing conditions and repetition, etc
 Variables in which values can be copied and then retrieved
 Basic statements are invocations of existing web services
 Bindings to WSDL and SOAP/HTTP have been specified
 To use them you need execution engines!
EMTM 600 2011
Val Tannen
27
BPEL (CDL) cont’d
 Developing BPEL “programs” is very much like specifying workflows
 But writing directly in the XML-based syntax is horrendous
 Development tools with visual interfaces: create boxes corresponding
to the control structures and the variables, drag and drop service icons
to build the composition
 Great for SMALL tasks
 It’s dangerous to write a BPEL script as complicated as a program in,
say, Java (you can, but you shouldn’t!).
EMTM 600 2011
Val Tannen
28
REST Architecture
REST stands for unmemorable “Representational State Transfer”.
Software architecture principles for distributed systems with hyperlinks
(i.e., the Web!).
Clients send requests, servers provide responses. Servers function in a
stateless mode. If the interaction logically has state, then the state is
maintained by the client and it accompanies each request from client
to server.
Goal is “use of resources.” Server response is a resource
representation, i.e., data that captures its state. It contains
hyperlinks that may be used in next client request.
Thus, a client is either in transition between states or "at rest”, when it
can interact with its user, without on the servers or on the network.
Hence the cute acronym REST.
EMTM 600 2011
Val Tannen
29
RESTful web services
The capabilities of RESTful services are based on HTTP (the WWW
protocol) whose URI paths and methods (GET/POST, PUT,
DELETE, etc.) capture the interface:
Resources are identified by URIs and are of two kinds: collection and
element. Methods may work differently on each. Eg., GET(a
collection) returns a list of the URIs of the elements of the collection.
While GET(an element) returns the element (according to its MIME
type)
PUT/DELETE are rarely used outside of RESTful services. PUT
inserts/updates information on the server. DELETE removes
information from the server. This assumes that the server maintains
a forest of URI-indexed information.
REST was basically devised to advertise HTTPs capabilities. But it’s a
lot simpler than SOAP and developers love it!
EMTM 600 2011
Val Tannen
30
WSDL and BPEL for RESTful services
Initially, WSDL and BPEL had mainly support for RPC (i.e., SOAP) style
web services.
WSDL 2.0 allows developer to specify RESTful services with the
addition of an HTTP-specific sub-namespace.
There are proposals for extending BPEL to cover RESTful services,
in particular in the open source Apache ODE (Orchestration Director
Engine).
By the way, WSDL and BPEL specifications are formatted in XML!
EMTM 600 2011
Val Tannen
31
Alternatives to XML
RESTful services can transfer XML-encoded resource state. But most
developers today prefer alternatives which are easier to read by
humans:
JSON (JavaScript Object Notation). (Not really object-oriented: “objects”
are sets of key-value pairs. Can be statically typechecked using
JSON Schema. Works well with AJAX and developers love it!
YAML (“recursive” (!) acronym: YAML Ain’t Markup Language). Like
JSON but even more human-readable. Without quotes or braces,
uses indentation instead.
SOX (Simple Outline XML) Just a compressed way of writing XML while
avoiding some of the angle brackets and tags…
EMTM 600 2011
Val Tannen
32
JSON
YAML
{
--receipt: Oz-Ware Purchase Invoice
date: 2007-08-06
customer:
given: Dorothy
family: Gale
items:
- part_no: A4786
descrip: Water Bucket (Full)
price: 1.47
quantity: 4
- part_no: E1628
descrip: |
High Heeled
"Ruby” Slippers
size: 8
price: 100.27
quantity: 1
bill-to: &id001
street: |
123 Tornado Alley
Suite 16
city: East Centerville
state: KS
ship-to: *id001
delivery: >
Follow the Yellow Brick Road
to the Emerald City. Pay no
attention to the man behind
the curtain.
"firstName": "John”,
"lastName": "Smith",
"age": 25,
"address”:
{
"street": "21 2nd Street",
"city": "New York”,
"state": "NY",
"postalCode": "10021"
},
"phoneNumber":
[
{
"type": "home",
"number": "212 555-1234"
},
{
"type": "fax",
"number": "646 555-4567"
}
]
}
EMTM 600 2011
Val Tannen
XML
<html xmlns="http://www.w3.org/xhtml">
<head>
<title>Sample page</title>
</head>
<body>
<p>A very brief page</p>
</body>
</html>
SOX
html>
xmlns=http://www.w3.org/xhtml
head>
title> Sample page
body>
p> A very brief page
33
The WS Future Vision vs. Today’s Reality
• The standards landscape is still confusing,
and sometimes confused.
JBI (Java Bus. Integr.)
a message-passing
plug-in architecture
based on BPEL
• Hope: WS-I (Web Services Interoperability Organization)
(http://www.ws-i.org) for guidance, best practices and resources
• Today most companies use web services for simple,
tactical integration projects (see next)
• Developers still grappling with SOA design principles
• Human-based discovery working just fine for the moment; local
registries are very useful in EAI (Enterprise Application Integration)
EMTM 600 2011
Val Tannen
34
Using Web services in Enterprise Application Integration
Pros:
•XML is a flexible data exchange format that can deal with complex data
types better than CORBA-IDL.
•Web services separate not only interfaces from implementations (so
does CORBA) but also from the transport protocol. That’s because XML
transport is easily supported by all protocols.
All this motivated Microsoft to put out .NET!
The response of the Java world has been interoperability standards
between the Java technologies and the Web services standards:
•JAXP (Java API for XML Processing
•JAX-WS (Java API for XML Web Services) (formerly JAX-RPC)
•SAAJ (SOAP with Attachments API for Java)
•JAX-RS RESTEasy (available through JBoss/Red Hat)
•Con: XML processing and HTTP transport are SLOW!
EMTM 600 2011
Val Tannen
35
Web Services in the J2EE Architecture
The Java-Web Services specs (JAX-RPC for J2EE and JAX-WS for Java
(5) EE) say that any Java Bean can be adapted to implement a Web
service.
Best practice: do it with session EJB!
Reason: security!
presentation
controller
HTML
Servlets
JSP
Java
Beans
SOAP/
WSDL
EMTM 600 2011
domain
Session
EJBs
data mapping
Entity
EJBs
data source
App.
Serverspecific
bad security
JDBC
Web
Serverspecific
Val Tannen
36
Adapting a Session EJB to become a Web Service
1.
Adapt the session EJB’s remote interface to a JAX-RPC/JAX-WS
compliant SEI (Service Endpoint Interface)
2.
Compile the SEI to a WSDL file (automated with the Apache open source
tool Java2WSDL)
3.
Compile the WSDL file into deployment information (automated with tool:
WSDL2Java) which is vendor-specific; better standardized in JAX-WS.
4.
Make the Web service deployment information compatible with the EJB
deployment information (vendor-specific)
5.
Add a SOAP HTTP request handler (automated with tool: endptEnabler,
appears to be also vendor-specific, but it’s better standardized in JAX-WS)
6.
Deploy the Java EE application; it now includes a Web service
EMTM 600 2011
Val Tannen
37
From the SEI to a WSDL document with Java2WSDL
•
One session EJB -> one SEI (normally)
•
Several SEIs, processed together by Java2WSDL-> one service.
•
Each SEI -> just one port (endpoint) in the service.
•
The name of the SEI becomes the name of the port.
•
The name of the SEI concatenated with “Service” becomes the
name of the service.
•
Each method in the SEI becomes an operation of the unique port.
•
The name of the method becomes the name of the operation.
•
The name of the method concatenated with “Request” and
“Response” become the names of the input and output messages
of the operation.
EMTM 600 2011
Val Tannen
38
Request-Response Operation (*)
public interface StockQuotes extends java.rmi.Remote {
public float getAvgPrice(String symbol, int noDays);
}
Java2WSDL
EMTM 600 2011
<message name="getAvgPriceRequest">
<part name="getAvgPriceArg1" type="xs:string"/>
<part name="getAvgPriceArg2" type="xs:int"/>
</message>
<message name="getAvgPriceResponse">
<part name="getAvgPriceReturn" type="xs:float"/>
</message>
<portType name=”StockQuotes">
<operation name="getAvgPrice">
<input message="getAvgPriceRequest"/>
<output message="getAvgPriceResponse"/>
</operation>
</portType>
Val Tannen
39
More complex architectural ideas
•
The session EJB transformed into a web service that we just saw is
an instance of the Web Service Broker pattern combined with the
Remote Façade pattern.
•
However, we often have multiple application services we want to
organize and expose as coarse-grain web services. Then we use
Web Service Broker (registry) in conjunction with Application
Service and possibly with Service Locator.
EMTM 600 2011
Val Tannen
40
More complex architectural ideas, cont’d
•
The web server can be bypassed: no need for a proxy in the web
server, the web service requests can be sent directly to the EJB
container.
•
In EJB 2.0 they would first have to be adapted to JMS and a
message-driven bean would receive them. The MDB follows the
pattern Service Activator.
•
However, the EJB 3.0 container supports Web services directly.
Just annotate an EJB with @WebService(, its methods with
@WebMethod and their arguments with @WebParam.
•
JAX-WS specifies how to obtain a WSDL file from that, no need for a
separate SEI.
•
In EJB 3.0, the Service Activator components come with the
implementation!
EMTM 600 2011
Val Tannen
41
Best practices for using WS with Java EE
•
A Java EE application can be a WS endpoint server but it can also
be a client to other Web services! If those are also implemented in
Java we can use the same Java <-> WSDL tools in both apps!
•
Do not use Web services between the logical layers of a Java EE
application. Reasons:
•
•
•
•
Serialization/deserialization overhead
XML parsing overhead
No good transaction support (yet)
No good security support (yet, but see OASIS WSS later)
•
In general, avoid fine-grain use of Web services, for the same
reasons. (And note that these reasons are similar to those behind
the Remote Façade pattern!)
•
More generally, defining services with the right granularity is the key
to SOA success.
EMTM 600 2011
Val Tannen
42
More best practices for WS / Java EE
•
Use Web services for widely distributed fat clients; SOAP over
HTTP will work in places where RMI over IIOP won’t, such as
integration with .NET apps.
•
Web services do provide an alternative to using MOM (Message
Oriented Middleware). Implementing asynchronous Web services
follows the same patterns used for MOMs and messaging-based
enterprise application integration (EAI).
•
We can combine Java EE advantages with asynchronous services
using Message-Driven Beans (and therefore JMS). This is
sometimes called SOAP over JMS but it’s really SOAP over
whatever protocol JMS is built on, with JMS as an adapter.
EMTM 600 2011
Val Tannen
43
Web Services and Security
•
SOAP has in essence the same security issues as CORBA, RMI, or MOM.
(DCOM is even less secure because of the COM registry): clear need for
authentication and authorization.
•
But SOAP is so simple that it is used without thinking that:
•
SOAP services are accessible through HTTP on port 80;
•
Firewalls don't block communications on port 80!
•
It’s not enough to use SSL (https instead of http), it doesn’t do
authentication and authorization!
•
In contrast, CORBA, MOM, and Java EE programmers include security as a
basic concern routinely and have tools that simplify their job
•
To secure SOAP and therefore web services, the security must be
implemented by the application, not by the transport protocol.
EMTM 600 2011
Val Tannen
44
Web Services and Security, cont’d
•
Standards for secure SOAP took a long time to be formulated but
now we have:
(WSS) Web Services Security 1.1 a.k.a WS-Security 1.1
from OASIS (http//:www.oasis-open.org)
•
Based on security tokens inserted in the SOAP messages and on
digital signatures.
“Security tokens assert claims and can be used to assert the
binding between authentication secrets or keys and security
identities. An authority can vouch for or endorse the claims in a
security token by using its key to sign or encrypt (it is recommended
to use a keyed encryption) the security token thereby enabling the
authentication of the claims in the token. An X.509 certificate,
claiming the binding between one’s identity and a public key, is an
example of a signed security token endorsed by the certificate
authority. “
EMTM 600 2011
Val Tannen
45
More on Web Services and Security
•
OASIS WSS is a very flexible mechanism; the idea of security token
will be probably adopted in the future by other security
specification, such as the Java Security API.
•
Through the Java Web Services Developers Pack 1.6, we can now
use in Java EE an implementation of OASIS WSS called XWSSecurity which can be used in conjunction with JAX-WS.
•
OASIS WSS 1.1 is now also implemented by .NET
EMTM 600 2011
Val Tannen
46
Claimed benefits of SOA
•
Increased “intrinsic interoperability” and ability to “federate”, i.e.,
positive impact on EAI
•
Increased vendor diversification options
•
Increased organizational agility
•
Increased business and technology domain alignment
•
Increased ROI
•
Reduced IT burden
Biggest risks
•
Inadequate performance
•
Neglect of user needs
EMTM 600 2011
Val Tannen
47