I just received a question from a fellow sales consultant in Vietnam. He asks...
"In my demonstration, all of our customers asked me the same questions when I delivered the IRM demo: how can distribute the IRM server in multiple provices in Vietnam? Vietnam internet connection is very bad, therefore all distributed locations in Vietnam could not share the same central IRM server, then they are expected to deploy one central IRM Server on internet, and few other IRM servers on intranets of each location thru out Vietnam.
The requirement is how to synchronize all IRM data (security configuration, roles, rights...) between these IRM servers, so that when I assign for you a document in Hanoi IRM server, then I travel to Hochinhminh I can open the document with Hochiminh IRM server"
There are a number of ways to resolve this issue and not knowing the specifics of the infrastructure for these customers i'll outline all possible ways to solve the problem.
Oracle IRM is already very network resilient
Firstly, Oracle IRM is by design very resilient to network performance. When the technology was first developed back in the late 90's it was very common for mobile workers to be using 14.4 and 28.8 modems. Network bandwidth and reliability was very poor in comparison to today's standards. Therefore Oracle IRM had some vital features which were essential in those early days and are unique to the Oracle IRM technology.- Network protocol was a cut down version of SSL designed for speed and low bandwidth use. It is also tunneled inside HTTP which gives it a stateless aspect that forces a system design which is efficient with network communication.
- As long as you are not assigning large amounts of rights to each user, the size of data to be transferred from server to client is small. Again due to the bandwidth limitations around when the system was initially designed, Oracle IRM is very efficient with the data that is sent server to client and back. For example as you access sealed content offline the client audits this activity. These logs are returned to the server in batches to conserve available network bandwidth.
- Offline caching has been in the core design of the system from day 1. This enables trusted users to travel with sensitive information without requiring to constantly connect with the network to validate rights. This of course needs to be balanced with the increased risk of extending that offline period, but in cases like this, just being able to deploy IRM brings a huge increase in security. This offline period can be taken to an extreme, some customers have given users a whole year of offline use. So they only need to access the IRM server once in an entire year! Of course this dramatically reduces the effectiveness of the security, but its demonstrative of the flexibility of the system.
Apart from taking advantage of the inbuilt functionality, it is possible to build a system which allows for a more balanced security approach. This does involve a little more work and complexity and requires good system design to avoid instability as more components are involved.
Multiple Oracle IRM servers can talk to one database
It would be possible to deploy multiple IRM server instances in each province. Then using localized DNS resolution (remember each piece of content has a fixed DNS hostname pointing to the home IRM server) you can have rights requests be served from a local servers. The IRM server by default is set to cache data in memory which mitigates some of the connectivity issues from the server instance back to the centralized database.There are issues here. You need to figure out a smart way to do geographical DNS resolving which is hard if the end user is using public DNS servers and not ones on your own network. Also you might find that the connectivity from server to database also shares exactly the same issue you are trying to design around, that of a very poor network connection.
Using Oracle database in a distributed manner
The ultimate solution of course would be to have an Oracle IRM server with its own distributed copy of an Oracle database running in each location. Oracle database has some very powerful capabilities which allow it to clone schema's to remote databases. A good example of this in action is how Google achieves its super-fast response time by cloning the Oracle database server in many locations across the world.This, whilst possible, is going to require some clever consulting to setup. Latency of changes to data needs to be taken into consideration across the entire system and also allowing those remote IRM and database systems to update information back to the "master" server. There is also still the issue of ensuring DNS points users to the right local server.
With 10g this would be a challenge, but he imminent release of 11g opens up the ability for the system architect to insert all sorts of logic right into the Oracle IRM server which would facilitate a design such as the one above. Of course when it comes to resolving distributed database issues then Oracle is already the master of that problem :)
Using the Oracle IRM API to manage the distribution of rights
Another, more complex system could be built on the extensive API's available. The central IRM server would contain the master copy of rights and classifications which could then be "copied" using logic contained in an application that would utlilize the IRM API to update the intranet IRM servers.Considerations also need to be taken about how to handle the audit logs from the separate IRM servers. These can be written to binary files, which are transferred back to a central location for processing into a complete audit of all activity. The Oracle IRM server also allows for these events to be placed onto a message queue which would provide a quicker method for amalgamating the records.
