Is it possible to use .NET to implement JChem?

Hello,





Is it possible to use .NET to implement JChem?


I think it is possible if we use cartridge, but would like to know if there are any other way.





Thanks,

There are basically two possible approaches to access JChem's Java API from .NET:





1.) This involves implementing a server in Java providing the required JChem functionality through a remoting mechanism supported by .NET. Of the remoting mechanisms readily available for a Java implementation, .NET directly supports Web Services. "Third party" products exist that can be used to access a Java server from a .NET client through more flexible and faster RPC-like remoting mechanism such as RMI or CORBA.





This approach involves a substantial amount of extra work in Java which consists of (a) creating "wrapper" Java interfaces for the JChem API so as to conform to the rules/constraints of the selected remoting mechanism; (b) implementing in Java the bridge between the wrapper interfaces and the corresponding JChem API and (c) publishing the wrapper interfaces for remote access using mechanism-specific tools. This extra work pays off only, if the implemented interfaces can be reused for purposes beyond the mere interoperability with .NET. For example, since they are intended to be a highly interoperable architecture, Web Services promise such extra benefits. Axis (http://ws.apache.org/axis) from the Apache consortium makes it very easy to create and deploy Web Service implementations based on Java interfaces (step (c) above) while .NET includes tooling to generate .NET stubs based on Web Service descriptions (WSDL).





A special case of remoting is to use a messaging service (such as Tibco or MQSeries) as highest common denominator. Messaging services are supported both by .NET and J2EE, but are, by nature, probably too heavy for the purposes of JChem.





2.) Using a native .NET/Java bridge. Such bridges typically consist of native libraries implementing a basic bridging logic as well as tools for generating .NET interfaces/classes which map to the target Java classes. This approach involves much less extra work than the first one (due mainly to the fact that it requires much less (if any) "refactoring" of the Java API) and the resulting runtime system is also significantly faster. The most widely known native bridge is probably jnbridge (http://www.jnbridge.com/index.htm).





An alternative (still in experimental phase) to the above approaches is: http://www.ikvm.net . This is a basically Java 1.4 compatible Java virtual machine implemented in .NET with various tools including enablers for .NET-to-Java calls.

As pkovacs said, using 3rd party Java <-> .NET middleware is much easier and more efficient.





J-Integra for Espresso is a another middleware which developed entirely as managed code and can therefore be accessed by all .NET languages (C#, ASP.NET, etc...). It's Bi-directional and up to 20x faster than Web services.





J-Integra for Espresso also includes plugins for Visual Studio.NET 2003 AND Visual Studio.NET 2005, which enables developers to incorporate J-Integra for Espresso into their .NET client applications while working entirely within the Visual Studio environment.





Please refer the following examples to see how easy the Java <-> .NET bridging can be done.





A simple "Hello" example


http://j-integra.intrinsyc.com/support/espresso/doc/index.htm#DemoJava/Hello/Hello.html





Callbacks from Java to .NET


http://j-integra.intrinsyc.com/support/espresso/doc/index.htm#DemoJava/Callback/CallBack.html





For more information about Java <-> .NET interoperability, please see the following online documentation:


http://j-integra.intrinsyc.com/products/java_net.asp





Cheers,





Hao Zhang





J-Integra Interoperability Solutions


http://j-integra.intrinsyc.com/


high performance interop middleware for java, corba, com & .net

A user is asking:

Quote:

I read with interest your posts to fujiki concerning implementation of JCHEM in .NET using a .NET/Java bridge; however, I'm not sure if I really need such an intimate degree of interoperability for my application. I have a database in Oracle 10g running on Windows Server 2003, storing text documents which are accessed through an ASP .NET interface. Each document has chemical structures associated with it and I would like to integrate the documents with their compounds through JCHEM Base. Since the DBMS is in Oracle I'm assuming I could call up structures from my ASP pages by sending SQL statements against the JCHEM cartridge. Structure searches would be initiated from Marvin, but the part I'm not sure about is creating the links from the structure display that would take me back to associated documents. I need to be able to be able to dynamically create a hyperlink, on the structure display page, that will send the structure's index number back to an ASP form. But can't I manipulate JCHEM's web output (that is creation of a simple hyperlink) directly through its API rather than having to go through a .NET/Java bridge? Or am I missing some essential point here (which would not surprise me in the least)

With JChem Cartridge for Oracle, you can access much of JChem's functionality from ASP.NET via your favorite database connectivity method (for example using the classes in the System.Data.OracleClient namespace). Please, consult the JChem Cartridge API to learn which SQL operator to use in order to access a given JChem function: http://www.chemaxon.com/jchem/doc/guide/cartridge/cartapi.html .





We provide an example for the integration of JChem Cartridge with an ASP application. This example is located in the examples/cartridge/asp directory of the JChem installation package. The installation instructions are in the setup.html file in the same directory. Although this example application is written using server-side Visual Basic Script, it might serve as a good starting point in learning how to integrate JChem Cartridge for Oracle with an ASP.NET application.





Actually, an ASP.NET application can be implemented much simpler than the ASP example, because ASP.NET has much less limitations than the Visual Basic Script language. For example, the absence of the Encoding classes in Visual Basic Script makes it difficult to encode/decode large Unicode strings from/to ASCII. In order to overcome the performance problems associated with VBS implementations of the encoding logic, we provided the "jc_encode_blob_into_tmp" stored procedure in the "jchem_util" JChem Cartridge package. With ASP.NET, you can simply use the classes in the System.Text.Encoding namespace instead of this stored procedure.





I suggest to try to translate the solutions in the afore mentioned JChem Cartridge example to your ASP.NET specific requirements and if any questions/problems arise in the process, do not hesitate to post them.

I'm trying to work through the ASP example, jchem\examples\cartridge\asp\setup.html specifies that a structure table needs to be created with name, stock and comments fields which should then be loaded "with the necessary test data". I can't find any sdf files under jchem\examples\ that include those fields and of course my own molecule files do not have them. Where can I find the specified test data?





Thanks,


Blaik

Hi,





No sample file is included in the package.


You are right, we should provide one in future versions, or change the example to be more general.





Until then you can use your own structure files.


These additional columns will be empty (NULL) after the import of course, but it's not a problem.





Best regards,





Szilard

Blaik,





You do not even need any data. You can use the example itself to populate the "database".





The documentation does not specify any test data, because the point is that you should be able to use it with any test data: large molfile, small molfiles, rectangular molfiles, round molfiles.





Let me explain a bit what I mean. Initially, I tested the example with SMILES which are nice small molfiles and it worked well. But...I knew that there are users out there who would want to use SDF files (and eventually large SDF-files), so I tested with this kind of files and it turned out that performance was bad. That is why I had to hack those stored procedures into the jchem_util package I wrote about in my previous posting. So if I left the example in its initial form and provided SMILES test data, you could have asked it again: where are the sdf files specified? Not everyone wants to see the example work with SMILES and not everyone wants to see the example work with sdf files. (And what is more: not everyone wants to use the example with jchem tables as I suspect you do. Some users will also want it to use regular tables.)





So there is a reason why the example does not want to dictate you exactly what kind of data you have to use. The only thing it dictates (or "specifies" if you wish) is the structure of the data (name, stock, comments). I suspect that if we made the example generic enough for you to specify the structure of the data, the code of the example would become so overwhelmingly complex that it would lose its main purpose which is (this is at least what I infer from the kind this ASP application is said to be: "example") to show you how you can use elements of the JChem Cartridge and Marvin for a self-contained ASP application.





Regards,





Peter

jchem\examples\cartridge\asp\setup.html specifies in step #6





"Review the constants in <JChem's URL>/examples/asp/index.asp"





but the constants are actually in init.asp right?





step # 7 directs


"Copy the file adovbs.inc from C:\Program Files\Common Files\System\ado\ to <JChem's URL>/examples/asp/index.asp"





Does that mean


copy adovbs.inc to the same folder as index.asp or


paste the contents of adovbs.inc into index.asp or


add an include directive to index.asp like <!--#INCLUDE FILE="adovbs.inc"--> ?

You have found the two bugs in the documentation of the ASP example. Please, refer to the documentation available on the chemaxon website. The bugs are corrected there (and will be corrected in the next JChem release). Sorry for the inconvenience.

Quote:

"Review the constants in <JChem's URL>/examples/asp/index.asp" but the constants are actually in init.asp right?

Yes. Check the constants in init.asp and change them if necessary.

Quote:

step # 7 directs "Copy the file adovbs.inc from C:\Program Files\Common Files\System\ado\ to <JChem's URL>/examples/asp/index.asp"

Copy adovbs.inc to the same folder as index.asp. ("Copy the file adovbs.inc from C:\Program Files\Common Files\System\ado\ to <JChem's URL>/examples/asp")

I have started working on trying to port your examples/asp/cartridge ASP example files to ASP.NET. Referring to the createTemporaryBlob function in init.asp: I'm guessing from the references to ASCII and unicode that the contents being stored in the blob field are straight text so could it be stored/handled as a CLOB instead?





When searching.asp calls createTemporaryBlob and passes it molfile I assume the molfile argument is coming from a Marvin generated query out of query.asp. Is an actual .mol file written to disk or passed directly as a filestream? I can't quite see how query.asp passes the query value to index.asp except that it must occur in submitIfLoaded. Any background you could provide on the process flow from query submission to structure search to hit presentation would be greatly appreciated.

Quote:

Referring to the createTemporaryBlob function in init.asp: I'm guessing from the references to ASCII and unicode that the contents being stored in the blob field are straight text so could it be stored/handled as a CLOB instead?

The JChem Cartridge operators using BLOB parameters expect ASCII encoded structures (basically one byte for each character as opposed to the "wide characters" with Unicode encoding). The server side scripts (and probably the client side script as well) use Unicode that is why the call to jchem_util.recode appears at the end of the createTemporaryBlob function. I am far from being a .NET expert, but I think that you could remove this call and pass the createTemporaryBlob a molfile which has already been recoded to ASCII using the Encoding .NET classes. (Probably, you can make other simplifications as well in a .NET environment.) At first glance, using CLOB does not seem to be a good idea, but, after all, I am not completely sure I understand why and where you would want to use CLOB. Please, could you elaborate?

Quote:

Any background you could provide on the process flow from query submission to structure search to hit presentation would be greatly appreciated.

You guessed right: the molfile from query goes over submitIfLoaded to structure search. The search results (the primary key values of the hits from the structure table) are then stored in the hitList array which is stored in a session at the bottom of searching.asp. The hitList array is then retrieved in searchresults.asp and the attributes of one screenful of the hits are retrieved and displayed based on how the user navigates in the results.

JChem currently supports .NET through JNBridge: http://www.chemaxon.com/NET_support_land.html.