On the other hand, everything about Domino seems to run counter to IBM's grandiose WebSphere middleware marketing scheme. Questions routinely surface about Domino whenever it is mentioned along side IBM's WebSphere middleware tool suite. For instance, is Domino a part of WebSphere, or is it a competing WAS platform?
The R6 Pre-release 1 of Domino further clouded this question with the removal of certain Web-enabling elements that were part of a project code-named "Garnet."
Was Garnet the Future of Domino?
Garnet was an internal Lotus project that was designed to enhance Domino's ability to work with J2EE and Java servlets. Parts of the project were put in the Beta 4 code of R6 Domino. However, for a number of reasons, IBM/Lotus removed some working features in Pre-Release 1 of Domino R6.
From the developer's perspective, the Garnet project was providing--up to Beta 4 of R6 Domino--an upgrade of the Domino servlet engine to the 2.2 level, allowing it to support JSP 1.1, integration with the Domino Directory, and source-level editing of JSP and servlet design elements, along with some ancillary functions. The elements of Garnet were targeted to make Domino a more "standards"-based server in the WAS world.
All told, the goals of the Garnet project seemed designed to open the doors to new developers from other WAS platforms--and to give Domino developers a finer control over the final Web disposition of their applications. After all, in order to play "hardball" in the larger world of WAS, a server suite must provide standards-based services with the greatest possible power and punch. And if an application server such as Domino is to compete head to head with WebSphere, Tomcat, WebLogic, or IIS, it had better have the features and functions that those communities of developers are used to using.
However, according to sources within Lotus, it evidently soon became clear to the developers of R6 that the scope and the direction of some of the items contained within the Garnet project were overly ambitious and that, in some measure, they really did not represent a realistic view of how Domino should be used within IBM's larger vision of J2EE.
From the IBM/Lotus perspective, the same basic questions about Domino's capabilities and market segment that have confounded analysts in the industry needed some clarification. For instance: Is Domino a real WAS, or is it a messaging and collaboration server? How is it really used within the community of customers and developers, and what are its greatest strengths? If Domino is truly a WAS, does it need to fully implement the standards of J2EE, or can it get away with implementing a new subset of those standards?
In the end, IBM/Lotus chose to remove the embedded J2EE server, leaving the R5 servlet engine for backward compatibility. It also removed the ability to edit JSPs and servlets in the Domino Designer as well as the ability to write JSPs in LotusScript. Here's why.
Mix of Standards in the World of WAS Developers
First, according to IBM/Lotus, you shouldn't have partial compliance with standards. You shouldn't do some with the functions of J2EE and do others with a different model. Even if mixing models and standards is useful to a particular user set, it runs against the fundamental concept of industry standards. Though Microsoft and others get away with this mixing and matching of standards, it was not what IBM/Lotus wanted to do in R6 of Domino.
Second, for the run-of-the-mill J2EE developer, a Domino-centric WAS strategy was unrealistic. In the real world, J2EE developers start with a J2EE WAS--WebSphere, BEA, Tomcat, iPlanet, etc.--and build their applications from that base, accessing other servers via Java and connectors. However, if Domino had a J2EE engine inside, it was bound to confuse people and contribute to the idea that Domino was a kludge, not a real solution at all.
Finally, IBM/Lotus has finally concluded that Domino is not designed as a WAS in the widely understood sense of the word. Instead, it is a collaboration server upon which developers and customers build great applications. Though it has great advantages over the typical WAS--such as RADD, multi-client support, replication, security, etc.--it is not on the list when someone's buying a WAS to integrate enterprise middleware for Web applications.
Viewed from this perspective, implementing the Garnet project in R6 was creating a risk for IBM/Lotus that the benefits of Domino would be further confused in the world of J2EE compliance.
What Was Left from the Garnet Project
Given that IBM/Lotus decided to pull some of the features of the Garnet Project, what, you may ask, did they leave in for R6? The list is still somewhat impressive:
- Bundled developer version of the WebSphere App Server 4.x
- JSP Tag Library
- Hardened Java APIs
- WebDAV (Web Distributed Authoring & Versioning)
- Multiple HTTP stacks
- Single sign-on via LTPA with WebSphere App Server
Bottom Line of R6 Without Garnet
For the industry analyst trying to understand the IBM/Lotus WAS strategy, the removal of the J2EE features of Domino sends a mixed message. First, it's clear that IBM/Lotus has finally come to terms with the issue of overlapping services between its product lines. Domino remains a highly proprietary platform that complements but does not compete with IBM's WebSphere strategy. But its future--as J2EE standards for collaboration services continue to evolve--will still need to be addressed down the road. Whether its functions as a collaborative server will be superceded by other WAS services on other platforms is still undetermined and unexplained. These standards are evolving quickly and are too rich for a single organization in the market to try to dictate.
For the customer and the developer, the removal of the J2EE features of Garnet will force them in the long run to consider other means of integrating non-Domino Web middleware for the enterprise. However, this is less an obstacle than it might appear on the surface. As WAS standards continue to evolve--creating a superset of features and functions--it's probably better to have applications that run on the Domino platform integrate as connecting services than to attempt to compete with the overall functionality of larger WAS services. Yet, this should be a clear message that enterprise-level WAS applications should not be contemplated for Domino down the line. It probably won't support those WAS services directly, and it will probably be better to see Domino as an element of the solution, rather than the solution itself.
Still, the bottom line of R6 is pretty impressive: It still provides one of the most robust and comprehensive solutions to collaboration that is available. It is still a proprietary platform, but it's positioned to connect well with non-proprietary standards-based WASs. Its highly functional, feature-rich, highly adaptive model constitutes one of the most cost-effective means of delivering collaborative applications to organizations of any sizes. It's easy to set up, and it's got a great growth potential within the realm of collaboration.
This mix of values and features and limitations will undoubtedly still drive analysts crazy as they try to pigeonhole Domino in the world of J2EE. But for customers and developers, the ground is still very fertile for growing great collaborative and workflow messaging systems on this unique and highly productive platform.
Thomas M. Stockwell is the Editor in Chief of MC Press, LLC. He has written extensively about program development, project management, IT management, and IT consulting and has been a frequent contributor to many midrange periodicals. He has authored numerous white papers for iSeries solutions providers. His most recent consulting assignments have been as a Senior Industry Analyst working with IBM on the iSeries, on the mid-market, and specifically on WebSphere brand positioning. He welcomes your comments about this or other articles and can be reached at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online