Standard set of Lotus Domino web services
The other day, John Turnbow blogged about this and also put up an idea on IdeaJam. Where are the standard set of Domino web services?Just about every other application framework has AT LEAST a set of basic services to build on, and some even have specialized services exposing core functionality to Service Oriented Architectures or even just to acommodate service based integration and development.
Since R7, the Domino server has been able to expose native web services, but no basic services were provided. With R8, Lotus (or IBM Lotus) has provided a client framework that is extendible, mashable, and able to be a client for advanced composite applications. It has been branded "The Desktop of the Future" and the IBM "Open Collaboration Client Solution", and on occasions has been touted the "Client for SOA".
But where IS "SOA" in the Notes/Domino philosphy? It seems that focus is all on the client and on the ability to consume web services and wery little is on the provisioning and deployment of web services. But with no focus on providing and deploying web services, why would anybody select Domino as a service provider?
IBM has an extensive SOA strategy. Domino should as a minimum play well with that strategy, and ideally play well with SOA as an architecture style in general, not just geared towards the IBM ESB or other semi-proprietary platforms. But flipping through the slide decks from Lotusphere, the SOA message is at best vague. At worst, it is completely out of alignment with the rest of IBM's SOA message. I'm not even sure the definition of the term is consistent inside the branches of Big Blue.
I would like to see that fog being cleared, and a great way to start would be to provide a set of specialized Domino services as a part of any Domino server. Obvious candidates for services are simple PUT and GET operations, lookups and the like. Also directory services should be included as should the ability to check credentials against the user's ID-file and carry them through to other services. After all, Domino can take the role of the main corporate user directory!
There is great interest in Notes/Domino 8 and 8.5 at the moment, not diminshing as MS stops recommending upgrading to Exchange 2007, and being the "strategic fit" wouldn't make things worse, that much is certain.
I have often considered starting a project on OpenNTF with exactly this objective, but since I'm not a developer (or at least a very rusty one), I've held back so far. Also, I honestly believe that this functionality should be native to the platform and supported by IBM Lotus.
But no matter what, John's idea is very, very valid and I heartily support it.
So could you, but promoting it at IdeaJam.
(And this is where I would love to embed the IdeaJam plugin for John's idea, but being a complete idiot, I can't make that work, so PLEASE click through on the link above).
src="http://www.ideajam.net/IdeaJam/P/ij.nsf/ideajamblogthis.js">
Domino Lotus SOA Web services June 7th, 2009
2 Comments
1. Axel | 6/7/2009 1:21:20 PM
Hi,
from my allways limited experience there is a much greater demand for Domino as a Webservice Consumer than as a producer.
Specialized SOA platforms emphasize non-functional requirements like a very high grade of reliability/failover, transactions, easy integration. Those has not been the traditional strengths of Domino.
Integration with other platforms can become easier with using Webservices (REST and SOAP), though it has also some costs as a learning curve for the organization and the developers. For example SAP guys show an astounding cross-organization tendency to push requirements for their unnecesary complex SAP Error datastructures to the consumer ;-)
Have done 3 projects that used consumer Webservices on Domino 6 and 7(SOAP and REST). Have written my onw framework and am about to openSource it.
Generally agree with you that there should be a REST Webservice Producer component for Domino, though Domino will not be the best basis for a "real" SOA platform, that honours the non functional requirements mentioned above.
2. Lars Olufsen | 6/7/2009 1:46:57 PM
Oh, I agree completely that Domino should not be the basis for a SOA platform at all. But "real" SOA is not about transactional web services - that is way to fine a granularity. Effective SOA is about mirroring business processes and business process elements, and If you dissect your business processes, you're likely to find that native Domino functionality appears a lot.
The most basic example is sending an email. How many times a day is mail sent as part as a business process in your organisation? In ours, it's quite a few. Sending an email - and I don't mean a spoofable, high-risk, low-featured SMTP message - should be available as a service on any SOA platform, including all the facilities surrounding the email, that Domino could provide, such as authentication/authorization and encryption, not to mention all the workflow that you can do with Domino.
I don't agree regarding reliability/failover. Domino can be rock solid if done right, and failover can be seamless.
But I DO agree about the lack of "easy integration". Hence the need for improvement in that area, and how better than a bunch of web services that plays well with SOA - the "integration architecture" of the hour?