Sharing Interactive Applications

Presentation for WSCM MeetingJanuary 7-9, 2002

Eilon ReshefVP Products and Co-FounderWebCollage

- 2 -

Outline Real-Life Case Studies

Business Requirements Web Services and Interactivity

Architecture IWS (Interactive Web Services)

Approach Potential Pitfalls Summary

- 3 -

Case Study 1: Travelers Checks Provider: A Financial Services Company

Selling travelers checks beyond their Web site Increase revenue, support traditional resellers

Sample business partner: http://www.eurovacations.com/travelstore

Key Requirements R1: “Multi-step Applications”

A sophisticated multi-page process R2: “Easy for Container”

No need for partners to re-develop application flow (model or controller)

R3: “Loose Coupling” Ability to add new features (pages, elements) without

partners re-write Real-life Example: Euro Travelers Checks

Container oblivious to provider architecture

- 4 -

Case Study 2: Cosmetics Boutique Provider: A Cosmetics Manufacturer

Creating online boutiques in department stores Replicating the off-line model

Sample business partner:http://www.macys.com/

Key Requirements R4: “Full Control over Look and Feel”

Brand is king

R5: “Integrated Application Flow” Enter and exit with specific data (product id)

- 5 -

Case Study 3: High-Tech Configuration Provider: A High-Tech Manufacturer

Integrating configuration tools with system providers Reducing sales costs across the demand chain

Sample Business Partner:http://www.attcanada.ca

Key Requirements: R6: “Customizable Presentation”

Allow partners to change elements in the look and feel From individual elements to complete sections in the page

R7: “Existing Applications” Web interface is tightly bound to legacy applications Cannot enforce a specific programming model

- 6 -

“Traditional” Web Services

View Controller

Container Application

Model Model

View Controller

Provider Application

ModelAPI (WSDL, SOAP)

- 7 -

“Interactive” Web Services (IWS)

Model Model

View Controller

Provider Application

API (WSDL, SOAP)

View Controller

Model Model

View

View Controller

Model Model

View

Travelers Checks

Cosmetics Boutique

High-Tech Configuration

Model

Controller

- 8 -

Approach Design Criteria

D1: Relate to “Traditional” Component Models Use concepts from ActiveX/COM,

OpenDoc/SOM, … Properties, events, …

D2: Facilitate drag-and-drop programming Web Services should be self-describing

Define required meta-data and semantics

D3: Facilitate coarse-grained interfaces Support distributed applications over a WAN

- 9 -

Structure of Interactive Applications

Page

ControllerAction

- 10 -

Typical Technologies

Page HTML XML WML …

Controller JSP Servlet ASP Perl …

Page

ControllerAction

Action Link Form

- 11 -

Run-Time Model

Container ProviderGetPresentation(…)

Presentation [HTML/WML/XML]

End User

- 12 -

Run-Time Model – Object Model

Interface includes properties and events Defined as part of WSDL using XML Schema

Supports drag-and-drop programming Container sends property values as part of the

invocation Container sends event handlers (WSDL

nuggets) as part of the invocation “Property sheets” may be hosted at

provider

Container ProviderGetPresentation(…)

- 13 -

Run-Time Model – Presentation

Presentation (HTML, WML, XML)

Container Provider

Returned presentation must be embeddable Encapsulated HTML or XML readily convertible

into HTML/WML All actions must be routed to container

HTML defines links and forms as actions Container must handle actions

Out properties are also returned Specifically, the state should be communicated

- 14 -

Run-Time Model – Actions

Actions triggered by the end user are routed to the container Container provides a

“controller” URL as a property value

The process is repeated

Container

End User

Summary

- 16 -

Pitfalls to Watch For P1: Yet another application development model

Must support development using any paradigm P2: Yet another programming language

Must assume application logic may be written in any language

P3: Yet another paradigm shift Must leverage previous work in component models

P4: Yet another security committee Must present a practical, simple and modular

approach P5: Yet another committee standard (;-)

Must rely on related work (single-sign-on, …)

- 17 -

Requirements SheetBusinessRequirementsR1: “Support Multi-

step Applications”

R2: “Easy for Container”

R3: “Loose Coupling”R4: “Full Control over

Look and Feel”R5: “Integrated

Application Flow”R6: “Customizable

Presentation”R7: “Existing

Applications”

Pitfalls to WatchForP1: Yet another

application development model

P2: Yet another programming language

P3: Yet another paradigm shift

P4: Yet another security committee

P5: Yet another committee standard (;-)

DesignCriteria

D1: Relate to “Traditional” Component Models

D2: Facilitate drag-and-drop programming

D3: Facilitate coarse-grained interfaces

Thank You!