Transcript Successfull companies and Innovators Dilemma

Web Services
Distribution paradigm between hype and
revolution
Walter Kriha
Goals
Web Services were the most overhyped topic in 2001. Then came SOA,
then Cloud Computing. One goal of this session is to discuss the pattern
of “disruptive technology” and see if and how it applies to Web
Services.
Another goal is to discover strength and weaknesses of xml based
distribution technology – and as we do so also learn how such
technology can be evaluated properly. We will meet a lot of false
arguments about distributed systems.
And finally we will use our distributed systems design knowledge from the
last session and try to apply it to applications built with Web Services:
what style of application works best? What fits into the Web Services
paradigm? Does old distributed system knowledge still apply?
Part of our job is to evaluate new technology, e.g. for project use. As with
every new technology its value and application are unclear – and even old
computing hands can be wrong. So don´t hesitate to voice your opinion!
Overview
•
•
•
•
•
•
•
•
•
The concept of disruptive technology
What are Web Services?
SOAP and the performance discussion
A way to describe messages: Web Services Description Language
How to find Web Services: Universal Discovery and Description
Interface
Web Services and the “ilities”: Reliability, Security, Transactions etc.
Web Service applications
Trends and possibilities
Discusion: Are Web Services disruptive? Is it a Peer-to-peer
technology?
Successfull companies and Innovators Dilemma
• Listen to customers
• Invest aggressively in technologies that give those customers what they
say they want
• Seek higher margins (e.g go after the most wealthy customers with the
hardest problems)
• Target larger markets
(from Christensen, page 263ff.)
This behavior of successfull companies is well known. On their way to
success these companies restructure themselves to better achieve the goals
from above: they invest only in the high margin area, they develop an
internal cost structure that matches the high-margin market they are after.
Clayton Christensen shows that it is exactly this behavior that makes
successfull companies miss disruptive technology
Disk Drive Product Features and Competition
capacity
reliability
speed
price
time axis of product evolution
Most product display a similiar evolution: from technical possibility over
improvements (convenience) and feature overload (think about hi-fi
products!) to battling over price only. This is the reason why most companies
try to go „upmarket“ where higher prices are paid for more complex
products.
Commoditization of IT?
First, regardless of whatever definition you use to describe cloud computing (a fairly
hopeless task in my view), the term merely identifies an underlying shift of I.T.
from a product to a service based economy. It's a consequence of :
- Certain I.T. activities becoming suitable for service provision through volume
operations (i.e. those activities are well defined and ubiquitous
The existence of mature enough technology to support this (Popek et al wrote the
book on virtualisation back in 1974)
-A change in business attitude towards I.T. (Carr and others, namely Strassmann,
pointed out that much of I.T. is simply seen as a cost of doing business.)
- The concept of utility computing provision (i.e. the provision of suitable I.T.
resources much like other utility providers, as forecast by McCarthy back in the
1960's.)
Take away any of these elements and cloud computing wouldn't represent the
upheaval and the disruption that it does today. From: Simon Wendley‘s blog
http://blog.gardeviance.org/
Disruptive Technology (1)
• Is simpler and cheaper and lower performing
• Promises lower margins, not higher profits
• Leading firms most profitable customers generally can´t use and don´t
want them
• are first commercialized in emerging or insignificant markets
(from Christensen, page 267)
It is hard to find a market or application for something that is a looser in all
known applications or markets. Our Peer-to-peer group noticed how hard it
is to find usefull applications for a disruptive technology. Imagine you are a
developer who wants to convince a well established manager of a
successfull company to invest into a disruptive technology and you have to
acknowledge the things from above! Imagine you are an employee of a
database company and you´ve invented the www. Do you think your
manager would be excited about some „network database“ where you can´t
find things deterministically? And the reliability issues etc....
Disruptive Technology (2)
• needs new markets to shine
• needs new people and organization: it won´t grow in old
structures
• Starts weak but has potential
• It does most things worse than established technology but
it can do SOME things those can´t or do badly.
This characterization is surprisingly close to how Thomas Kuhn explained
progress in science („The structure of scientific revolutions“). He clearly
showed that old theories literally die out with their teachers and that there is a
large piece of believe both in old and new theories.
What are Web Services?
„A Web service is a software component that represents a
business function (or a business service) and can be
accessed by another application (a client, a server or
another Web service) over public networks using
generally available ubiquitous protocols and transports
(i.e. SOAP over http)“. (http://www3.gartner.com/Init by
M.Pezzini, April 2001)
The core definition usually comprises:
-simple requests
-public networks/Internet
-http transport
-XML message format
-business function
WWW: from GUI driven to B2B
<FORM action="http://stockservice.com/getquote" method="post">
<P><LABEL for=valor">valor: </LABEL>
<INPUT type="text" id=„valor"><BR>
<INPUT type="submit" value="Send"> </FORM>
stockservice: valor=IBM
html document with IBM=44.56
stock
server
<xmlrpc><service>stockservice</service><request>getquote><parameter><name>
valor</name><value>IBM</value></parameter></request></xml-rpc>
myYahoo
<xmlrpc><service>stockservice</service><response>getquote><parameter><name
>IBM</name><value>44.56</value></parameter></response></xml-rpc>
The concept of a web service is extremely simple: use XML to create requests and
responses and send them using http. This allows machines to communicate with each
others, e.g. to perform supply chain management or other business to business processing.
XML-RPC by David Winer (userland.com) was one of the earliest standard proposals.
Companies have used this technology internally for quite a while.
Web Services Components
single sign on services:
Hailstorm/liberty
alliance
Digital Signatures
Transactions
global registry
Metering
Universal Description, Discovery, Integration UDDI (XML)
Web Service Description Language WSDL (XML)
Request format: SOAP (XML)
Transport layer: http(s), smtp, httpr
XML is the standard format used in Web Services. On top of standard transport
mechanisms are requests formatted using the SOAP XML schema. Clients learn
about service providers by browsing the UDDI registry. Services are described in a
special description language, again a XML schema.
The Web Services Architecture
UDDI
registry
look for service in
UDDI registry
requester
retrieve provider
location and WSDL
service description
bind and send request via
SOAP/http or other
transport to provider
publish services in
registry
provider
create request from
WSDL description
This type of architecture is called „service-oriented“. It uses a broker for
service advertisement and lookup. Requester and provider bind dynamically
with respect to transport (http, smtp etc.) (Raghavan N. Srinivas, Web services
hits the Java scene part 1, http://www.javaworld.com)
Request Transport in Web Services
Currently http or https are mostly used for Web
Services. But asynchronous messaging is also
supported e.g. through SMTP.
Both transports have deficits with respect to
reliability. IBM has introduced a proposal for
HTTPR, a reliable asynchronous message
protocol.
more information on HTTPR: ibm developerworks: Web Services: A
primer for HTTPR. It has some excellent diagrams on the relation
between transactional safety and resource allocation in asynchronous
protocols. Shows why asynchronous protocols potentially scale
better.
Request Format of Web Services: SOAP
hello-request
hello-response
<s:Envelope
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
xmlns:s="http://www.w3.org/2001/06/soap-envelope"
xmlns:xsi="http://www.w3.org/1999/XMLSchemainstance"xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<s:Body>
<m:sayHello xmlns:m='urn:Example1'>
<name xsi:type='xsd:string'>James</name>
</m:sayHello>
</s:Body>
</s:Envelope>
<s:Body>
<n:sayHelloResponse xmlns:n="urn:Example1">
<return xsi:type="xsd:string">
Hello James
</return>
</n:sayHelloResponse>
</s:Body>
</s:Envelope>
SOAP is essentially an RPC protocol with XML. It provides elements for type
marshalling and RPC semantics. A header element contains meta-information but
is optional. See Snell et.al. Programming Web Services... for details. Find a
complete SOAP implementation at apache.org
SOAP: performance aspects (1)
Object to XML
conversion
transport of XML
stream over http
XML stream
XML Parsing and
construction of objects
XML stream
The use of a non-binary transport format has created heated discussions about
performance issues. Bad coding techniques (too many objects created), XML
misunderstandings (e.g. to use validating parser without need) and wrong parsers
(e.g DOM instead of SAX) have created a lot of confusion. Lately it looks like
XML encoded messages can come close to the performance of binary formats
like IIOP.
SOAP: performance aspects (2)
marshaling
time
Internet
transport
time
Object to XML
conversion
transport of XML
stream over http
XML stream
effect of
size on
transport
demarshaling
time
XML Parsing and
construction of objects
XML stream
The only way to find an answer on possible performance problems is to measure the
effect of individual processing steps or transport times on the overall request time. It
became clear that the internet transport time with lacking QOS has far greater effects on
overall request time than the size and interpretation effort of a textual format. In other
words: it is NOT the XML that is problematic, it is the public network (Internet) that takes
a toll on request/response protocols. (watch Amdahls law in action)
loose coupling with XML
• all Web-services API´s are expressed in XML and therefore
completely programming language independent
• XML messages are self-describing and can be validated on
the receiver side if a schema is used.
•XML messages can be read by humans and machines.
•No pre-compiles stubs and skeletons are required
These properties of XML, together with the use of http as transport have given
web services the touch of simplicity. But beware: Changes in XML schemas WILL
surprise receivers, the question of semantics is still open (see UDDI later)!
Web Services and Firewalls
CORBA
port
SOAP request
SOAP request
Web Service
Application
Server
http
port
SOAP request
RMI
port
Firewall
Web server
Object
server
The firewall „friendliness“ of Web Services has been touted all along. But
firewalls were introduced for a reason: to block protocolls that cannot be tracked
and filtered properly – perhaps because the necessary infrastructure was never
developed – perhaps because the protocols were not intended for the Internet like
CORBA and RMI. But Web Services make no sense without such an
infrastructure.
WSDL
Web Services Description Language (WSDL) is the metadata language of Web
Services. It defines how service providers and requesters understand Web
Services.
When exposing back-ends as Web Services, WSDL defines and exposes
components and lists all the data types, operations, and parameters used by that
service.
WSDL provides all the information that a client application needs to build a
valid SOAP invocation that in turn is mapped by the Web Services platform
onto back-end enterprise logic. (after P.J.Murray, Web Services and CORBA,
CapeClear)
WSDL: The IDL of Web Services
<?xml version="1.0"?> <definitions name="StockQuote"
<schena targetNamespace=http://example.com/stockquote.wsdl [...]
<types><schema targetNamespace="http://example.com/stockquote.xsd" [...]
<element name="TradePriceRequest">
<complexType> <all> <element name="tickerSymbol" type="string"/> </all> </complexType>
</element></schema> </types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/></message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/> </operation> </portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
[..] <operation name="GetLastTradePrice"> [..] </binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/> </port> </service> </definitions>
WSDL Elements
•Types– a container for data type definitions using some type system (such as
XSD).
•Message– an abstract, typed definition of the data being communicated.
•Operation– an abstract description of an action supported by the service.
•Port Type–an abstract set of operations supported by one or more endpoints.
•Binding– a concrete protocol and data format specification for a particular
port type.
•Port– a single endpoint defined as a combination of a binding and a network
address.
•Service– a collection of related endpoints.
A WSDL document defines services as collections of network endpoints, or ports. In
WSDL, the abstract definition of endpoints and messages is separated from their
concrete network deployment or data format bindings. This allows the reuse of abstract
definitions: messages, which are abstract descriptions of the data being exchanged, and
port types which are abstract collections of operations. The concrete protocol and data
format specifications for a particular port type constitutes a reusable binding.
Dynamic Binding in WSDL
Service
Port A
Port B
Binding A
Binding B
Operation
Operation
Message
Message
Operation
Message
WSDL allows the specification of a service with operations on a logical level.
The physical binding to host, transport etc. happens in a binding declaration.
Clients negotiate the binding to be used with a provider.
Service Discovery (1): UDDI
UDDI registry with find and publish API
White pages:
Yellow pages:
Green pages:
information
about
companies (loc.,
contact etc.)
business
categorization,
type and
industry
meta
information
about services
and their
qualities
most distributed services use some kind of central registry for service lookup.
The Universal Description, Discovery and Integration registry plays this role in
web services. Especially the green pages property has led some people to
proclaim automatic service matching by service requesters browsing the metainformation contained there. For the difficulties behind ontologies and automated
discovery see: Steve Vinoski, Web Services and Dynamic Discovery on
webservices.org
Service Discovery (2): UDDI content
<businessEntity>name,
contact, location etc.
<tModel>meta
<businessService>
info on service
specification of
a service
<bindingTemplate>
All content in UDDI is expressed in XML. Besides the obvious elements for
companies and services a number of meta-information elements like tModel exist.
A core feature of UDDI is the expectation that requester and provider do a
dynamic bind where they agree on service and transport characteristics. A local
registry can be downloaded from www.alphaworks.ibm.com
UDDI Organizational Alternatives
provider/
index
UDDI index
provider/
index
provider
provider/
provider/ index
index
provider
provider
provider
Several indexes are
created
UDDI index
create request from
WSDL description
UDDI
UDDI
registry registry
federation is
possible
between
registries
provider
provider
provider
provider
providers
register services
in central
registry
Different levels of economic control and threats are behind each model.
Technically each of them is possible.
Common Business Processes: ebXML
implement purchase process
according to specification
ebXML registry
retrieve specification
Standard Purchase
Business Process
Specification:
company A
register own purchase service
•Operations
use company A‘s purchase
service
•Parameters
•Flow
find service from company A
company B
Without standard schemas for services every company will implement their
business processes differently. Clients will have to deal with many different
interfaces for the same type of service. ebXML is a global electronic business
standard and defines a framework for defining, finding and using standard
business process services. see www.oasis-open.org
Transactional Web Applications
Lock seat #5
The travel agency needs to reserve a flight, book a car and a
hotel room for a traveller.
Flights
lock car #24
Travel
Agency
Rental
cars
lock room #47
hotel
reservation
The 2-phase commit protocol does distributed transactions. But it does not really fit to the
web world because it requires resource managers to lock resources. On the un-reliable
medium internet this should be avoided. SOAP does not yet specify a transactional
service. OASIS is working on „Business Transaction Processing“ to support Web Services
Transactions. IBM is proposing a model using „tentative“ reservation to overcome the
locking problem.
Web Services Application Types
<xmlrpc><service>stockservice</service><response>getquote><parameter
><name>IBM</name><value>44.56</value></parameter></response
></xml-rpc>
Information
Aggregation
stock
server
myYahoo
<xmlrpc><service>roomreservation</service><response>reserve
Room><parameter><name>Kriha</name><value>4711</val
ue></parameter></response></xml-rpc>
Business
Transaction
hotel
reservation
The web has always been an information space as well as a transaction space. Web
services allow both kinds of exchanges: more document centric information aggregation
and more transaction oriented service requests.
Web Services Example Applications
•
•
•
•
The ubiquitous „Stock Quote Example“
A zip code lookup service from US Postal
Weather reports lookup etc.
Single-sign-on services: passport (hailstorm), liberty alliance
Up to now most web services applications are technical
showcases and cover only very simple types of requests. This
may be because things like security and transactions have not
been solved yet. Right now SSL is used to secure message
transport. But work is on the way to include digital signatures
in SOAP messages.
Trends and Future developments
Internet
web services gateway
(„firewall“?)
Intranet
Interceptors
A hosting service provides metering for providers (accounting, authorization etc.)
requester
web
service
provider
web
service
Hosting
Service
The implementation of common services through web services will be an
interesting case. Will performance and reliability suffer? What are the business
models behind such a technology? Security and privacy issues?
Reliable Messaging
Application
layer
Application
layer
persistent
messages
persistent
messages
SOAP msg. with message ID,
sequence number and QOS tag
requester
receiver
message
ordering
request and ack.
MUST send
ack!!!
Reliable B2B messages need guaranteed delivery (ack enforced), duplicate
removal (message ID) and message ordering (sequence numbers). SOAP and http
do NOT provide those qualities. Further QOS extensions could be: time to hold
messages, number of retries etc. Proxies are considered transparent.
Secure Messages
SOAP envelope
Application
layer
Digital Signatures:
XMLDsig
signed
encrypted
Application
layer
Digital Encryption:
XMLEnc
WS-Security goes from channel based security to message (object) based security.
Individual messages can be signed and encrypted. WSDL can advertise the QOS
expected/provided by a receiver. End-to-end security is possible across
intermediates. See my internet security lecture for details on WS-Security,
security policies and expressions (SAML, WS-Policy), WS-SecureConversation
and WS-Trust. The idea of the „Virtual Organization“ – overlay structures over
existing real organizations is one of the driving factors here.
Coordination and Transactions
• A generic coordination service providing coordination
tpyes, context and protocol (e.g. atomic transactions,
business activities
• A transaction service which covers traditional TA‘s and
conversational Business Activities.
Loosely coupled services which last a long time cannot use regular locking or do
a complete rollback if something fails. Business Activities comprise several lowleval atomic TA‘s but make progress even in case of individual task failures.
Transaction Models
Transaction
Atomic
Activity
• not nested
• nested tasks
• short
• long running
• tightly coupled business task
• loosely coupled business activity
• rollback in case of error
• compensating tasks and activities
• errors: system crash
• errors: order cancellation etc.
Complete rollback is too expensive for long running business activities.
Intermediate results must be visible early – compensating acting try to undo tasks
in case of business errors.
A Coordinator
forward Context
Transaction
Starter
Context
Participant
Context
Context
register indirectly
register with Coordinator
create Context
Activation
Registration
Coordinator
Activation
Context
Registration
Coordinator
(subordinate)
Activation works like a factory method to create a new Coordination Context.
This context is forwarded to participants which register through it either directly
with the first coordinator or with their own coordinator which registers itself as a
sub-coordinator. Protocol and type of coordination are contained in context.
Phase Zero Protocol
Coordinator
Participant
Resource Manager
register for phase 0
phase 0
holds cached data
write cached date
phase 0 OK
prepare (begin two phase commit
To allow for caching by intermediates ws-transaction defines an additional phase
called phase zero BEFORE the usual two phase commit protocol starts. Reason is
that most resource managers cannot handle change requests after 2pc has started.
This „feature“ is not undisputed – see Roger Sessions objectwatch newsletter on
this topic.
Stateful Web Services
endpoint reference
including resource
property identificator
requestor
wsdl + resource
property description
get/set operations,
notification registration,
lifecycle (create/destroy)
endpoint with
get/set methods
Stateful architectures like computational grids need the concept of a resource.
WS-Resource adds this via meta-data descriptions contained in the WSDL and
WS-Adressing schemas. An identifier is used to communicate state information
between requestors and endpoints. On top of WS-Resource advanced notification
requests can be built. See: The WS-Resource Framework (Czaikowski, Ferguson
et.al.)
Virtual Organizations
VO‘s need to be created ad-hoc using a common technology for communication
and security. The best know grid project globus (www.gobus.org) now switched
to a web services approach for interoperability reasons. (diagram taken from
„Security for Grids“ (Von Welch et. al.)
GUI re-use: Web Services for Remote Portals
WSRP Consumer
WSRP Producer
WSRP Service
Portal
WSRP Service
WSRP Service
Aggregated
HTML, WML, VoiceXML,
... over HTTP
Mark-Up Fragments
Transferred via SOAP
• Portals can aggregate presentation from many WSRP services
• WSRP services can be aware of portal context
– User profile from portal
– Desired locale and markup-type
– User‘s device type
from: OASIS WSRP Technical Committee, April 2002 (see resources)
Interesting Projects
• Use Web Services to provide a common service layer for logging,
auditing, user profiles in a multi-language intranet.
• Use Web Services Component Model to create components for
integration in portals. See oasis-open for proposals from Epicentric,
IBM („Web Services Experience Language“)
• Computational Grids are now using Web Services to express
communications, security and resources (see www.globus.org )
• Create automated workflows for B2B. BPEL4WS and other standards
try to automate business processes using Web Services. This goes
along with better semantics through Web Ontology Language, RDF
etc.
Yes, both projects might be used in intranets first. But companies face the
same integration problems internally as the experience in the B2B area.
Best Practice for Promoting Scalable Web Services
1. Stay away from using XML messaging to do fine-grained RPC. For example, stay away from a service which returns the
square root of a number. Stay away from a service that returns a stock quote (this is the classic-cited example of a
Web service).
2. Conversely, use course-grained RPC. XML web services usually have to be defined at a coarser granularity than
ordinary software objects. That is, use Web services that "do a lot of work, and return a lot of information".
3. When the transport may be slow and/or unreliable, or the processing is complex and/or long-running, consider an
asynchronous messaging model.
4. Always take the overall system performance into account. Don't optimize until you know where the bottlenecks are, i.e.,
don't assume that XML's "bloat" or HTTP's limitations are a problem until they are demonstrated in your application.
5. Take the frequency of the messaging into account. A high rate of requests might suggest that you load (replicate) some
of the data and processing back to the client. The client occassionally connects to synch-up with the server, and get
the lastest data.
6. Aggregation using replication. There will be Web services which serve to aggregate data from other Web services. One
approach is to perform the aggregation on demand - the services which supply the data are invoked in real time, the
data is aggregated, and returned to a requesting client. Alternatively, all the data from the supplier services may be
retrieved during off-hours in one large, course-grained transaction. Thus, the aggregation is performed in real-time
(rather than trying to retrieve the supplier data in real-time). The later is recommended whereever possible.
this is the result of an interesting discussion at xml-dev. Do you agree?
Other Web Services Architectural Models
Representational State Transfer Architecture (REST), SOA and Policies are
models beyond mere messaging. Diagram taken from „Web Services
Architecture (w3c)
RESTful Web – against the RPC Model
-The WEB is based on representation of resources
using URIs, Web Services create private, non-standard
ways of information access
-The envelope paradigm does not add any value over
the generic http get/put/post
-RPC mechanisms are not suitable for the WEB. Some
extensions to get/put/post might be necessary though
(going in the direction of tuple-space systems)
This is a hot topic currently: ask yourself whenever you think about building a web
services: could it be done with just an http get or post? REST btw. stands for
Representational State Transer Architecture, a term coined by Roy Fielding, the father
of http. see resources on REST. But in later versions Web Services have been extended
through a document centric model as well.
RESTful Web: CRUD like Message Semantics
Representation
Requestor
Resource
GET -> Read (idempotent, does not change server state)
POST –> Create resource on the server
PUT -> Update Resorce on the server
DELETE -> Delete Resource on server
Is this separation of updates and reads something new? Not by far. Bertrand Meyer of OO fame
calls this a core principle of sound software design and made it a requirement for his Eiffel
programming language. He calls it “”command-query separation principle”:
“Commands do not return a result; queries may not change the state – in other words they satisfy
referential transparency” B. Meyer, Software Architecture: Object Oriented Versus Functional
[Meyer]
RESTful Web Features
Four strands that make a servive RESTful:
• explicit use of http protocol in a CRUD like manner
• stateless design between client and server
• meaningful URIs which represent objects and their
relationships in the form of directory entries (mostly
parent/child or general/specific entity relations)
• use of XML or JSON as a transfer format and use of
content negotiation with mime types
All state change is reflected by a change in representation. Resources are manipulated
through a very simple and uniform interface (CRUD like) and through the exchange of
representations. This is how the WWW works. A subset of Web Services are RESTcompliant. From A.Rodriguez, see resources.
Policies – Making Services More Intelligent
- Intermediates acting as trust-centers, proxies etc.
What does a service allow?
- Advanced collaboration between businesses. What
does a business require?
- Virtual organizations on top of physical organizations.
What are the rules for participation?
Complex business relations, frequently ad-hoc and fast established, need ways to
express the constraints for each partner, transaction etc. This covers security policies
just like reliability and availability expectations which are generally subsumed under
the „QOS“ term.
For advanced services architecture and
security technology for ad-hoc end-to-end
services see the lectures on SOA and Web
Services Security
Resources (1)
• Clayton M. Christensen, The Innovators Dilemma. Shows how
disruptive technology can turn successfull companies into loosers.
Explaines why companies find it so hard to embrace new technology.
This book has been so successfull that nowadays every discussion of
new and badly understood technology uses the term „disruptive“.
• www.webservices.org The Web Services Portal. It covers most Vendor
products and has good overview articles.
• xml-dev: mailing list for XML developers. High traffic site. Had a
good discussion on XML-RPC performance lately
• Security for Web services, Raghavan Srinivas,
http://www.sun.com/developers/evangcentral/totallytech/Warsaw/Secu
rityWarsaw.pdf
Resources (2)
•
•
•
•
•
Programming Web Services with SOAP, J.Snell et.al.,
O´Reilly 2002.
www.oasis-open.org , Portal for ebXML and other XML
schema definitions. Work on business transactions over
web-services.
Global XML Web Services Architecture, Microsoft paper
October 2001, www.gotdotnet.com (.net portal for web
services)
Michael Stal, Web Services im Überblick, Objectspectrum
7/8 2001
www.uddi.org, portal for UDDI.
Resources (3)
•
•
•
•
•
The IBM UDDI registry:
http://www.ibm.com/services/uddi
Microsoft's UDDI registry: http://uddi.microsoft.com
Andre Tost, UDDI4J lets Java do the walking. Good
introduction to the concepts behind UDDI
Steve Vinoski, Web Services and Dynamic Discovery,
Article on webservices.org about the real difficulties with
ontologies and automatic understanding. Yes, Steve is one
of the fathers of CORBA and IONA´s chief architect.
P.J.Murray, Web Services and CORBA, CapeClear. Good
explanation of the mapping problems when exposing
CORBA services via Web Services.
Resources (4)
•
•
•
•
•
Dave Winer et.al., A busy developers guide to SOAP1.1, from
www.soapware.org, bare bone explanation of the most important features.
Does not cover SOAP with attachements etc.
Web Services for Remote Portals (WSRP), http://www.oasisopen.org/committees/wsrp/ , a new approach to re-use services WITH
their GUI. Headed by Thomas Schaeck, IBM Böblingen
the RESTwiki on http://conveyor.com/RESTwiki/moin.cgi
Principled Design of a modern Web Architecture, R. Fielding,
http://www.cs.virginia.edu/~cs650/assignments/papers/p407-fielding.pdf
Alex Rodriguez , RESTful Web services: The basics, IBM , 06 Nov 2008
http://www.ibm.com/developerworks/webservices/library/wsrestful/index.html?S_TACT=105AGX54&S_CMP=B1113&ca=dnw-945
Resources (5)
•
•
•
•
•
James McCarthy, Reap the benefits of document style Web services
http://www-106.ibm.com/developerworks/library/ws-docstyle.html?n-ws-6202
. A nice explanation of document style web services and when to use them.
E.g. if there is NO pre-existing rpc-service you might be better of designing
your communication in document style right away. Better for asynchronous
processing as well. And coarse grained which is better in many cases of distsys as we have learned.
The WS-Resource Framework V1.0, Czaikowski, Ferguson et.al. describes the
addition of statful resources to web services by using meta-data and identifiers.
Read the grid papers to understand the need for it.
Security for Grid Services, Von Welch et.al. Describes the security needs of
virtual organizations.
Martin Brown, Building a grid using Web Services standards Part1-6.
www.ibm.com/developerworks Shows a distributed movie serving application
built with web services. Looks a bit like napsters design. Shows how similar
p2p and grid applications really are.
REST in Rails: http://www.b-simple.de/documents