MORFEO PROJECT EzWeb: Put a Face on Services Marcos Reyes Ureña Telefónica R&D [email protected].

MO

RF

EO

PR

OJE

CT

EzWeb: Put a Face on Services

Marcos Reyes UreñaTelefónica R&D

[email protected]

MO

RF

EO

PR

OJE

CT

Why are we interested in services front end from the IT Systems world?

The IT systems complexity impacts on time to market and customer and user satisfaction

We have made steps in the right direction (EAI, BPM, SOA…) but the promises of reusability, adaptability, scalability, productivity and loose coupling still aren’t a reality

Maybe because users haven’t been taken into consideration as an integral part of systems architecture. It is necessary to explore a user-centric approach

The next generation service’s front end will allow systems to acquire and exploit user knowledge as a main tool to solve some of the current IT systems problems

MO

RF

EO

PR

OJE

CT

The reality of Services

Today, a real Service Oriented Architecture still being the main goal of most Enterprise Systems (B2B, B2C, B2E).

However most used Services implementations (WSDL/SOAP for example) don't seem to provide the promised solution...

System integration is not as easy as they told us...

Beware with the WS* Stack

In fact we have YARPC (Yet Another RPC)

CORBA, RMI, COM...

But services are more than RPC calls.

They must be something Useful

Final users have been forgotten

Try to give a WSDL to your mother

MO

RF

EO

PR

OJE

CT

Looking for the new ServicesWe need services that:

Involve and empower users

The only way to get their satisfaction

Adapted to real user requirements

... and their needs

Usable, touchable and accessible

Making it empirical and real

Make easy system integration

The best solution involve several Systems

Bring to reality SaaS (beyond ASP solutions)

Really configurable Software as a Service

Interact in a marketplace

Market rules to services evolution

Anyway not all is lost. Real Services already exist!!

At least... in the Internet.

MO

RF

EO

PR

OJE

CT

Catching the long tailThe Long Tail concept appears all along the Web 2.0 universe

It was at first applied to business models:

“Selling less of more”

But it can be applied to:

Acquire less Knowledge from more People

Exploit less Technical Expertise from more Developers

Develop less Requirements in more Systems

Employ less Work from more Workers…

MO

RF

EO

PR

OJE

CT

And also to IT projects…

MO

RF

EO

PR

OJE

CT

7

MaaS: Vision

Involve end-users in the development lifecycle and catch the innovation long tail

Enables crowd-sourcing, Improve user-knowledge sharing and exploitation

Implement SDP service front end features making services tangible for end-users

Highly customizable processes and user interfaces, allowing third parties integration

Increase end-users Efficiency and decrease Time to Market

MO

RF

EO

PR

OJE

CT

What's a Gadget?Gadgets are supposed to be SMALL, REUSABLE and USER-CENTRIC Service front end applications

Welcome to the Post-IT Generation!!

Generic gadgets are desirable but ad-hoc solutions are allowed too... only if they are quick & cheap enough

Sometimes all you need is a Kleenex!!

Gadgets should be adapted to real problems

Gadget Evolution versus Application Creationism

The idea is to Develop USEFUL / Develop FAST

2009 Odyssey: “My God, It's full

of... Gadgets!”

MO

RF

EO

PR

OJE

CT

Gadget’s Mashup: The Service enabler

New mechanisms to discover, use, share and manipulate Gadgets are necessary

Allowing easy and feasible service integration

Making solutions highly accessible and reusable

Empowering users to build their own applications (including situational apps)

Catching the long tail!

MO

RF

EO

PR

OJE

CT

10

Gartner 2009 considers Enterprise Mashups as one of the

10 strategic technologies of 2009

Forrester Research predicts that mashups will be coming

to the enterprise in a big way -- to the tune of a $700 million

market by 2013

Use and impact of the contributionUsage of Mashup technologies

MO

RF

EO

PR

OJE

CT

11

SERVICES

• Entry point to back-end functionality

GADGET

• Small front-end user oriented application able to be managed and integrated by gadget containers.

CATALOG

• Platform able to store, index, locate and dispatch Gadgets.

MASHUP PLATFORM

• Platform able to instantiate, rearrange and wire several gadgets together into a given workspace/mashup.

DELIVERY CONTEXT

• Grant access from every delivery context

MARKETPLACE

• Platform able to define and apply different business models and payment & billing schemas

Putting things in context: MaaS Architechture

GADGET

CATALOG

MASHUPPLATFORM

Publish

Instantiate

Instantiate

SERVICE

Uses

Access

DELIVERY PLATFORM

MARKETPLACE

Monetize

MO

RF

EO

PR

OJE

CT

Mashup-WebDesktop

Extending the Mashup Environments

12

GADGET

GADGET

GADGET

Wiring

Wiring

ICON

ICON

Add

Publish

GADGET

CATALOGMASHUP

Publish

Instantiate

Instantiate

float

CATALOG

APPS

GADGET MASHUPS

MO

RF

EO

PR

OJE

CT

So… What are we talking bout?

EzWeb: Demonstration

MO

RF

EO

PR

OJE

CT

14

Discover Buy Share Tag…

Discover Buy Share Tag…

CatalogueCatalogue

Drag-BoardDrag-Board

WiringWiring

Resize RearrangeConfigure Exploit

Resize RearrangeConfigure Exploit

Combine FilterAdapt…

Combine FilterAdapt…

MO

RF

EO

PR

OJE

CT

EzWeb: Technical Details

MO

RF

EO

PR

OJE

CT

EzWeb Architecture Overview

DB

MVC framework to support Information model: DJANGO/PYTHON

Under-using view and controller

REST / JSON in order to access information model

Simple and efficient

Heavy javascript client over Prototype Ajax Framework

To improve user experience

Portability problems

Write Through + Flying Object

Nice to store/modify state and for localization transparency

Raises some efficiency issues

MO

RF

EO

PR

OJE

CT

Gadget technological contextAny technology can be used to make Back end Services accessible through HTTP

Gadgets are web apps, mostly only view and technology agnostic

But javascript is a must for extended functionalities

Framework Ajax must be compatible with prototype

Template/Manifest metainformation is needed to add the gadget to the platform:

Template allows gadgets to share information with the world in an standard, declarative and semantic way.

MO

RF

EO

PR

OJE

CT

Gadget Development

Gadgets are formed by two different files:

Template, or declarative part (XML). Document that defines the gadget behavior with its environment (user, platform, other gadgets...), allowing the gadget can share information in a standardized, declarative and semantic way.

Implementation (HTML).

It is possible to define several templates for the same gadget implementation, depending on which you want to be its behavior.

EzWebAPI is a JavaScript API used by gadgets. Through this API, gadgets can exploit the functionality provided by the platform, which basically are:

Automatic management of integration variables

HTTP communication avoiding Cross-Domain AJAX Calls

MO

RF

EO

PR

OJE

CT

API: Integration VariablesProperties

They allow free persistence

Preferences

They permit configuration User Forms

Context

The easy way to access the delivery context

Event

Talk to other gadgets

Slots

Receive notifications from other gadgets

.. and so on...

“One concept to rule them all!”

MO

RF

EO

PR

OJE

CT

API: Cross-Domain Calls

The XMLHttpRequest object is at the core of today's AJAX web applications.

All web browsers impose a security restriction on network connections, which includes calls to XMLHttpRequest.

Prevention of a script or application from making a connection to any web server other than the one the web page originally came from.

Web Browser

Http Service Request

Http Service RequestRIA

(Domain A)

Web Domain A

Web Domain B

X

S S SCross-Domain Call

Intra-Domain Call S S S

MO

RF

EO

PR

OJE

CT

API: Cross-Domain Calls

Instead of making XMLHttpRequest calls directly to the web service, you make your calls to EzWeb Server Proxy.

The proxy passes the call onto the web service and in return passes the data back to your gadget.

Web Browser

EzWebApp

EzWeb Server

ProxyHttp Service Request

Intra-Domain Call Http Service Request

Web Domain A

S S S

Web Domain B

S S S

MO

RF

EO

PR

OJE

CT

Things keeping us bussy

Integrate Mashup Platform as one of the basic cloud services MaaS

Extend the webDesktop webOs capabilities

Ease the gadget creation

Advanced WebClipping

Service and Data Mashup

Context driven Dynamic Mashup

Multi device support

Integrate Bussiness models

Usability usability usability…

MO

RF

EO

PR

OJE

CT

Where we are now?

EzWeb is the Selected Mashup platform in the OpenMovilforum / OpenTelefónica initiatives.

As a key enablers to ease open services usage

Working as access point to eAdministration - eGovernment solutions within Zaragoza council

http://www.zaragoza.es/ciudad/servicios/easyzaragoza.htm

Try us!! we are OPEN at :

EzWeb.tid.es

MO

RF

EO

PR

OJE

CT

THANKS!!

Marcos Reyes UreñaTelefónica R&D

[email protected]

MO

RF

EO

PR

OJE

CT

Mashup platforms: SecurityMashup Platforms are inherently NON SECURE applications due to their principal functionality.

They allow and empower the code injection.

Mahups platforms allow to execute code from external sources other than the platform itself.

But don’t panic! It’s easy to offer security and trust in controlled environments

Minimizing the number of gadget providers

Establishing mechanism to audit the gadgets

Deploying specific platforms for closed organizations

Using HTML 5.0 inter iframe Messages

Indeed this is a great opportunity for enterprises able to provide a controlled and secure environment.

MO

RF

EO

PR

OJE

CT

EzWeb: Gadget Development in Detail

MO

RF

EO

PR

OJE

CT

Gadget Development

Gadgets are formed by two different files:

Template, or declarative part (XML). Document that defines the gadget behavior with its environment (user, platform, other gadgets...), allowing the gadget can share information in a standardized, declarative and semantic way.

Implementation (HTML).

It is possible to define several templates for the same gadget implementation, depending on which you want to be its behavior.

EzWebAPI is a JavaScript API used by gadgets. Through this API, gadgets can exploit the functionality provided by the platform, which basically are:

Automatic management of integration variables

HTTP communication avoiding Cross-Domain AJAX Calls

MO

RF

EO

PR

OJE

CT

Template: Description

It contains all the contextual information related to the gadget.

It is composed of the following fields:

Vendor. The distributor of the gadget.

Name. Name of the gadget.

Version. Current version of the gadget.

Author. Person who has developed a gadget.

Mail. E-mail address for contact with the author.

Description. A short description of the gadget.

ImageURI. URL where is the image that will appear later in the catalog.

WikiURI. Entry to a Wiki where to find a complete description of the gadget.

Gadget Identifier

MO

RF

EO

PR

OJE

CT

Template: Description (II)

<Catalog.ResourceDescription>

<Vendor>Morfeo</Vendor>

<Name>MyGadget</Name>

<Version>1.0</Version>

<Author>fabio</Author>

<Mail>[email protected]</Mail>

<Description>This is an example</Description>

<ImageURI>http://ezweb.hi.inet/gadgets/img/mygadget.gif</ImageURI>

<WikiURI>http://ezweb.hi.inet/wiki/mygadget</WikiURI>

</Catalog.ResourceDescription>

MO

RF

EO

PR

OJE

CTTemplate: Integration Variables

Properties

They allow free persistence

Preferences

They permit configuration User Forms

Context

The easy way to access the delivery context

Event

Talk to other gadgets

Slots

Receive notifications from other gadgets

.. and so on...

“One concept to rule them all!”

MO

RF

EO

PR

OJE

CT

Template: Preferences

Platform.Preferences. The user preferences, which may be changed through the platform interface. It may contain any number of these elements:

Preference. It defines a user preference. It must have the following attributes mandatorily:

name. Name of the variable.

type. Data type of the variable: text (string), number, boolean, password and list.

description. Descriptive text.

label. Label which the variable will be shown in the user interface

If preference type is equal to list, it will contain any number of these elements:

Option. It defines an item of the selection list. It must have the following attributes mandatorily:

name. Specifies the text to display in the selection list.value. Specifies the value when the option is selected.

MO

RF

EO

PR

OJE

CT

Template: Preferences (II)

<Platform.Preferences>

<Preference name="textcolor" type="text" description= "Text Color" label="Text Color"/>

<Preference name=”pass" type=”password" description= ”Service password" label="Service password"/>

<Preference name="bg" type="list" description= "Background Color" label="Background Color">

<Option name="Red" value="red"/><Option name="Yellow" value="yellow"/><Option name="Green" value="green"/><Option name="Blue" value="blue"/>

</Preference>

</Platform.Preferences>

MO

RF

EO

PR

OJE

CT

Template: State Properties

Platform.StateProperties. This element contains some variables that reflected the gadget state. The state can be any information that the gadget should make persistent. It may contain any number of these elements:

Property. It defines a state variable. It must have the following attributes mandatorily:


type. Data type of the variable. So far only the type text (string) is allowed.


<Platform.StateProperties> <Property name="note" type="text" label="Note Text"/></Platform.StateProperties>

MO

RF

EO

PR

OJE

CT

Template: Wiring

Platform.Wiring. It defines a list of variables, which the gadget uses to communicate with other gadgets. It may contain any number of these elements:

Event. Events produced by a gadget, which value will be received by other gadgets as slots. It must have the following attributes mandatorily:




friendcode. Label that defines the slots with which the event is related, and which can be connected through a channel. When a user creates a channel, its inputs and outputs are suggested by the platform using this.

Slot. It defines the variable where gadget receives the value of the event which another gadget has produced. Each slot must have the following attributes:




friendcode. similar to event.

MO

RF

EO

PR

OJE

CT

Template: Wiring (II)

<Platform.Wiring><Slot name="serviceHired" type="text" label="ServiceHired"

friendcode="service"/> <Event name="deviceId" type="text" label="Device Id" friendcode="device"/> <Event name="deviceStatus" type="text" label="Device Status" friendcode="status"/></Platform.Wiring>

MO

RF

EO

PR

OJE

CT

Template: Delivery Context

Platform.Context. Element in which variables of context are defined. These variables provide gadgets with a context, which are managed by the platform. It may contain any number of these elements:

Context. It defines a variable of (external) context with platform scope.

GadgetContext. It defines a variable of context with gadget scope.

Both of them must have the following attributes:



concept. Label that provides variable with semantic. Must match with one of the concepts managed by the platform. Currently only are defined as external concepts username and language and as gadget concepts height and width.

MO

RF

EO

PR

OJE

CT

Template: Delivery Context (II)

<Platform.Context>

<Context name="user" type="text" concept="username"/><Context name="language" type="text" concept="language"/><Context name="lock" type="text" concept="lockStatus"/><Context name=”orientation" type="text" concept=”orientation"/>

<GadgetContext name="height" type="text" concept="height"/><GadgetContext name="width" type="text" concept="width"/><GadgetContext name=”xpos" type="text" concept="xPosition"/><GadgetContext name=”ypos" type="text" concept=“yPosition"/><GadgetContext name="heightpx" type="text" concept="heightInPixels"/><GadgetContext name="widthpx" type="text" concept="widthInPixels"/>

</Platform.Context>

MO

RF

EO

PR

OJE

CT

Template: Gadget Source Code

Platform.Link. Gadget source code related to the template. It is formed by an unique element:

XHTML, in which the href attribute defines the gadget source code URL.

Rendering. It defines information about how to show the gadget. It must contain the attributes width and height.

<Platform.Link><XHTML href="http://ezweb.hi.inet/gadgets/gadgets/myGadget.html"/>

</Platform.Link>

<Platform.Rendering width=“6" height="11"/>

MO

RF

EO

PR

OJE

CT

Gadget Development: Implementation

HTML file which defines what makes the gadget, using the elements declared in the template.

It may embed any browser enabled technology (FLASH, APPLET, …)

While the template variables are defined as many aspects, towards implementation there are only two types of variables:

Read Only variables:SLOT

PREFERENCE

CONTEXT

Read-Write variables:EVENT

PROPERTY

MO

RF

EO

PR

OJE

CT

Implementation: Variable UsageTo make use of variables declared in the template, it is necessary to declare previously the variables in code using the EzWebAPI.

Read Only:

var variable = EzWebAPI.createRGadgetVariable(name, handler);

name. Variable name in template file.

handler. Function which will be executed by the platform when the value of the variable has been changed.

Read-Write:

var variable = EzWebAPI.createRWGadgetVariable(name);

name. Variable name in template file.

We can make use of them by its methods get and set:

var value = variable.get();

variable.set(value);

MO

RF

EO

PR

OJE

CT

Cross-Domain Calls

The XMLHttpRequest object is at the core of today's AJAX web applications.

All web browsers impose a security restriction on network connections, which includes calls to XMLHttpRequest.

Prevention of a script or application from making a connection to any web server other than the one the web page originally came from.

Web Browser

Http Service Request

Http Service RequestRIA

(Domain A)

Web Domain A

Web Domain B

X

S S SCross-Domain Call

Intra-Domain Call S S S

MO

RF

EO

PR

OJE

CT

Cross-Domain Calls: EzWeb Solution

Instead of making XMLHttpRequest calls directly to the web service, you make your calls to EzWeb Server Proxy.

The proxy passes the call onto the web service and in return passes the data back to your gadget.

Web Browser

EzWebApp

EzWeb Server

ProxyHttp Service Request

Intra-Domain Call Http Service Request

Web Domain A

S S S

Web Domain B

S S S

MO

RF

EO

PR

OJE

CT

Cross-Domain Calls: EzWeb API (I)

Send a HTTP request using the GET method

EzWebAPI.send_get(url, context, successHandler, errorHandler);

url: Target URL, where the request is sent. When using parameters, they must be encoded along with the URL as follows:

url = ‘http://host:port?param1=value1&...&paramN=valueN’;

context: Due to loss of current context executing JavaScript, it is necessary to provide a pointer to this in such methods in order to call the callback function.

successHandler: Callback function. It will be executed when the request was made successfully.

errorHandler: Callback function. It will be executed during the petition when there has been some error or exception.

MO

RF

EO

PR

OJE

CT

Cross-Domain Calls: EzWeb API (II)

Send a HTTP request using the POST method

EzWebAPI.send_post(url, parameters, context, successHandler, errorHandler);

url: Target URL, where the request is sent.

parameters: HTTP request parameters, they must be encoded as a string in the next way:

parameters = ‘value1&param2=value2& ... &paramN=valueN’;




MO

RF

EO

PR

OJE

CT

Cross-Domain Calls: EzWeb API (III)

Send a HTTP request using the PUT method

EzWebAPI.send_put(url, parameters, context, successHandler, errorHandler);


parameters: HTTP request parameters, they must be encoded as a string in the next way:

parameters = ‘value1&param2=value2& ... &paramN=valueN’;




MO

RF

EO

PR

OJE

CT

Cross-Domain Calls: EzWeb API (IV)

Send a HTTP request using the DELETE method

EzWebAPI.send_delete(url, context, successHandler, errorHandler);





MO

RF

EO

PR

OJE

CT

For more information…

BLOG:

http://ezweb.morfeo-project.com/

WIKI:

http://forge.morfeo-project.org/wiki/index.php/Plataforma_EzWeb

TRAC:

http://trac.morfeo-project.org/trac/ezwebplatform

MAILING LIST:

[email protected]

MO

RF

EO

PR

OJE

CT

Next Generation Service Front-End:Put a Face on SOA

Marcos Reyes UreñaTelefónica I+D

[email protected]

MO

RF

EO

PR

OJE

CT

Morfeo Formación is intended to provide a Free Certified Learning Program in several Open Source Technologies

OSS Introduction

Project Management in OSS

EzWeb

MyMobileWeb...

Morfeo Formación is funded by the Spanish Government inside the PLAN AVANZA

The community behind allows to maintain a stable training network, so Morfeo Formación will last out the AVANZA project

http://www.morfeo-formacion.org/

MORFEO PROJECT EzWeb: Put a Face on Services Marcos Reyes Ureña Telefónica R&D [email protected].

Documents

morfeo project gadgets

morfeo project whats

market slide

real services

demonstration slide

mother slide

reality of services

services evolution