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 –Support multiple presentation mechanisms –Interact with a presentation framework Packaging issues – What do you download and “install” – (i.e. like.war files)

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 Service Package Portal Service Component Blah Tool Package User Interface Component WML Component Swing Component HTML Component

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 Service UIWML SwingHTML Service Standardized Framework Service BrokerGUI Broker UIWML SwingHTML UIWML SwingHTML

Building an “Application” Service UIWML SwingHTML 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. Application Service BrokerGUI Broker Service UI HTML

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

Standards in this Area JSR-168 – –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 – –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

Standards (cont.) WSIA –Web Services for Interactive Applications –WSXL Web Services Experience Language – –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

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. A CHEF Application TurbineJetspeed CHEF OKI Grid Portlet Velocity PERL, JSP, ETC 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.

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.