When using WebSphere Application Server and Lotus Domino together to create an ebusiness application or portal, which topology you choose will depend on the purpose of the site and the software you plan on using to deploy it. First, you'll have to decide if it's to be a self-service customer site for ordering products, a collaborative site for partners and employees, a data access site for customers and staff to look up information, or a site intended to provide integrated access to several applications and databases. The goal of the site will help decide how important security is, what type of resource integration method is used, and whether Domino or WebSphere App Server will be the primary application.
To help developers navigate these choices and select the right topology for the situation, IBM has published a Redbook, entitled Patterns: Custom Designs for Domino and WebSphere Integration, which describes standard patterns for the layouts and product mappings used for different e-business scenarios.
In an environment that combines Domino and WebSphere App Server, there are five run-time patterns that may (or may not) be optimal.
1. Domino application with WebSphere services, single server. This pattern is most often used when WebSphere App Server is initially implemented in a Domino environment, and when simplicity in configuration and maintenance are important. In this case, the client accesses Domino via the HTTP server and is authenticated by the Domino Directory. Domino and WebSphere reside on the same server, which sits outside the domain firewall but behind a protocol firewall which allows only http access.
This pattern is best for simple scenarios that don't carry heavy transactional, functional or scalability requirements, and is suited particularly well for light-use collaborative sites that make use of Domino's messaging and workflow capabilities.
2. Domino application with WebSphere services, multiple servers. Here (as the name implies) Domino and WebSphere reside on their own servers rather than sharing a server. This is the ideal runtime pattern for Domino-centric sites that require greater scalability, heavier use of Domino functionality and better security for the WebSphere App Server, which is placed behind the domain firewall.
Like the single-server version, this pattern is fairly simple to implement, but provides for greater processing power and, thus, heavier use of the Domino workflow and collaborative features. Like pattern number one, authentication is done via the Domino Directory.
3. Web redirector with Domino and WebSphere Application Server. In this situation, both WebSphere Application Server and Domino sit behind the domain firewall while the WebSphere HTTP plug-in is used to separate out the Web server capability and place it into the DMZ. This provides higher security for both Domino and WebSphere servers. The HTTP server acts as a redirector, routing requests to either local, static Web pages or to either Domino or WebSphere Application Server, which in turn can provide access to other enterprise systems via Enterprise JavaBeans (EJBs) or servlets. The Domino server might also be used to access other systems via Lotus Enterprise Integrator.
One key advantage of this runtime pattern is greater horizontal scalability, with the HTTP server(s) providing load balancing between multiple application servers--a function that the other four patterns do not provide.
4. WebSphere Application Server application with Domino services. Here WebSphere Application Server acts as the front end to the system, providing a consistent user view to both Domino and other back-end applications. Domino, sitting behind the main firewall, provides collaborative and messaging servers, and serves up data residing in custom Domino databases.
For heavy-duty transaction-oriented systems, this pattern provides a high level of scalability (particularly when used with the WebSphere Edge Server) and better security for Domino data by placing it inside the internal network. (Normally, this pattern would also include other databases, such as DB2, and not just Domino.) User authorization would go through either the Domino Directory or a separate LDAP directory such as the IBM Directory Server.
5. WebSphere Web services with Domino. This pattern, although not yet very common, may become more prevalent as the use of Web services increases. In this scenario, WebSphere Application Server, sitting outside the domain firewall, provides Web services which access data and services on the backend Domino or relational databases. The Web services are published in a public UDDI directory and a SOAP-supporting client accesses the services over the Internet.
This scenario works best in situations where there are multiple application server platforms or where a wide range of users (partners, employees, customers) need to access information and services over the Internet from a standard interface. However, IBM advises against using this pattern in three instances:
- supply chain environments in which EDI already prevails as the standard for information exchange;
- where volumes of binary information must be transmitted (since XML is not an efficient way to encapsulate binary messages);
- when there are a lot of legacy systems that are easily made Web-services compliant.
Sue Hildreth is a freelance writer specializing in enterprise software. She can be reached at Sue.Hildreth@comcast.net.
