Web services

Unlike the other interface methods described in this section, the use of Web services applies to not only IBM-specific solutions, but also opens up real interoperability between disparate platforms, including Microsoft .Net, Sun Open Net Environment (ONE) and a variety of open-source solutions. Any vendor that adheres to the W3C standards and recommendations related to Web services can serve as a provider or consumer of Web services.

The primary technologies utilized by both consumers and providers of Web services include:

eXtensible Markup Language (XML) - A self-describing, extensible format for encoding data.

Simple Object Access Protocol (SOAP) - A lightweight protocol for exchange of

information in a decentralized environment, based on XML. HTTP servers are traditionally utilized as the transport mechanism for SOAP information. However, in theory, SOAP may utilize other transport mechanisms.

Universal Description, Discovery and Integration (UDDI) is a vendor-neutral, standard directory that contains interface information about registered Web service providers.

Web Services Description Language (WSDL) is a W3C sanctioned XML format used to describe the nature of published Web services.

The advantages of Web services in any integration framework are many, including:

Web services are self-contained and abstracted from the implementation layer. Web services deployed on the IBM J2EE WebSphere Application Server platform, for example, will interoperate with Web services deployed on a Microsoft .Net platform.

Since Web services are deployed using XML, messages sent to and from a Web services server are self-describing and can be easily parsed in any language with readily available code libraries.

Web services can encapsulate existing business objects, including EJBs, JavaBeans, or DCOM objects, and tools are widespread that easily encapsulate business object entities in a Web services wrapper.

For the sake of discussion in this redbook, we are interested in providing a Web service, hosted in WebSphere Application Server, that encapsulates Domino-specific functionality. Alternatively, Lotus Domino may serve as a Web service provider. However, as just described, there is nothing inherent in this interface method that would prevent a non-WebSphere or non-Domino application from achieving the same general interface. Hence the beauty of Web services: relatively simple interoperability between dissimilar and potentially geographically dispersed systems.

Typical usage scenarios

Web services can be implemented in a number of ways. From either the Domino or WebSphere perspective, Web services can be utilized or published.

Some examples of utilizing Web services to implement interfaces between Domino or WebSphere Application Server are:

A Domino server may provide a Web service that provides user information contained in the Domino directory, such as an individual’s address or phone number.

An agent written in Domino may act as the consumer as a Web service contained on a WebSphere server to obtain stock price information stored in an IBM DB2 database.

A WebSphere server may act as the provider for a Web service that aggregates data from a Domino database and an Enterprise Resource Planning (ERP) system. The Web

service may provide information, such as an employee’s current health care benefits selection and their current mailing address from the Domino Directory.

In Lotus Domino, Web services can be written using LotusScript or Java-based agents. In LotusScript agents, a SOAP-encoded message can be manually assembled or disassembled through code, or more simply through the use of the Microsoft Toolkit for SOAP, which includes an MSSOAP COM object. In Java agents, the classes provided in Apache SOAP and Apache XERCES projects (both freely available on http://www.apache.org) provide similar capabilities, simplifying the steps required to create and decipher SOAP messages. When constructing a Web service that will be served using WebSphere Application Server, Apache SOAP and Apache XERCES projects should be utilized to assist in the creation of either Web service provider or consumer services.

Benefits and limitations

There are several benefits in the use of this interfacing mechanism, such as:

Web services are self-describing and fairly simple to parse using standard toolkits since they are based on XML.

Web services are based on open standards, and will interoperate well with Web services provided on a variety of platforms, regardless of their underlying implementation.

Web services may serve as data aggregators, providing read and write access to not only Lotus Domino databases, but also relational databases, such as DB2.

One of the limitations of Web services is the added complexity of implementation. For example, a Web service provided in WebSphere Application Server that accesses a simple document in a Lotus Domino database must not only use the Domino Objects for Java to access the database, but must also use SOAP to encode and decode the service envelope and header, (potentially) publish the Web service in a UDDI directory, and create a properly formed WSDL XML body that accurately describes the service provided.

Fortunately, modern integrated development environments (IDEs), such as IBM WebSphere Studio Application Developer, include various wizards that simplify this process dramatically.

3.3.5 Domino tag libraries (JSP)

The Domino tag libraries provide an alternative mechanism for accessing Lotus Domino databases without the need to learn Domino Objects for Java or DCOs. These tag libraries provide high-level access to Domino forms, views, and other Domino design elements. Like DCOs, it should be noted that the Domino tag libraries may utilize the remote (CORBA) implementation of Domino Objects for Java, or the local implementation of this mechanism for single-server patterns.

JSPs, of course, are served from a WebSphere Application Server environment, providing a significant amount of scalability, as well as integration with other systems.

Typical usage scenarios

Domino tag libraries are utilized in JSP pages that require access to Lotus Domino database information. The Domino tag libraries may be the best choice for programmatically accessing Lotus Domino data from JSP pages for developers accustomed to JSP page development and the use of JSP tag libraries. Single sign-on is supported through the use of the Domino tag libraries, in addition to the ability to execute full-text searches and run server agents.

In addition, several tags are available that allow state and environment information to be used within a JSP page. These tags include, for instance:

The ability to determine the ACL settings for the current user

The ability to create or delete documents in a database

The ability to execute server-side Domino agents

The ability to execute @Formula commands

Benefits and limitations

The most obvious benefit of the Domino tag libraries is that developers do not need an understanding of the Domino Objects for Java. Instead, developers need to understand the Domino tag libraries and the use of JSP. Therefore, this interfacing method is most suited to teams with servlet and JSP development experience, but little direct Domino Objects for Java knowledge.

Another benefit of Domino tag libraries is in the level of integration to be provided in IBM WebSphere Studio Application Developer. Lotus will soon be releasing a plug-in for the WebSphere Studio Application Developer environment that provides more direct integration of JSP development in WebSphere Studio Application Developer with existing Lotus Domino databases. For example, a form in a Lotus Domino database may be “imported” into a WebSphere Studio Application Developer project as a JSP page utilizing Domino tag libraries to represent various design elements from the original Domino form.

From another perspective, since JSPs would be served from a WebSphere Application Server, they provide a wide range of scalability options.

The disadvantage of using Domino tag libraries is that functionality is limited to what is provided in the JSP tags themselves. An analysis of the functional requirements of an application, or a specific JSP page, must take into account the specific tags available in the Domino tag libraries to ensure that functional requirements can be met.

Lotus Domino Toolkit for WebSphere Studio

The Lotus Domino Toolkit for WebSphere Studio is a product that lets application developers access Lotus Domino applications and data from WebSphere Studio. The toolkit is built on the Eclipse open source platform and it shares a common look and feel with other

WebSphere toolkits. With the toolkit, it is possible to see deployed Domino applications on the Domino server and reuse Domino forms, views, and agents in J2EE applications.

The toolkit isn't a programmable method to access Domino data itself. It generates Domino custom tag code automatically for Domino design elements when dragging those elements to a Java Server Page in WebSphere Studio. The toolkit installs the Domino custom JSP tags for the WebSphere Studio environment for easy use and for access to help and samples.

This toolkit helps Notes/Domino application developers understand and implement the new Domino custom JSP tags that ship with Domino 6. Developers can use their existing

development skills and blend Domino's application platform advantages for collaboration with the transactional aspects of WebSphere applications designed for the J2EE architecture.

Tip: Despite this disadvantage, another considerable benefit tied to the use of Domino tag

libraries is the introduction of more generic, mainstream J2EE development, which is a core foundation of the Lotus NextGen strategy. The use of Domino tag libraries, then, may be considered a stepping stone for Lotus Domino developers into the J2EE world.

For J2EE developers developing with WebSphere Studio, the toolkit allows access to the Notes/Domino data store and application features within the context of the J2EE technology. The toolkit understands how to connect and what’s needed to connect to Domino data, and it configures JSP tags with attributes automatically. Without the toolkit, the developer needs to understand how to connect to Domino data, set up the connection, and code the JSP tags manually.

The Lotus Domino Toolkit for WebSphere Studio will be included in a future version of Domino Designer 6. It requires both Domino 6 and WebSphere Studio V5. Final code is currently scheduled to be generally available with Lotus Domino Designer in Q2 2003.