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
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
why is that? e.g. where is the workflow in connections, yammer, facebook, twitter?