Integrating Composer and NPS: A Study of Strategies for Using Novell exteNd Composer with Novell Portal Services
Articles and Tips: article
Lead Consulting Engineer
Integration Product Specialist Group
jdumblauskas@novell.com
01 Feb 2003
About Novell Portal Services and Novell exteNd Composer
Novell Portal Services (NPS) is an out-of-the-box portal that is easily configurable and highly developer-productive. Novell exteNd Composer is an XML integration server that allows access to a wide variety of data sources including (but not limited to) HTML pages, CICS systems, 3270 and 5250 systems, FTP, and databases (that support JDBC).
NPS has a much wider market penetration than Novell exteNd Director. It makes sense to examine the integration between NPS and Composer, because Composer can help customers who already have an investment in NPS and need back-end access to legacy systems.
There are many strategies for getting data from NPS to Composer and back again. These are the three addressed in this study:
Create or modify a gadget that programmatically invokes a Composer service
Make an HTTP servlet call
Use jBroker Web
The three strategies each have their own strengths and weaknesses, depending on how they are used. Let's look at each strategy.
Strategy 1: Create or Modify a Gadget
You would use this strategy to maximize performance and to integrate with an existing NPS setup. The strengths of this strategy are programmatic invocation of Composer services (which has better performance, since there is no HTTP overhead). This strategy also has better integration, since most NPS setups that are customized have custom-written gadgets.
The custom phone book gadget was developed as an example for this study. This gadget uses the Composer JDBC connector as its data source and replaces the code in the standard phone directory gadget that searches the directory (the PortalConnection SearchDirectory method) with a Composer call that searches a database.
The drawback to this strategy is the application server issue. At present, the strategy will not work on a standard Apache Tomcat installation (which seems to be the most common way NPS is deployed).
That's because to be programmatically invoked, Composer needs to be in the same process as the calling code. But at present Composer can only be installed into three application servers: Novell exteNd Application Server, IBM WebSphere, and BEA WebLogic. Novell is investigating market opportunities and technical feasibility for Composer to expand support to other application servers, such as Apache Tomcat and Sun ONE. No commitments or specific timeframes have been announced to date.
Strategy 2: Make an HTTP Servlet Call
The HTTP servlet call is Composer's bread and butter: it is flexible and reliable and can side-step most firewall network issues. The only drawback is HTTP overhead.
In the case of an Apache Tomcat installation, this strategy would be the only main option (using a SOAP call is really a subset of this strategy). The example for this strategy is a static page deployed on Tomcat that is accessed through an IFrame gadget. The page accepts parameters and invokes a call to the Composer service running on a Novell exteNd Application Server.
Strategy 3: Use jBroker Web
Using jBroker Web involves using a SOAP call to invoke a Composer service. This third strategy is really a hybrid of the first two: the Composer server still needs to run on WebSphere, WebLogic, or the Novell exteNd Application Server. But through using jBroker Web 2.0 in the gadget, you can make a programmatic call.
This call still has HTTP (and SOAP) overhead but has the advantage of having the service deployed in a language- and platform-agnostic manner and having the client code able to call the service (although a programmatic HTTP call can be made in the gadget as well).
The example for this study uses a modified phone book gadget that uses jBroker Web 2.0 to act as a client. The gadget uses the jBroker Web to make a SOAP call to the server.
Summary of the Three Strategies
The following table gives the strength and weaknesses of each strategy this article has talked about.
|
Option
|
Strengths
|
Weaknesses
|
|
Create or modify a gadget that programmatically invokes a Composer service |
Programmatic invocation; tighter integration |
Can be deployed on only three application servers |
|
Make an HTTP servlet call |
Highly flexible Reliable |
HTTP overhead |
|
Use jBroker Web |
Uses standards; can write code in the gadget |
HTTP overhead |
Another Possible Strategy
These three strategies are by no means the only ones that are available to you. Another possible strategy is to have the service developed with an EJB service trigger.
Calling the Composer service would be (from the client side) the same as the HTTP servlet call. If the container that NPS is deployed on supports EJBs (like a JBOSS), you can make a programmatic call. This assumes the container that NPS and Composer are deployed on implements the EJB 2.0 specification.
Reference
Composer project attached in ZIP file (to be deployed on a Novell exteNd Application Server)
NPS.zip (the NPS WAR file)
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.