1 / 49

EzWeb: Put a Face on Services

EzWeb: Put a Face on Services. Marcos Reyes Ureña Telefónica R&D mru@tid.es. 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

hall-lee
Download Presentation

EzWeb: Put a Face on Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EzWeb: Put a Face on Services Marcos Reyes Ureña Telefónica R&D mru@tid.es

  2. 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

  3. 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

  4. Looking for the new Services We 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.

  5. Catching the long tail • The 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…

  6. And also to IT projects…

  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

  8. 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!”

  9. 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!

  10. Use andimpactofthecontribution Usage of Mashup technologies • 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

  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 SERVICE Uses GADGET Instantiate Publish CATALOG MASHUP PLATFORM Instantiate Access Monetize MARKET PLACE DELIVERY PLATFORM

  12. Extending the Mashup Environments GADGET Instantiate Publish CATALOG MASHUP Instantiate Mashup-WebDesktop GADGET ICON ICON CATALOG APPS Publish Wiring Wiring GADGET GADGET Add MASHUPS GADGET float

  13. So… What are we talking bout?EzWeb: Demonstration

  14. Drag-Board Resize Rearrange Configure Exploit Catalogue Discover Buy Share Tag… Wiring Combine FilterAdapt…

  15. EzWeb: Technical Details

  16. EzWeb Architecture Overview • 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 DB

  17. Gadget technological context • Any 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.

  18. 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. • EzWebAPIis 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

  19. API: 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!”

  20. 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 Web Domain A Http Service Request RIA (Domain A) Intra-Domain Call S S S X Web Domain B Http Service Request Cross-Domain Call S S S

  21. Web Domain B Web Domain A S S S S S S 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 EzWeb Server EzWeb App Http Service Request Proxy Intra-Domain Call Http Service Request

  22. 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…

  23. 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

  24. THANKS!! Marcos Reyes Ureña Telefónica R&D mru@tid.es

  25. Mashup platforms: Security • Mashup 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.

  26. EzWeb: Gadget Development in Detail

  27. 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. • EzWebAPIis 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

  28. Gadget Identifier 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.

  29. Template: Description (II) <Catalog.ResourceDescription> <Vendor>Morfeo</Vendor> <Name>MyGadget</Name> <Version>1.0</Version> <Author>fabio</Author> <Mail>fabio@tid.es</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>

  30. Template: 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!”

  31. 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.

  32. Template: Preferences (II) <Platform.Preferences> <Preferencename="textcolor" type="text" description= "Text Color" label="Text Color"/> <Preferencename=”pass" type=”password" description= ”Service password" label="Service password"/> <Preferencename="bg" type="list" description= "Background Color" label="Background Color"> <Optionname="Red" value="red"/> <Optionname="Yellow" value="yellow"/> <Optionname="Green" value="green"/> <Optionname="Blue" value="blue"/> </Preference> </Platform.Preferences>

  33. 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: • name. Name of the variable. • type. Data type of the variable. So far only the type text (string) is allowed. • label. Label which the variable will be shown in the user interface <Platform.StateProperties> <Propertyname="note" type="text" label="Note Text"/> </Platform.StateProperties>

  34. 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: • name. Name of the variable. • type. Data type of the variable. So far only the type text (string) is allowed. • label. Label which the variable will be shown in the user interface • 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: • name. Name of the variable. • type. Data type of the variable. So far only the type text (string) is allowed. • label. Label which the variable will be shown in the user interface • friendcode. similar to event.

  35. Template: Wiring (II) <Platform.Wiring> <Slotname="serviceHired" type="text" label="ServiceHired" friendcode="service"/> <Eventname="deviceId" type="text" label="Device Id" friendcode="device"/> <Eventname="deviceStatus" type="text" label="Device Status" friendcode="status"/> </Platform.Wiring>

  36. 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: • name. Name of the variable. • type. Data type of the variable. So far only the type text (string) is allowed. • 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.

  37. Template: Delivery Context (II) <Platform.Context> <Contextname="user" type="text" concept="username"/> <Contextname="language" type="text" concept="language"/> <Contextname="lock" type="text" concept="lockStatus"/> <Contextname=”orientation" type="text" concept=”orientation"/> <GadgetContextname="height" type="text" concept="height"/> <GadgetContextname="width" type="text" concept="width"/> <GadgetContextname=”xpos" type="text" concept="xPosition"/> <GadgetContextname=”ypos" type="text" concept=“yPosition"/> <GadgetContextname="heightpx" type="text" concept="heightInPixels"/> <GadgetContextname="widthpx" type="text" concept="widthInPixels"/> </Platform.Context>

  38. Template: Gadget Source Code • Platform.Link. Gadget source code related to the template. It is formed by an unique element: • XHTML, in which the hrefattribute defines the gadget source code URL. • Rendering. It defines information about how to show the gadget. It must contain the attributes widthand height. <Platform.Link> <XHTML href="http://ezweb.hi.inet/gadgets/gadgets/myGadget.html"/> </Platform.Link> <Platform.Renderingwidth=“6" height="11"/>

  39. 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

  40. Implementation: Variable Usage • To 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 getand set: var value = variable.get(); variable.set(value);

  41. 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 Web Domain A Http Service Request RIA (Domain A) Intra-Domain Call S S S X Web Domain B Http Service Request Cross-Domain Call S S S

  42. Web Domain B Web Domain A S S S S S S 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 EzWeb Server EzWeb App Http Service Request Proxy Intra-Domain Call Http Service Request

  43. 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.

  44. 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’; • 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.

  45. Cross-Domain Calls: EzWeb API (III) • Send a HTTP request using the PUT method EzWebAPI.send_put(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’; • 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.

  46. Cross-Domain Calls: EzWeb API (IV) • Send a HTTP request using the DELETE method EzWebAPI.send_delete(url, context, successHandler, errorHandler); • url: Target URL, where the request is sent. • 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.

  47. 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: • morfeo-ezweb@lists.morfeo-project.org

  48. Next Generation Service Front-End:Put a Face on SOA Marcos Reyes Ureña Telefónica I+D mru@tid.es

  49. 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/

More Related