Compound Registration Integration Options

I am investigating the possible use of the Compound Registration system, and have a few questions about integration options available.

(1)  My understanding is that it must run as a stand-alone web application with its own database, is that correct?

(2) It appears that web services are the preferred means for full integration, but is there a native Java API as well?

(3) What kinds of data sources can the server poller web service access to retrieve compounds for registration?

Thanks!

Hi Jason! Thanks for your questions.

(1) Yes, that's right.

(2) This is also true. We offer a WS API for integration. There's no public Java API at the moment. We do use internally a Java API in our continuous integration tests, but it's not offered as a publicly available API.

(3) Theoretically any data source can be used that is supported by JDBC, but it's been tested with Oracle and MySQL DBs only.

Thanks for the information!  I have a few more questions about using the compound registration web services, let me know if this is this is still the appropriate forum or if the general web services one would be more suitable.

Do the webservices expose all of the functionality that we can see in the demonstration site and web client? Could I write my own user interface that provided the same features/functionality as the compound registration web client ?

Is more documentation available for programatically working with the compound registration system via web services? For example, something defining the general concepts of how to work with sessions & user management and working with specific features of the system?

Yes, this is the right forum. The general JChem Web Services is not really related to Compound Registration itself, it exposes a set of basic chemistry-aware functions, but nothing specific that is used during the registration process.

Everything that is performed on the web client application is either (a) implemented on the server side and exposed through web services to the client user interface, or (b) implemented partly within the client-side JavaScript code with the aid of the WS API. The main areas of the business logic are certainly implemented on the server side, the latter ones mostly include user interface changes and data pre-processing based on previous WS responses. You can implement your own UI for the system, but in that case you have to take care of certain convenience features currently provided by our web client (e.g. the adaptive change of the match action buttons based on the type of the structure match, etc).

Regarding the developer documentation, right now we can offer a JavaDoc of the WS API. Most of the concepts (e.g. user and role management) and also the workflows are covered in the User's guide, and the possible configuration options in the Configuration guide. Parts of the web client JS code can serve as examples, best practices about the use of our WS API. We do not provide a dedicated Devaloper's guide at the moment, and some of the mentioned areas (e.g. authentication) are under heavy refactoring right now. Please let us know if you need any specific information, we're happy to have a presentation about the concepts, workflows and best practices for you.

thanks