Over the last couple of days, ICON UK took place at IBM South Bank in London. It was great to see the community in attendance for a wide variety of experts. I delivered a session of OpenNTF Domino API and CrossWorlds.

My initial feeling was that it might have been a quiet year for ODA. But I soon came to realise it’s been a pivotal year, with the maturity of aspects of code that have transformed the landscape for those of us close to the project. ODA began as a project to make Java coding in Domino easier and more standardised. But over the last year with the proving of Xots, we have greater ability than ever before to show that Domino and Domino web applications can deal with big data. With the refinements of Graph database, Domino data can be more than just NoSQL and, significantly, can be NoSQL and graph at the same time. The coming year will extend that further by bringing a maturity of REST access to the Domino Graph implementation. And CrossWorlds, OsgiWorlds and the work behind the REST access to Graph have enabled use of ODA from a variety of OSGi applications and servlets on Domino, but also from Websphere Liberty Profile.

The OsgiWorlds code will be coming to OpenNTF shortly (the demo application is dependent on some enhancements to ODA core). Daniele Vistalli is working on packaging and building of CrossWorlds. Currently, there is some manual configuration because it relies on including some jars from the Domino server or Notes Client on the same box that CrossWorlds and Liberty are installed on.

So for the time being, there are slides with screenshots of the demos I showed on Monday, but that’s something I’m conscious about replacing with code anyone can run.

5 thoughts on “ICON UK – OpenNTF Domino API (ODA) and CrossWorlds”

  1. Hello Paul,

    I couldn’t get to your presentation but it looks good. Is the demo database from slide 8 available ? I am intrigued by the Graph database stuff and Xots.

    We are using backing beans for most things now and finding a better way to sort and filter the documents in memory would be interesting.

    As an example this demo app ( http://www.focul.net/kd-demo ) woks well at the current scale it is but building a bean for very large data sets ( > 100k documents ) is slow unless you configure the navigation options carefully.

    We have a skinny backing bean and a full fat baking bean – the skinny bean has just enough information to sort the records and the the fat bean is loaded page by page with the other view data. The bean data for the actual document is loaded when the document is displayed.

    The skinny bean is populated by a formula search ( FT search is not dynamic enough )

    Does the graph approach essentially keep all of the document metadata in memory ? If so this might allow us to avoid rebuilding the bean on every new filter choice.

    Thanks, Sean

    1. It’s not currently packaged for availability. I’m currently developing it on CrossWorlds, but once it gets to a reasonable amount of pages, I’ll also put it in an OSGi application to run on Domino. That particular demo is just using Xots and the core steps are the same as on the blog posts linked to from the slides. I’ve not personally used the graph functionality for large data sets, though I suspect Nathan has. But in most applications I’ve planned, navigation would be using small datasets navigated to from specific vertices, e.g. conference Sessions based on a specific Track; then Ratings of the Session; Attendees planning to attend, actually attending, presenting it etc; Comments on the Session; Sessions other Attendees are planning on attending etc. But depending on the what the criteria are, if they would be vertices, that may mean not needing a search but just navigating via edges.

  2. Sean, yes, the graph metadata stays in memory. And yes, I’ve worked with some very large datasets (1 million+ vertices) And in your particular case of needing to sort & filter large numbers of documents, there are probably some very useful features.

    But I bet I can give you a quick performance boost based on this…

    “The skinny bean is populated by a formula search”

    Are you doing Database.search(formula) to get a DocumentCollection? Try instead using a NoteCollection and setting the same formula. If the NoteCollection will work for you, you should find that it builds considerably faster.

  3. Hello Nathan, thanks for your input.

    Our bottleneck is not in getting the collection but rather in extracting the data from the documents to build the bean – we loop through the collection using collection.getnextdocument(doc) and then beanattribute1= doc.getItemValueString(“somefieldname”) ;

    Is the advantage of using the notecollection ( as opposed to the notesdocumentcollection ) that the collection is created faster or that the getnextdocument is faster ?

    In terms of the graph data in memory – is it attached to a scope ( which may time out ) or is it only discarded at a significant event such as a restart ?

    Thanks again, Sean

  4. With the NoteCollection, the collection is created faster. And then you’ll be doing a Database.getDocumentById() instead of a .getNextDocument()

    When setting up a graph, you give a name to the graph itself and it’s held in the entire XPages JVM. It’s not a scoped variable.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.