« Book Review: Carl Hiaasen - Stormy Weather | Main| Book Review: JK Rowling - Harry Potter and the Half Blood Prince. »

Rebuilding the Notes replicator....

Category None
Bookmark : del.icio.us  Technorati  Digg This  Add To Furl  Add To YahooMyWeb  Add To Reddit  Add To NewsVine 

Now here's an interesting scenario. Us Domino guys are well used to the idea of a complex, rich application shared between people in a single organisation. Lets consider a simple "helpdesk" application (okay, no helpdesk application is simple, but bear with me in terms of the example....)

Lets imagine within a company, we have a helpdesk style application, where folks can raise help requests in a local replica, and then see responses, status updates and fixes replicated back to their applications. But only see the helpdesk requests that the end-user raises

In a native Domino application, this would take a heartbeat. A simple application, some reader/author fields, a response hierarchy. And Domino does the rest, by allowing rich text to be exchanged. Essential in a helpdesk application where you might expect a customer to include screenshots, and/or other rich data

Lets change the goalposts somewhat. Lets imagine that your a small ISV, and wish a helpdesk application, using the Notes client (and all the Richness that that implies), that can be used by each customer. In the customers Notes environment - we have no access to (nor wish to access) this environment. Remember, we're a Notes ISV, and this is a strong assumption we can make. However, we cannot assume that any corporate will allow cross-certification and replication anymore. There seems to be no appetite for this. So how do we proceed?

In fact, the only constant that we have is that most clients and servers in a corporate environment can initiate a web-based session with something on the internet. Now, this smells like a web service, hosted on our Domino service

Okay. So we could write a web service on our Notes server, and therefore trigger web service requests from the client's notes machines. These could easily export whole Notes documents as streams of DXL (Domino XML exported data) ,and then all we have to do is decide which documents to pass back and forth. Simple, eh ?

What would drive this "replication" engine ? Well, since we're not going to host any logic in scheduled agents, it would be simply on document-updates and/or refresh buttons in the view - so that each user of the remote application may have their own replica, if required.

In fact the more I think about this, the more attraction this has as a general purpose "replication" tool between enterprises, on an ad-hock basis. The upside of course is that the users still keep using the notes client (and all the speed and rich text advantages that brings), its a fast application to develop (just a handful of fields, a couple of documents, a view or two). Notes gives us the document unique number - ensuring (pretty much) that we know which documents exist in each replica. And the downside is that you have to come up with "replication-style" logic for each application.

Now dont for a second think that it has to be a Domino client and a domino server - remember, we're just chucking around XML documents. In this instance, as one of our requirements is to use Notes Rich Text, then using a Notes client would give us a huge saving in coding - but this could be *any* application. I suspect as time goes on and Web Services become even more commonplace in our environments, this will be seen as an everyday task in the near future.

I think this is a great example of taking our Domino application infrastructure, adding some well-known, open standards tooling, and letting us extend the visibility and reach of our domino applications way beyond a single enterprise. This even starts to smell like a lotusphere presentation, right ?

Comments

Gravatar Image1 - Neat idea, Bill. As an alternative, it could be done via email -- if you can assume that a mail-in database and mail-triggered agent processing would be allowed on the server. Doc creation and updates could mail the DXL to you, and you would mail updated DXL back to the mail-in. Not as 21st-century as a web services solution though.

-rich

Gravatar Image2 - Oddly enough, back in 1992 (god, 13 years ago!) I worked for a 200m (sterling - so figure 350m dollars) oil service company that did precisely that to create a replicated, global Foxpro (remember that?) solution on top of cc:Mail (God, that rocked!) in order to implement a purchasing system. Those were the days...

Whilst now web services give you the format (XML) and the transport, and more importantly, real-time status infomation. Store and forward email systems have to be infinately more robust, and assume message (packet!) loss...

---* Bill

Gravatar Image3 - Well using web services over SOAP you could actually leave the transport decision to the implementer since SOAP is transport agnogstic.

I really like the idea and it made me think of the new replication engine for DB2 where IBM does something a lot similar. In previous editions replication in DB2 was done using regular proprietary SQL replication. The new version on the other hand uses XML messages exchanged via Websphere MQ. It sure smells a lot like what you are providing.

Couldn't it also be made totally transparent to the end users by using the database/agent manager plugin Damien Katz wrote where you can subscribe to database updates?

Just some thoughts...

/lekkim

Gravatar Image4 - Seems to me that triggered web services, without scheduled agents to back them up, would also have to cope with message loss. Much like cluster replication has to be backed up by scheduled replication.

-rich

Gravatar Image5 - Hi,
I like the idea very much. What I could see as useful would be a simple Export/Import functionality, possibly combined with email.
e.g. select a Notes document or design element, click on export, choose a recipient and off it goes. If the email was to a Notes user then the email itself could contain the code to integrate the new design element into a user-selected database.

Regards
Ethann

Gravatar Image6 - Ah. Code and eMail. I think most corporate systems would have a heart attack if folks started executing code originating outside their secure environments...

---* Bill

Gravatar Image7 - Did u say u had a Masters degree ?

Gravatar Image8 - Me ? Masters ? Nooo.

---* Bill

Gravatar Image9 - Sounds like time for a J2EE Open Replicaiton API. Then all you need is to drop the ORAPI based object on your Eclipse project and Voila.

Needless to say the engine would have to handle the RepId of the records/documents and format interchange (given Like/non like db replication, fields in common, formats in common etc.....). But the important thing would be that the replication logic would confirm to one standard for all applications that used it.

It would allow you to expose data in the best application set, per function, and get rid of a whole raft of middleware. Hmmm, I think this idea just died on the altar of revenue.....

Finalist's Site Marker 3.jpg

www.flickr.com
wildbillbuchan's photos More of wildbillbuchan's photos

News

Loading...

Quick Bill


I'm
- a Lotus Domino Dual PCLP - that is, a SysAdmin PCLP and an AppDev PCLP (or IBM Certified Advanced Application Developer and Advanced System Administrator) in nd7, v6, v5, v4 and v3.
- an IBM Certified System Administrator - Websphere Portal v5.0
- an IBM Certified Solutions Developer - Websphere Portal v5.0
- an IBM Certified Associate Developer - Websphere Studio v5
- an IBM Certified Solutions Expert - Websphere v4.0.
- a SUN Java 2 Certified Programmer
- a (probably lapsed now) Microsoft MCSE in Windows NT4.
- a (definately) lapsed now CLP in cc:Mail v2 and v6