Working with Centera from Java.

Question

Hi All, I have never worked with Centera before but have been asked to consider the following scenario and provide some rough estimates and a statement regarding the feasibility of attempting to build a solution of this type by the close of business (UK time) tomorrow (07th November, 2014). I therefore thought I'd sketch out the basics here in case anyone could offer any useful thoughts or advice. We build Java web services and applications primarily so would be looking to access Centera directly from our Java applications. I have seen that the Centera SDK provides a Java JNI wrapper for the main SDK functionality that is implemented in C libraries. Our development environment is standard Windows PCs with Eclipse (Java IDE), JDKs as appropriate (1.6, 1.7, 1.8 etc) and Windows builds of our JBoss Fuse Service Works deployment platform. Thus, we can build and run everything locally and the only non-local element is typically the development database. Our destination environment is based on the Red Hat Enterprise Linux (RHEL) OS along with the corresponding RHEL versions of the required JDKs and JBoss Fuse Service Works deployment platform. QUESTION 1:   Is the 'FPLibrary.jar' containing all the Java JNI wrapper code platform independent or platform specific? In other words... If we installed the appropriate Windows version of the Centera SDK on our development PCs and the appropriate Linux version of the Centera SDK on our RHEL deployment servers, would the 'FPLibrary.jar' supplied with the Windows SDK function correctly if packaged up into our WAR artifact and deployed on our RHEL deployment servers or would we need to switch out the 'FPLibrary.jar' file on a per-platform basis? One task common to numerous work-flows in our web-applications is to allow a user to upload a file which will be stored as an attachment to the main case/record they are working on. In current web-apps that simply store these file attachments in a vanilla DB, we can simply stream the data from the user's browser directly into the DB via our web-app code. Similarly, if a user wishes to view a file attachment, we would normally just stream that file's data back from the DB to the user's browser. An initial very quick overview of the Centera SDK suggests that the API functions seem to expect data to be held on the local filesystem for both reading and writing purposes. Enterprise web applications incur a good deal of additional friction when one has to consider allowing them to have access to the local file-system for reading or writing data and it has serious implications for the ease with which the application may be deployed into new or alternative environments. QUESTION 2:   Is it required that data be held in files on the local file-system when reading from or writing to Centera? In the overview presentation held at https://community.emc.com/docs/DOC-3162 the possibility of accessing and interacting with Centera via SOAP based web-service mechanisms is mentioned early on but not elaborated on later. QUESTION 3:   Does Centera provide a proper SOAP based Web-Service interface for applications to use to interact with Centera? If it does, where is this functionality documented? Is the WSDL returned by the web-service sufficiently comprehensive that we could point a relatively modern tool like SwitchYard's composite editor at it and it could generate all the required stub-code automatically? Though we have many questions, if you could provide any responses to the above questions and/or any thoughts/advice on this most sensible endeavour I would be very grateful to receive them. Many thanks in advance. Best wishes, Mark.

mfh2 · Accepted Answer

Hello Mark -

I'll take a crack at your questions.

1) Yes, the FPLibrary.jar file is portable across architectures, but not across SDK versions. Actually, this version-portability restriction may be relaxed in the 3.2/3.3 versions but I still wouldn't do it. It would be safe to bundle up the JNI defs from Windows into your WAR file.

2) You could use in-memory buffer streams rather than writing to the local filesystem, but of course this will impact your memory footprint. If I was implementing this with Centera I would probably read chunks with BlobReadPartial up to 20MB at a time to avoid having to hold an unbounded size blob in memory.

3) There is no supported SOAP (or XML-RPC, or REST) interface to Centera. We did a prototype in engineering 'back in the day' but it was just a demo and never really went anywhere.

Best of luck with your project,

Mike Horgan

Sopra-Mark-H · Answer

Many thanks Mike - that information will help me immensely with my 'rough estimate' task today. Thanks for responding so promptly to my questions - it is much appreciated. Best wishes, Mark.

Centera

Was this post helpful?