It’s been out for a little over a year, but I wanted to throw a quick post out about RIDC as I’ve recently started using it and I’m really very, very pleased with my experiences. RIDC stands for Remote IntraDoc Client and it’s an API used in remote Java applications to connect to UCM. It’s effectively a replacement for CIS(Content Integration Suite) and in a strange bit of computer irony it’s better because it smaller and does a lot less.
Where’s the Document Object?
The problem with CIS was that as a design it was, forgive me, a little weird. It’s not that it didn’t work, it actually worked pretty well in most situations, but there were a couple of oddities.
- It has what you might call and easy-to-use command pattern that hid underyling service calls from the application. So for instance you would call if you wanted to make a DOC_INFO service call, you’d call the getDocumentInformationAPI method. Not the end of the world, but also not really an intuative API for UCM. I think the reason was that this pattern fit much better in Java web app and so it was designed a little more for that rather than as just a standard Java API.
- Because you’re working with strict objects, it makes it sort of tough to call new services, like Site Studio ones, directly. There is a work around, which involves using what’s called the administrative API(sort of the base API for the whole thing). Typically I’ve just used this for all my calls,(and incidentally it would then look a lot like RIDC code), but looking at all of CIS, it just seems like you needed a lot of different classes to do really the same thing, make service calls.
- If you crack open the CIS jar, you’ll find that there’s a slightly loco version of Spring in there(based on 1.5 I think) along with a modified classloader. I’ve only run in to issues in one location(you know who you are), but with all that extra code in there, I’ve always been hesitant to use it with other Spring versions for fear of class conflicts.
- Inside of UCM there’s already a Java API called the jspserver.jar. It’s about 5-6 classes total, allows you to call any service, uses objects that look and acts very much like normal Content Server objects. I’ve based all my remote API’s on it(.NET and ActionScript)..it was such a simple and elegant design, I always wondered why the CIS people never talked to the jspserver people. Well that’s pretty much what RIDC is.
And here’s some code.
Since code samples always make for exciting reading, lets jump right in with some examples.
Here’s the example included in the CIS developer manual for how to make a DOC_INFO call.
//get the active API
SCSActiveAPI activeAPI = m_cisApplication.getUCPMAPI().getActiveAPI();
//create a document object
ISCSDocumentID documentID = (ISCSDocumentID) m_cisApplication.getUCPMAPI().createObject(ISCSDocumentID.class);
//set the dID
//make the call, get the doc response
ISCSDocumentInformationResponse docResponse = activeAPI.getDocumentInformationAPI ().getDocumentInformationByID(m_context, documentID);
//and there's the content
ISCSContent content = docResponse.getDocNode();
What do you think? Granted I copied the CIS example out of the doc and it’s not a prefect one-to-one comparison to the RDIC one I’m about to show you(designed for a web environment where the connection is already established), but doesn’t that seem like a lot of casting and nested objects? I know I’m complaining about code looking too complicated, but seriously try to explain that to someone. It really just doesn’t even look like UCM.
Take a look at the same call with RIDC…..way simpler, and I think if you understand UCM at all, it follows a rather intuitive flow. If you’ve done any Java component development, you’re learning curve should be near nil.
//create the client manager
IdcClientManager idcClientManager = new IdcClientManager();
//and then create a client to the content server
IntradocClient client = (IntradocClient)idcClientManager.createClient("idc://localhost:4444");
//create a binder object
DataBinder binder = client.createBinder();
//add our service values
//and make the call...too easy.
ServiceResponse response = client.sendRequest(new IdcContext("sysadmin"), binder);
Binders, putLocal methods and clients…everything you’d expect in a remote API. You can call any service; custom ones and new ones added via components like Site Studio and other Oracle add-ons are all there. I haven’t opened up RDIC yet, but check out how much smaller the new API is vs it’s older sibling.
I’m not going to rush out and re-factor all of my CIS-based applications, I can solidly say I’ve moved on for future projects. I have a couple of portal examples forthcoming and hope to have some RIDC in there, so check back soon.