My initial advice would be to investigate COM-Java integration options,
similar to your item 1). Basically, you want to be able to access
Java objects from .NET, so having Java objects appear as COM objects gets
you a long way towards this.
In my opinion, you sould absolutely minimize the amount of code you
are writing to glue COM and Java together (this would pretty much eliminate
CORBA or sockets as viable options), as this introduces a large amount
of complexity and risk (you'd almost be writing an app server) and you
would rather focus (I assume on your application's core functionality).
There are tools that will generate the Java-COM mappings for you automatically.
Once you generate the mappings, you have a set of COM "proxies" for the
Java classes you can use as you would any other COM component, including
managing them from MTS. You don't need to hand code any of this,
so it is much more maintainable. As you indicate, there may be scalability
issues with this, but the actual characteristics will depend on how you
implement things and your applications requirements. (For example,
if your interactions with Jess are not stateful, you can probably get NTS
to some object pooling for you.)
A Java - COM tool I have used is called J-Integra. Check it out here:
http://www.intrinsyc.com/products/bridging/jintegra.html
It is a bi-directional Java-COM bridge that lets you access Java from
COM or vice versa using COM or DCOM. I used J-Integra to let a Java application
interact with an MS Exchange server through Exchange's COM interface
(CDO). There are also other tools out there. I think another
one is available from IBM alphaworks.
Another option for you, if the performance of the above architecture is not acceptable, would be to investigate tools that can generate a Win32 DLL from Java code. I know Visual Cafe does this as an option. I believe MS Visual J++ also had this option (or perhaps it was just generating COM wrappers for Java code...I don't remember).
Regarding implementing web services in Java, as a previous poster indicates, this is not especially expensive or complex, but certainly complicates your environment if you use a Java app server and also assumes a higher level of expertise with Java. The Java-COM bridge option has much less of an impact on your overall .NET architecture because you don't need any special run-time infrastrcture (besides maybe a JVM) to run the components.
Good luck!
Shea.
Randy wrote:
I'm building a comercial consumer-oriented web site using Microsoft's new .NET infrastructure and I am attempting to use Jess as a back-end service behind the web application. The issue I'm facing is how to bridge the Win32<->Java gap while trying to minimize the Java-architecture-learning-curve and $ expense. It also needs to be architected so that I can achieve scaleability in the future. I've spent a week researching this (including the archive of this list), and before I get down to serious coding, I wanted to run my analysis by this group to make sure I'm on the right track.I don't want to go back to CLIPS, because it doesn't use the Rete algorithim, and doesn't seem to be being maintained much and I'm not willing to write the whole app in Java. I could use a comercial product such Haley, however besides the cost, they don't seem to have fuzzy rule support which I would like to use in the future.The basic architecture that I think scaleability requires is to have a Jess Server capable of managing multiple Rete() engines, one for each task - each with its own thread, and possibly in the future having multiple Jess Servers clustered together. So the issue is is how to build this with minimum fuss, and how to communicate with it.So, my options I see are:1) COM Wrapper such as Sun's CAS COM. Problem here is that It doesn't seem scaleable (each instance is a seperate JVM - do I have this right?).2) Use CORBA as a trasport between Win32<->Jess Server. Problem here is CORBA support seems week on the .NET side and this seems to be alot of trouble and perhaps overkill, plus I still need an App Server. But this could just be my inexperience with CORBA talking.3) JNI - Not really a transport solution, but could be part of a solution4) Web Services (via SOAP) - this is my prefered method, however on the Java side I would have to buy lots of expensive tools (such as CapeConnect + an App Server) - Isn't there an easier way to handle SOAP in the Java side?5) Sockets - this is what I'm currently leaning toward. I'm considering building a simple Jess Server via Sockets using the App Server framework outlined in the book 'Server based Java Programming' by Neward.So, I ask this group - Is my thinking on track or am I missing something? Any experience or advice (or code) would be appreciated.Thanks in advance,Randy Bradley
