Building Applications from Web Services

© Blue Skyline Ltd1 of 33

Building Applications from Web Services

Andy LongshawBlue Skyline

[email protected]


Some important questions• Who am I?• Who are you?

– Developers, technical architects and technical managers who need to understand the capabilities of Web Services

• Why are you here?– Examine Web Service technologies (WSDL, UDDI,

SOAP, ebXML)– Define the role of each technology– Examine how a Web Service-based application is built– Explore what is missing from the current Web Service

model?


Web Service motivation• What is a Web Service?• Where did they come from?• Why do I care?


What makes a Web Service?• Provides a service at some level

– Examples include: package courier, credit card processing, currency conversion, authentication

• Accessible by other applications over the Web• A description of

– How to use it (e.g. an interface)– Where to find it

• Applications built on Web Services look very similar to "traditional" component-based applications


Why Web Services?• A service goes beyond a component

– Delivers a "service" rather than just functionality (e.g. package courier service)

– It belongs to, and is controlled by, someone else• Similar drivers to component model

– Don't want to create or provide it all yourself…– … but you need a framework to use

3rd party services• Why should you care?

– Potential for faster development andmore integrated applications

– The vendors are pushing you that way!


Web Service building blocks• Web Service roles• Web Service technologies


Web Service roles• What do I need to do?• Service providers

– Have a good idea for a service!– Implement the service being offered– Describe the service being offered– Publish the description– Wait for customers

• Service users– Discover an interesting service– Retrieve the description– Plug it into your application

• Must have a framework for all this to take place under otherwise it is chaos


Describing Web Services• Web Service Description Language (WSDL)

– describes messages, parameters, return values, complex types

– much like IDL but in XML– Also includes binding information: ports, portTypes, etc.

<service name="OrderService">

<port name="OrderServiceSoap" binding="s0:OrderServiceSoap">

<soap:address location="http://localhost/SimpleServices/OrderService.asmx" />

</port>

<port name="OrderServiceHttpGet" binding="s0:OrderServiceHttpGet">

<http:address location="http://localhost/SimpleServices/OrderService.asmx" />

</port>

</service>

<service name="OrderService">

<port name="OrderServiceSoap" binding="s0:OrderServiceSoap">

<soap:address location="http://localhost/SimpleServices/OrderService.asmx" />

</port>

<port name="OrderServiceHttpGet" binding="s0:OrderServiceHttpGet">

<http:address location="http://localhost/SimpleServices/OrderService.asmx" />

</port>

</service> Partial WSDL file


Publishing Web Service metadata• Universal Description, Discovery and

Integration (UDDI)– Publish business information and

technical service description• Different style of searching for information

– Find a specific service (white pages)– Search by service type instead (yellow pages)

• What you get back– Technical service descriptions for

matching services (green pages)– Select appropriate service and transport


Transporting information• SOAP agreed on as underlying transport

– Carries message and parameters as XML– Can do synchronous (HTTP) or asynchronous (mail,

FTP)– Defines XML tags for message structure and header

• SOAP with attachments – what’s the difference?– Ability to carry non-XML payloads– MIME packaging


Language binding• You can program in SOAP directly

– if you really want to…• Language-specific proxies

– Examples include .NET (C#, VB, C++) and Java• Your application should not have to worry too

much, except for usual distributed system concerns– Indeterminate response times– Network-based errors


Web Service Development• Define the interface• Server side

– Create language binding– Implement functionality– Register/create registry information

• Client side– Create language proxy– Call methods/send messages

• Examples: .NET, IBM WSTK


Interoperability• The great promise of Web Services

– Use anybody's service in your application– Platform and language do not matter

• SOAP as the wire protocol– Should give a certain level of interoperability– But not necessarily, e.g. early Apache SOAP and MS

interoperability• XML Protocol is an opportunity to solve

outstanding issues– Being formalized by W3C– SOAP 1.2 in progress


Issues with this model• Security

– Need security but not tightly coupled (e.g. requiring Kerberos) – Point to point security via SSL– End-to-end security not there yet– Pluggable services are (probably) not the answer– XML Dsig and XML Encryption arepart of the answer

• Reliable delivery of messages– Need to define QoS (exactly once, at least once, etc.)

• Context propagation– Need to maintain context: security, transaction, session– Can't re-build this for every call– How do you share context between disparate applications?


Issues with this model (2)• Business process integration

– How do I use this interface?– Roles and sweet spots– Web Service Flow Language (WSFL) on the way

• Common business “objects”– The world does not need another purchase order…


An alternative approach• OASIS and UN/CEFACT joint venture

– http://www.ebxml.org• Creating the framework

– Initial 18 month project to create standards– Use existing technology where possible


Components identified

TechnicalArchitecture

BusinessProcess

Modelling

CoreComponents

RegistryAnd

Repository

Collaboration

Protocol Messaging


How it works Company A

Company B

ebXMLregistry

Request Business Details1

ImplementSystem

2

Register ImplementationDetails and Co. A profile

3

Do businesstransactions

6

Query forCo. A profile

4

Downloadscenarios

and profiles

5Agree businessarrangement

<XML>

Business scenariosBusiness profiles

Business components


ebXML and Web Services• How does ebXML fit with the world of Web Services?

• UDDI can be used to locate appropriate CPP– Will all CPP info really be stored in global UDDI registry?– If not, need a second tier

• SOAP provides some wire-level compatibility– However, you lose security and reliability extensions defined in

ebXML message

• Other parts largely overlap– WSDL and CPP/CPA– UDDI and Registry & Repository


Where does this leave us?• What are the implications of building applications

on shared services?– How we build the applications– How we use the shared services– Owning, maintaining and evolving


Building Web Services• What do we require of the tools and platforms?

– They must "speak the language"– Import/export of service metadata– Packaging and deployment

• Testing is an interesting issue– How do you do testing when using a shared service?– Will other service users really be happy with your load

testing?• Design and development of the service

– What process do we use for development (RUP, XP)?– Granularity of interface design


Using Web Services (1)• Where do you find them?

– Someone you know (vendor, marketplace)– Globally (how far can you trust it?)– Different levels of trust for servers of information rather

than "concrete" goods/services• How do you agree to use the service?

– Which is first• Import metadata and develop application or …• …contact service provider or broker and agree

terms of use– To a degree, it depends on payment


Using Web Services (2)• Payment and licensing must be agreed• Who pays?• How do you pay?

– Subscription– Per-use

• Need common security modelfor authentication– Payment relies on non-repudiation,

especially "per-use"– Passport/Hailstorm questions


Web Services are not RPC• This is plainly not just "RPC across the Web"• Key issues around lookup and use of services

– Runtime lookup of services is not likely for most organizations!

– How do you represent reliability, honesty, quality in Web Service description?

– Stick with existing suppliers orgo via a trusted marketplace


Risk management• Your application now relies on someone else

– Availability– Scalability

• What if someone else's application loads it heavily?– Security– Support– Evolution and versioning

• Potentially a single point of failure that is outside of your control– Although a service broker can add robustness


Why Web Services? - revisited• We have seen the issues, what are the plus

points?– Potentially quicker development– Potentially richer applications– Shared services can be more robust/richer– Enabler for the "short term collaboration" model– Enabler for "smart" Web Services

• Propagation of context, e.g. who, how, where• At the very least it provides an interoperable

component model


The Microsoft Story• .NET Framework• SOAP/WSDL/UDDI• COM-like approach

– get talking first and then sort out security etc.


The Sun Story• Sun ONE Framework – hype or reality?• Strong backer of ebXML• Late started with “popular” Web Services• JAX Pack APIs coming down the line


The IBM Story• A foot in both camps• Progressed a lot of technology through

alphaworks• Ahead of the game with Java offerings


Other vendors and initiatives• Varying levels of support from tool, server and

application vendors– Bolt-on solutions– Native implementations

• Existing initiatives link in at different places– RosettaNet– cXML/xCBL– Data Interchange Standards Organization (DISA)– Business Process Management Initiative (BPMI)


Future directions• Current state of standards

– Many still in formative stages• XML Protocol (XMLP)• Higher-level metadata

– Business process integration– Business objects

• Vendors are building a bridge "across the chasm"


Summary• Web Services extends component model onto the

Internet• "Popular" Web Services model (WSDL, SOAP

and UDDI) has a lot of mindshare• ebXML alternative is more rounded• Building applications on other people's services

has risks as well as benefits• Each major vendor has their own story


Further information• IBM

– http://www-106.ibm.com/developerworks/webservices/– http://www.alphaworks.ibm.com/tech/webservicestoolkit

• Microsoft – http://msdn.microsoft.com/– Web Services section of library

• Apache XML – http://xml.apache.org/soap/index.html

• ebXML home and resources– http://www.ebxml.org

• Web Services Architect– http://www.webservicesarchitect.com/

• Web Services Portal– http://www.webservices.org

Documents

Building Applications from Web Services