 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Press & Success
Success Stories
JSR 168 Portlet Specification: Opening the Door to Enterprise Productivity and Cost Containment
Joey Santini doesn't know diddly about the inner workings of a portal. But he does know that when he sweet talks his customers into buying a car, it sure helps that the internal home page of the nationally recognized car manufacturer whose dealership he works for has organized the tools he needs to drive the sale home. From this portal, he can read headlines related to transportation and salesmanship, print a 4-Square worksheet, consult reference indices such as Kelley Blue Book, open a calculator, customize a form letter, send and receive email, check current inventory, negotiate with the loan group via instant messaging, and check the company's current stock price. Some utilities were created just for this enterprise, while others were gleaned from different servers on the enterprise intranet as well as various places web sites. No one has told Joey yet, but his company is making plans to buy the local competitor. Each dealership has invested substantial resources to make its portal an environment that maximizes the efficiency of its employees. Here's the hitch: Dealership A built its portal on IBM's WebSphere Portal, while Dealership B used Plumtree's Enterprise Web Suite. Whose portal will be discarded after a merger? It would have been cost prohibitive to reimplement all the portlets on one portal to run on the other. However, Java Specification Request (JSR) 168, developed through the Java Community Process (JCP) program, allows Dealerships A and B to select the best components of each of their portals to deploy on whichever portal they deem most suitable at a trivial net cost. Sun and IBM Co-Lead Specification Design
Enterprises such as Boeing and DaimlerChrysler increasingly depend on the elegant power of portals to help their users access a plethora of tools and information efficiently, without needing to know where the content came from. "Portal servers have become really popular over the past three or so years, and the market for portal servers has continued to grow even through the economic downturn of the past couple of years. It's one of the areas in which the year-over-year growth is still pretty substantial compared to other marketplaces," says Adam Abramski, product line manager for the Portal Server group at Sun Microsystems and co-submitter of JSR 168. To address the appeals of customers, Sun Microsystems and IBM each submitted a JSR to the Java Community Process (JCP) program, independently, near-simultaneously, and without knowledge of each other, proposing a standard API and spec around the portal platform. When Onno Kluyt, director of the JCP Program Management Office (PMO), suggested a collaboration, Sun and IBM withdrew their original requests and decided to submit JSR 168 jointly instead. Their decision to co-lead the expert group was made with the understanding that Sun would write the specification and the Technology Compatibility Kit (TCK), and IBM would be responsible for the Reference Implementation (RI). JSR 168 Portlet Specification defines a set of Java APIs to enable interoperability between portals and portlets. A portlet is a web component that runs within a portal providing a user interface that enables the exposure of content and application functionality through a portal. And a portal is a web page that aggregates and organizes content in the form of applications (search engine, productivity software, games), enterprise services (calendar, email, customer relationship management), content management, and information (news, movie guide, weather, stock ticker) arranged to satisfy many of the user's needs. Sometimes the user can customize aspects of the format and structure. Popular consumer portal examples include the home pages of Yahoo!, CNN, and AOL and vertical sites such as c|net's comparison shopper.com and the travel-oriented priceline.com. Enterprises deploy portals as personalized and customizable business applicatons for their constituents, such as employees, customers, suppliers and partners. Before JSR 168 became final in October 2003, portlets had to be written specifically to suit a given portal platform, such as those sold by Sun, IBM, BEA Systems, Oracle, and Plumtree Software. Each portal vendor supplied the APIs for how content becomes aggregated and personalized through their particular portal. As the portal server marketplace matured, independent software vendors (ISVs) and developers who wanted to integrate their applications with portals faced a challenge that grew worse over time. Abramski says, "Developers of portal content had to be cognizant of and write to the specific APIs of each portal server's platform, and that became a maintenance support nightmare for an enterprise organization." Corporate enterprise developers pressured portal vendors to make it easier for them to support and maintain their portlets. With JSR 168, developers can build a single portlet and install it on any JSR 168-compliant portal. Sun has been very active not only in co-leading the expert group and writing the spec, but also in building its own implementation of JSR 168 to address customers' requirements, says Abramski. Sun's Java System Portal Server 6.2 now conforms to the spec and will be marketed as such. It began shipping with Java Enterprise System 1.0 product, which is available now. The roster of expert members is a who's who of portal vendors, including Sun, IBM, BEA, Oracle, Vignette Software, and others. Abramski says JSR 168 is "absolutely important for Sun" and its competitors in the portal market. Many Sun Portal Server customers are already aware of the importance of the spec, and Abramski thinks it's "fabulous" that the Sun field force is asked a several times each week when the portal server will support JSR 168. He says ISVs and others who provide products complementing portal servers, have been "dying for this specification to be finished a long time ago because it's going to make their life much easier." Sun Java System Portal Server 6.2 http://wwws.sun.com/software/products/portal_srvr/home_portal.html BEA Sees Benefit for Customers and Partners
BEA's choice to get involved in JSR 168 as an expert member is "kind of the bread and butter of why we're in the Java community. We see it's good for our customers and partners because it's increasing the ability for our developers to implement applications that could be run on compliant portal servers," says Shane Pearson, director of product management, WebLogic Portal. "It really helps increase the value of the return on investment of our customers." According to Pearson, among BEA’s partners are content management vendors, such as Documentum, who need the ability to expose their content management application components as portlets for content-enabled applications in the portal. Customers with heterogeneous environments in their enterprise want to conserve resources by writing a JSR 168-compliant application just once, then running it on the multiple portal servers they’ve already installed. "BEA released a technology preview implementation to our developers after the specification 1.0 version was available to the public. This enabled our partners and developers to preview the specification and comment on the features," says Subbu Allamaraju, BEA's representative expert and senior software engineer. The technology preview was "very well received," Pearson reports. "We worked jointly with a few customers and partners who are really excited to adopt it because JSR 168 is going to make both development and maintenance easier for ISVs and customers who want to write applications for multiple portal servers. It provides another developer choice for building J2EE applications that can be more easily integrated for presentation in JSR 168-compliant portal servers." Other customers anticipate having a broader selection of Java portlets from different software vendors. JSR 168 support is delivered as a standard feature of WebLogic Portal 8.1, SP2, which is planned for general availability mid-December 2003. BEA is also enabling the portlet container with the Web Services for Remote Portlets (WSRP) protocol so portlets can reside on a remote machine. BEA WebLogic Portal 8.1 Product Information hhttp://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/portal BEA WebLogic Portal Software Download http://commerce.bea.com/showproduct.jsp?family=WLPORTAL&major=8.1&minor=0 JSR 168 Implementation Overview http://dev2dev.bea.com/products/wlportal81/articles/JSR168.jsp
Oracle Champions Remote JSR 168 Portlets
Oracle's JSR 168 implementation cleanly decouples portlets from the portal; while developers code portlets using the JSR 168 APIs, the portal sees the portlet as an OASIS standard WSRP service. "This decoupling provides a web-centric execution model," says Michael Freedman, senior engineer on Oracle's Application Server Portal project, who also represented Oracle on the JSR 168 expert group and OASIS WSRP technical committee. "Portlet content developers can publish, update, and maintain their portlets independently from the portal installations accessing them." In addition, the remote portlet architecture allows a portal to distribute its execution load.
"When running sites for tens or hundreds of thousands of users, it's important to separate and distribute generating the content from aggregating the page to achieve performance scaling," says Michael Freedman. "This is why we were active in both the JSR 168 expert group and the OASIS WSRP technical committee. Our role was to ensure the two standards worked together cleanly so that Java programmers would have a single standard for developing portlets whether they run remotely or locally." To support this architecture Oracle provides two pieces: a WSRP service that runs JSR 168 portlets and a portal that communicates with the WSRP service. Each will be included in a future release of Oracle Application Server 10g slated for 2004. In the meantime, at http://portalstandards.oracle.com, Oracle has made available the following free pre-release JSR 168-related items so developers can build and test JSR 168 portlets:
Rob Cheng, product director for Technology Marketing at Oracle,
says, "Companies and developers can use the hosted portal environment
to develop all their portlets in anticipation of the production
release. When they do roll out and upgrade their systems to support
the newest version of Oracle Application Server, they'll have the
confidence that in fact those portlets and that content can immediately
be implemented." Oracle Application Server 10 g Information http://otn.oracle.com/products/ias/index.html Updated Status of Oracle's JSR 168 and WSRP Standards Efforts http://portalstudio.oracle.com Plumtree Customers Prompt Portlet Open Source Trading Site
Early September 2003, Plumtree released a JSR 168 early access implementation. "Plumtree's leadership in and support of portal standards is one element of our Radical Openness strategy, which is our long-term commitment to ensure that every major component of our solution is interoperable with customers' existing technologies, even technologies that compete with our own," says Fubini, Plumtree engineering manager and standards ambassador. "JSR 168 is the first step in a long journey towards portal interoperability." Unlike implementations planned by some other vendors for JSR 168, Fubini says the Plumtree Container was designed to run on many application servers and Web servers including Apache Tomcat, BEA WebLogic, and IBM WebSphere. According to Fubini, Plumtree was able to quickly release the Plumtree JSR 168 Container because Plumtree's "loosely coupled" architecture allowed Plumtree to develop the container independently of the core portal. "Plumtree has a true Web services architecture for portlets and all the services in the Enterprise Web. The Plumtree Corporate Portal communicates with the Plumtree JSR 168 Container via Internet protocols, so JSR 168 portlets can also run on a platform separate from the portal. The portal consuming the JSR 168 portlets is likewise free to run on any Java 2 Enterprise Edition (J2EE)-compatible or Windows application server and is able to integrate a higher volume of portlets than it would if all the portlets ran natively with the portal," says Fubini. Moreover, Plumtree's use of Internet protocols, while consistent with the current version of the JSR 168 standard, also anticipates improvements coming with the next version of the standard to support remote portlets. JSR 168 was "widely anticipated" by the enterprise web community, and Plumtree's JSR 168 Container is being "received excitedly" by customers and partners. Large partners are using the new container to build their portal integration kits, while new customers see Plumtree's standards leadership and JSR 168 support as "crucial" in their decision to deploy the Plumtree Enterprise Web, says Fubini. "Customers clamored so much for our standards products as well as a view of what else was coming out in the marketplace that we initiated a Portlet Open Source Trading site (POST) along with Sun, BEA, and Documentum. The positive feedback and plentiful inquiries we have received around POST indicated the need in the marketplace for practical implementations based on the new standards," Fubini says. Standards in the portal industry are important to Plumtree because, Fubini says, "they free customers from basing technology decisions on whether a vendor's proprietary conventions will prevail in the market: a customer investing in Plumtree's industry-leading Enterprise Web software can now develop industry-standard portlets, and ensure that the investment can yield a return within any portal." The Plumtree JSR 168 Container implementation continues Plumtree's commitment to providing support for the best development tools available in both the Java language and .NET. Plumtree JSR 168 Container Information and Resources http://www.plumtree.com/developers/standards/ On-Demand Webinar with Gartner and Plumtree White Paper http://www.plumtree.com/03/Webservices Plumtree Implementation Announced http://www.plumtree.com/news_events/pressreleases/2003/press090303.htm POST Site http://sourceforge.net/projects/portlet-opensrc/ POST Announced http://www.plumtree.com/news_events/pressreleases/2003/press111003.htm
Documentum Uses Component Architecture
According to Documentum's web site, the company (recently acquired by EMC) provides "enterprise content management (ECM) solutions that enable people to collaboratively create, manage, deliver, and archive the content that drives business operations." Among these solutions are collections of portlets and an integration kit that allows content management applications to be built within a portal framework, which can be found at http://www.documentum.com/. But for Documentum to keep up with the maintenance of integrations on many frameworks and with many partners takes considerable engineering effort, says Jeff Spitulnik, senior product manager with Documentum's platform group. "Documentum saw that JSR 168 held the promise of plug-and-play for our portlets and portlet architecture across many portal partners' infrastructures." Documentum customers prefer a portal interface for ease of use, the need to use multiple applications more or less simultaneously in order to accomplish a particular task, and the recognition that business users may need only portions of applications, says Greg Dierickse, senior product marketing manager at Documentum. Enterprises are beginning to avoid monolithic applications from a single vendor in favor of composite applications they can customize into functional components. It's considered a waste of resources to train workers on an entire product suite just so they can do a "snippet of the job." Dierickse adds, "Naturally, our APIs and development environments like Documentum Foundation Classes (DFC) and Web Development Kit (WDK) are object oriented and componentized, so our application functionality is easily exposed through portlets." It's been "far easier" for Documentum to change its implementation of portlets to conform to JSR 168 than it was to keep up with the integrations of their previous implementation. The old and new architectures are essentially the same, but Documentum was able to enhance their Web Development Kit (already available for application servers) by "portletizing" the component architecture following the JSR 168 specifications. Spitulnik says that before JSR 168, in order to allow the WDK components -- the fundamental building blocks for a Web-based content application -- to work within a portal, an adapter had to be written specific to every portal vendor's API (and even then, custom components were required and adapters for some portals were not even possible). Now Documentum can replace those vendor-specific adapters with one generic JSR 168 adapter, unify the environments through which Documentum applications are built, and give customers the ability to design and deploy Documentum componentry in their portal-based applications. Documentum will highlight the product's relationship with JSR 168. "JSR 168 makes our job easier, and we love that. But it will also make our customers' jobs much easier. Our customers want to know that our product is JSR 168-supported. It's one of their checkboxes on the decision to buy. It's really important for them to have a lower total cost of ownership," Dierickse says. Customers "really love the standard" because they can pick and choose among diverse types of applications and have them run across diverse portal environments, then migrate upwards from one version of an application to the next as needed without fears of incompatibility. Bowstreet Broadens Customer Base
Neither Documentum nor Bowstreet served on the expert group, but each was listed as one of the 23 official industry supporters of the specification, and both followed the progress of the expert group attentively. Joe Lichtenberg, vice president of Marketing at Bowstreet, says, "We've been actively reviewing the interim JSR 168 specifications and participating in the public discussions. As soon as there were reference implementations available, we started to write to them." Bowstreet released JSR 168 support in its portlet development tools in December. "We will support and certify interoperability with the implementations from all of the various portal vendors as they are made available," says Lichtenberg. "In addition to our current support for JSR 168 in Portlet Factory for WebSphere, we will introduce a new version of Portlet Factory that is packaged specifically for non-WebSphere accounts in early Q1 2004." "The recent release of JSR 168 is extremely exciting to us because it allows users of any JSR 168-compliant portal to benefit from our extremely powerful dedicated portlet creation tools that up to now were available exclusively to IBM WebSphere Portal customers," says Lichtenberg. He notes that although large numbers of out-of-the-box portlets are available for companies to access and use, people "always, always" need to do custom portlet development to expose their own data and business processes in the portal to get value out of their portal implementations. "JSR 168 is great on a number of levels," he says. "It enables the entire portal market to benefit from our technology, while opening up exciting new business opportunities for us." JSR 168 Download http://bcp.bowstreet.com/download/index.htm JCP Coopetition Brings Out the Best Standards
Abramski of Sun feels the JCP is "obviously very cool in that the community process is literally open to any company that wants to participate in driving a Java standard."
Rose O'Donnell, vice president of Engineering at Bowstreet agrees, saying, "Ultimately, it's customers that benefit from the openness of this process. In my experience, the greatest value of the JCP is that vendors can collaborate to create standards without fighting each other in the open marketplace, where customers inevitably get burned by the differences. The JCP is an important protection for software customers."
Abramski labels this activity "coopetition." He asks, "How else are you going to get competitors and partner to sit down together for the better good of the industry and for the better good of serving customers to create something like JSR 168?" Fubini of Plumtree adds, "The JCP and its members have a balanced combination of Java experience, technical expertise and business savvy. This knowledge, added to the cooperative energy of the community is helping form technology guidelines that can improve the way creating software is approached today." Because of the success of previous standards, the industry views the JCP as a reputable program that produces high quality specifications that take into account each opinion about how a given specification should be created, says Abramski. The Executive Committee and JSR 168 spec leaders "did an exceptional job at making sure the spec was done right. I feel good signing up to this spec, knowing it has a life in front of it, it's going to evolve, we'll be able to take advantage of the ways it evolves, and hopefully we'll be able to continue contributing to its evolution," says Spitulnik of Documentum. Spitulnik's colleague Dierickse agrees. "We love it. It's a good standard. It helps us as a vendor in lowering costs and doing our development work more effectively. More importantly, it will greatly help our customers." Looking to the Next Version
Plumtree believes that Web services beyond just portlets are
needed to empower developers to build rich, interactive applications
within the portal -- Web services for profiling and authenticating
users, for crawling content and for searching across diverse systems
through the portal. “The completion of JSR 168 was an accomplishment
for the portal industry, but there is still much more to be done,”
Fubini says. Plumtree is already involved in discussions about the next version
of the JSR 168, Portlet Specification 2.0. Fubini says, "Our use
of Internet protocols, while consistent with the current version
of the JSR 168 standard, is done in anticipation of improvements
coming with the next version of the standard to support remote
portlets."
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
