1 / 10

Building Systems from Standards-based Reusable Components

Building Systems from Standards-based Reusable Components. Reusability and Plug-and-Play. Standardized APIs to access services Standardized APIs to manage services Lifecycle, Context, Namespace, Scoping, Discovery Reusable User Interface Components Separate functionality from presentation

kennan-sosa
Download Presentation

Building Systems from Standards-based Reusable Components

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. Building Systems from Standards-based Reusable Components

  2. Reusability and Plug-and-Play • Standardized APIs to access services • Standardized APIs to manage services • Lifecycle, Context, Namespace, Scoping, Discovery • Reusable User Interface Components • Separate functionality from presentation • Support multiple presentation mechanisms • Interact with a presentation framework • Packaging issues – What do you download and “install” – (i.e. like .war files)

  3. Portal Service Component Service Package Tool Package <broker> Blah </broker> <gui> <wml blah…> <html blah...> <swing blah…> <services-req’d blah…> </gui> WML Component User Interface Component HTML Component Swing Component Ultimate Goal State • Standardization for interchange of two types of packaged components – a blob that you download (i.e. a .jar file) • Tool Package • Multiple presentation components • Service Package

  4. UI WML HTML Swing UI WML UI WML HTML Swing Service Service Service HTML Swing Building an “Application” • Select a set of service and tool packages, and “install” them into a framework. • The framework and components are assembled together based on APIs Standardized Framework GUI Broker Service Broker

  5. Application Service Service Service Service Broker UI UI HTML HTML HTML UI GUI Broker UI WML Service HTML Swing Building an “Application” The installation process extracts the needed components from the packages, and assembles them together to form an “application”. In this example, the application is a pure-HTML solution so it ignores, the WML and Swing UI render components. There are two types of APIs: Broker (Lifecycle, Discovery, etc), and application APIs. The Broker APIs are necessary so that the components can associate with one another so as to cooperate over APIs.

  6. Framework Service Service Broker Tool Pres. GUI Broker Where will Standards Come From? Basic GUI Broker APIs are coming from WSRP and from JSR-168. Basic Service Broker APIs will be part of JSR-168. WSIA and/or OGSA may evolve this. WSRP is the most advanced Tool/Presentation API effort – but it still falls short. Service APIs will be standardized separately for each service (i.e. OKI, OGSA, …..)

  7. Standards in this Area • JSR-168 • http://www.jcp.org/ • Web oriented – like servlet • Influenced by IBM WebSphere • Will include some Service lifecycle and broker capabilities • Available “real soon now” for about 1.5 years • WSRP – Web Services For Remote Portals • http://www.oasis-open.org/ • Influenced by IBM • Application is limited to HTML portals • Introduces standardized notion for remote State • Good decomposition pattern – except for too html-centric • Pretty mature – evolutionary not revolutionary

  8. Standards (cont.) • WSIA • Web Services for Interactive Applications • WSXL Web Services Experience Language • http://www.oasis-open.org/ • IBM’s answer to .NET • Very strong service lifecycle, discovery, brokering, etc… • Very generic “network of web services” approach • Will need to harmonize with Open Grid Services Architecture (OGSA) • Several years out

  9. A CHEF Application Jetspeed CHEF OKI Grid Turbine Portlet Portlet Velocity Velocity Velocity Portlet PERL, JSP, ETC Current CHEF Environment CHEF Uses Jetspeed as its tool coordination framework, velocity as its presentation language, Portlet for its tool specification, and Turbine for its service broker. There a wide range of services including OKI, CHEF, and Grid Services. CHEF/Jetspeed also supports “arms-length” integration of tools using an i-frame which are not portlet-based. Ideally, all of these interfaces would not be based on a particular product (Jetspeed, uPortal, WebSphere, etc) but instead would be based on a standard which was supported across products.

  10. Conclusion • The full suite of standards is several years out • Some will need our input • WSRP – Support WSDL (i.e. pre-presentation data) instead of HTML (post-presentation) • JSR-168 and WSIA – Service lifecycle, brokering, discovery • We need to start a collaborative effort to bring order to this problem space • CHEF has the right architecture • As standards evolve, we can quickly test and deploy them • Becoming “Jetspeed agnostic” by abstracting APIs • If we can work together to solve the standards problems, organizations can maintain their existing portals and add support for these standards.

More Related