Bala's Oracle Fusion Middleware Blog

I remember those days when Enterprise Java Bean (EJB) was a big buzz and every project want to use them. They used so much that the projects and applications that didn't demand an use for enterprise level services started implementing them. I felt like that was another 'Gold Rush' people didn't want to miss. After a while everyone started realizing that EJBs are not for everyone. Also EJBs could only be accessed remotely when they originally released in EJB 1.0. But application server vendors provided their value addition by optimizing the local access to an EJB by by-passing RMI. This gave a hint to the standards committee and they included this as a feature - Local Interfaces in the later EJB Specification 2.0. So in short Best Practices started to emerge and now you can say the usage of EJBs in IT projects got streamlined.

You could be wondering why am I taking about EJBs when the title of this blog reads 'Local Proxy & Federated Portals'. Now coming to the portal paradigm, Web Services Remote Portlet is a specification from OASIS Technical Committees which defines a web service interface for interacting with presentation oriented web services. The portal application that provides their presentation oriented services for consumption by other portal servers is called as a Producer and the later is called as a Consumer. Typically, a consumer application does not include the business logic, data, or user interface parts of the portlet: instead it simply collects the user interface markup delivered from producers and presents that user interface to users. One can use interceptors to programmaticaly customize the data on the receiver end as well.

As WSRP is a web services protocol, communication between the producer and consumer happens over SOAP. This communication involves serialization and deserialization and also intermediate buffers. This is the case even when the producer and consumer are located on the same server (runtime). Oracle WebLogic Portal 10 includes a new feature Local Proxy Mode. You can enable local proxy support by setting to true in WEB-INF/wsrp-producer-registry.xml in the consumer web application which will optimize the communication by avoiding network I/O. If the consumer finds the producer deployed on the same server then it will avoid the SOAP over HTTP and will use the local proxy. This saves the overhead from serialization and deserialization of SOAP. Internally WebLogic Portal will use the same execute thread to invoke the producer using servlet API. When local proxy mode is enabled the remote proxy can also be used by remote consumers. Java portlets or third-party portlets deployed on the same server can be integrated without requiring any modifications. This reminded me of the local interface with EJBs which evolved when people started realizing that they are consuming EJBs more locally than remotely.

You can find more information on WSRP here - http://e-docs.bea.com/wlp/docs100/federation/Chap-Details.html#wp1021292.
For information on local proxy mode see here - http://e-docs.bea.com/wlp/docs100/federation/Chap-Best_Practices.html#wp1010714.

I always wonder how companies manage to keep user information in sync with their many IT resources. Whenever a new employee or contractor joins a company, his/her information must be inserted into all the systems such as Network, Email, Packaged Applications such as Expenses, Human Resources, Travel, Procurement etc. The above mentioned systems a small subset of what companies might use. The system might have been either purchased or home grown. There needs to be a central place from where we should be able to insert the user information or provision the user information into all these systems. Creating a bunch of request to different administrator and having them individually deal with their system can be a logical approach. But keeping track of all the individual requests associated with the main request to provision the user to all the IT system and getting approvals when needed demands for an automated way in which this should be done. The same applies when an employee or contractor leaves the company. Their information should be de-provisioned or removed from all the systems. According to Gartner, the time IT spend in creating or removing user information constitutes around 10% where as dynamically modifying user privileges with resources constitutes the rest of 90%.

Oracle Identity Manager (OIM) is a key product in the Oracle Identity & Access Management Suite which is a part of Oracle's Fusion Middleware products. After knowing what OIM does, my mysteries were solved about Identity Management. OIM not only ease the provisioning of user across various systems but also helps companies to keep auditing information for compliance purpose. With growing privacy concern, meeting the regulatory and the privacy requirements are mandatory for many business such as Finance, Health care etc. OIM is a hot pluggable product built on J2EE which maintains a repository which can be synced with other systems such as corporate directories, operating systems, database etc. With OIM, user information can be provisioned, de-provisioned, passwords can be managed across systems. These tasks can either be automated with no manual intervention of can be assigned with approval work flows that provides control for managers and power users.

For auditing and compliance reasons reports can be generated on access control and user information such as who has access to what and when etc. Also to ensure that only appropriate users have accessed information in enterprise OIM support a process called Attestation. Companies used to maintain mountains of documentation, reports in the form of paper files to keep track of security information in the past which is now eliminated to these niche Identity Management products.

For more information on OIM visit Oracle's product page here. I shall write more about OIM and the other products in Oracle Identity & Access Management Suite in the coming days.