Skip to main content

Transforming Domino into a Social Collaboration Platform, Part 2B - Experimentation


Transforming Domino into a Social Collaboration Platform, Part 1 - Where Do We Begin?
Transforming Domino into a Social Collaboration Platform, Part 2A - Experimentation

This is the second part of our experimentation portion of the series. In Part 2A, I talked about the different experiments that we did for creating web pages for our social collaboration applications and the design of the back-end database.  In part 2B, I will be talking about the application structure and business process and workflow management that you need in order to have a successful social collaboration tool. 

As I mentioned before, there were four areas of technical challenges that we had to overcome.
  • Web Interface Generation
  • Database Infrastructure
  • Application Structure
  • Business Process and Workflow Management
In this blog we will cover the last two.

Application Structure
Traditionally with Domino applications, an application consist of one or more Domino databases.  We build the forms, the views, and then the application logic.  With XPages, we can create the application using a combination of many languages and methods of implementation.  This is one of the greatest features of Domino, but also is one of its biggest drawbacks because it allows developers to chose whatever direction they want and it will work.   Each time you want to create a new application you create more databases.  So the more applications the more Domino databases you needed to maintain and manage leading up to an unyielding amount of maintenance and inconsistency. 

We wanted to minimize the number of databases that we needed and utilize the JSON database structure that we created.  Since we did not use the traditional XPages development method, we were free to develop our own approach to application development in Domino.  Having the front-end approach and the database infrastructure, we needed the controller to tie everything together. 

We could create a tightly coupled solution that allowed the server to generate the web page which has better performance or we could use RESTful services to provide the data and have the client JavaScript to generate the information on the web page.  After many experiments, we concluded that the best solution was to have the server generate a web page framework and use RESTful services using our Dojo data binding to populate the web page.  This approach was more flexible and totally decoupled the data from the form.  However, the danger of this approach is that for very RESTful service call a HTTP request is required.  Therefore, we had to be very careful on how we used the RESTful requests.

We created a standardized framework that allowed us to create RESTful services using whatever tools we were comfortable with including Java, SSJS, or LotusScript.  We started off with LotusScript since that was our existing toolset. Since RESTful services are independent of the Web page generation, we can migrate from LotusScript to whatever toolset when appropriate.  At this time, most of the RESTful services are still written in LotusScript though we are beginning to migrate over to Java.  We decided for now that only services that are call often will be migrated to Java.

Since we are generating our own RESTful JSON services, we standardized on a simple extremely lightweight JSON data format that minimizes the amount data that the server needed to transfer.  The format is far different compared to the Domino Data REST format which is very heavy. With a lightweight format, the data binding process is faster, requires far less coding and allowed us to create as a reusable Dojo class that can be applied to all binding objects.


RESTful versus REST
As I mentioned, we are using RESTful JSON services and NOT REST JSON services. There is a major distinction here.  For complete REST services, you have READ, WRITE, EDIT and DELETE. which involves GET, POST, PUT, and DELETE.  For us this is a security problem.  Yes, a person maybe authenticated but in environment where there are multiple ACL and roles defined, you can easily open a security hole where the user has undesired access.  In our RESTful JSON services we only have GET and POST.  In each process, the controller determines from its security analysis what information you can get and also whether you have rights to read, save, edit, or delete down to the individual field level.  By using the controller to determine user access and data security, users NEVER has direct access to the data.  Only through the RESTful APIs can the user request the data. By centralizing data access you reduce your data exposure.


Business Process and Workflow Management
For organizations social collaboration tools aren't very useful unless there is a compelling reason for using it.  It needs to be an integral part of an organization's business process and workflow to be effective.  If not, the social collaboration technology becomes no more that a paperweight and what I call a feel good tool.  From our experience of  developing business process and workflow solutions, we developed an entire framework over the years for creating and managing business processes and workflow applications which became our iPhora Foundation technology. So the next step was how do we integrate social collaboration to become part of an organization's business processes.

The solution was to create bidirectional event trigger points within the social collaboration tool API and utilize the iPhora Foundation API to handle the process.  An incoming event received by the social collaboration tool would trigger a process within the social collaboration tool and it itself can then trigger addition events within or externally to others processes.  Since the trigger event maybe activated by web services or something as simple as a email event we wanted to create a standardized communication process that provided an abstraction layer.  We accomplished this by creating a connector framework.

We are still expanding on this approach.


Next time, part 3
Transforming Domino into a Social Collaboration Platform, Part 3 - Teaching an Old Dog To Do New Tricks

Comments

Anonymous said…
"workflow management that you need in order to have a successful social collaboration tool"

why is that? e.g. where is the workflow in connections, yammer, facebook, twitter?
That is a good question. Some may differ, but I would not place Facebook or Twitter in the same class compared to Connections and Yammer. That itself can be a whole different discussion. The sad fact this that we are all cogs in the wheel of an organization and we have a certain job to do regardless if we are employees, contractors, or whatever. So everything is about a process and for collaboration to work effectively it has to be part of that process. In most social collaboration tool, we as individuals are the trigger point in the process, but by incorporating workflow management into the social tools, the process can be more automated and efficient.

Popular posts from this blog

The iPhora Journey - Part 8 - Flow-based Programming

After my last post in this series -- way back in September 2022, several things happened that prevented any further installments. First came CollabSphere 2022 and then CollabSphere 2023, and organizing international conferences can easily consume all of one's spare time. Throughout this same time period, our product development efforts continued at full speed and are just now coming to fruition, which means it is finally time to continue our blog series. So let's get started... As developers, most of us create applications through the conscious act of programming, either procedural, as many of us old-timers grew up with, or object-oriented, which we grudgingly had to admit was better. This is true whether we are using Java, LotusScript, C++ or Rust on Domino. (By the way, does anyone remember Pascal? When I was in school, I remember being told it was the language of the future, but for some reason it didn't seem to survive past the MTV era).  But in the last decade, there a

Creating Twitter Bootstrap Widgets - Part II - Let's Assemble

Creating Twitter Bootstrap Widgets - Part I - Anatomy of a Widget Creating Twitter Bootstrap Widgets - Part II - Let's Assemble Creating Twitter Bootstrap Widgets - Part IIIA - Using Dojo To Bring It Together This is two part of my five part series "Creating Twitter Bootstrap Widgets".   As I mentioned in part one of this series, Twitter Bootstrap widgets are built from a collection standard HTML elements, styled, and programmed to function as a single unit. The goal of this series is to teach you how to create a Bootstrap widget that utilizes the Bootstrap CSS and Dojo. The use of Dojo with Bootstrap is very limited with the exception of Kevin Armstrong who did an incredible job with his Dojo Bootstrap, http://dojobootstrap.com. Our example is a combo box that we are building to replace the standard Bootstrap combo box. In part one, we built a widget that looks like a combo box but did not have a drop down menu associated with it to allow the user to make a select

The iPhora Journey - Part 3 - Creating an Integrated UI Framework

The iPhora Journey - Part 1 - Reimagining Domino The iPhora Journey - Part 2 - Domino, the Little Engine that Could The iPhora Journey - Part 3 - Creating an Integrated UI Framework There are many ways to create the user interface (UI) for a web application. The HTML page could be created on the server and then pushed out. It could be static with the data generated on the page by the server with JavaScript, providing a more dynamic experience, or the server could generate new HTML content to update portions of the web page. XPages or PHP are good examples of this. Another method is to have the web page partially generated by the server and have JavaScript build the rest of the HTML by pulling data from the server via an API. This is the approach used in the Single Page Application (SPA) model. In all cases, it is still dependent on the web server technology being using.  As mentioned previously in this blog, XPages is dependent on complete integration between form and document, which e