A Limited Definition of Web Services Paul Kopacz CIS* Service Oriented Architecture Instructor: Qusay H. Mahmoud, Ph.D. February 15, 2007

A Limited Definition of Web Services - Inspiration “The World Wide Web uses relatively simple technologies with sufficient scalability, efficiency and utility that they have resulted in a remarkable information space of interrelated resources, growing across languages, cultures, and media” - W3C's Architecture of the World Wide Web

A Limited Definition of Web Services - Why? ● Shift towards Service Oriented Architecture ● Extend what works to provide services  Focus on a working model ● Provide a definition which creates services based on Web philosophy

Web ● Must use “Web” properly ● Not just a transport mechanism ● HTTP has well understood interface ● Must work within the interface to be considered Web ● “Web Services based on SOAP and WSDL are Web in name only” - Nick Gall

Resources ● Fundamental property of the Web  Resource endpoints  Expose functionality as URI ● Links are immediately useful  Show what functionality is available  Can organize functionality  Keep a history  Maintain sessions and state

Methods ● Correspond to create-retrieve-update-delete ● GET  Retrieve  Safe and idempotent  Obtain a resource  Invoke functionality with no side effects ● POST  Update  Neither safe nor idempotent  Submit data which causes changes  May return nothing (204 No Content)

Methods ● PUT  Create  Idempotent but not safe  Use when resource requires minimal processing ● DELETE  Destroy  Idempotent but not safe  Specific URL

Headers ● Transfer non-functional requirements ● Specified to be extensible ● Using the body of method calls is inconsistent

Services ● Provide functionality through the Web  No separation between functionality and interface ● Programming against a website worked badly  Screen-scraping  Form inspection  No hints

Services ● Next step in offering services online ● World Wide Web for Programs  Make the Web easy for programs to access ● Extend Web programming to provide interfaces to functionality

The Definition ● An extension of Web programming to expose an application interface through HTTP ● Obey the guidelines of HTTP  Sometimes ignored in Web applications  Providing an API  Strict and consistent

XML? ● Web works with resources of all formats  Use whatever is necessary  Does not specify HTML ● Cannot make it necessary  Probably a good choice

Differences ● Yet another distributed systems technology ● Layering on top of exiting functionality  Like RPC? ● No extra infrastructure required  Stub repositories, registries ● Document transfer instead of function calls ● REST is very applicable  Requiring no state on server unnecessary

Adoption ● Why use it? ● Specific  Technological adoption ● General  Business adoption

Technological Perspective ● Web for Programmers  Programmers want to provide service interface  Make their job easier ● Choice of technology left to engineers  Appealing from their perspective

80/20 Rule ● A technology has a high likelihood of success if 80% of the benefit can be realized with 20% of the implementation work ● Shortest path to exposing existing functionality ● Brand new functionality  Web programming without presentation

Gall's Law ● “A complex system that works is invariably found to have evolved from a simple system that worked” ● Allows simplest first approach  Only add complexity for current iteration ● No need to invent standards until there is a problem to solve

The Browser is Easy ● Making valid Web resources allows use through browser  Scaffolding  Debugging  Inspecting state

Business Perspective ● Increase flexibility and reach of provided services ● Use from other applications  Integrate into systems ● Use from different platforms  Different clients

Business to Customer ● Depends on business model ● Publisher model  Programmatically filter out ads ● Subscription model  The more choice the better ● Balance may need to be struck ● Eliminate lock-in

Business to Business ● Less obvious benefits  B2B communication technologies more mature (EDI)  Budget for integration  Technological roadblocks unlikely ● Complex non-functional requirements  Complex transactions, time limits  Other technologies are more mature (MOMs)

Conclusion ● Use Web technologies in the service oriented model ● Other choices exist but  The Web works  Extending to provide service is easy ● New problems may arise from increased complexity  Rely on what has worked so successfully