ColdFusion .Net Integration

Raymond Camden of roundpeg, a web development company, offers some notes on ColdFusion .NET integration issues.

3 Responses to “ColdFusion .Net Integration”

  1. vitallis Says:

    “ColdFusion .Net Integration” describes how Java can interact with .NET using mediators (COM, messaging, etc.). In this idea nothing new and this is not integration. I mean “integration” when Java can start .NET Module like JNI DLL or .NET application can embed Java module directly (like it can be done in C++ with JNI).
    See how to integrate Java code with .NET modules at[id]95126[sekid]0[SiteID][id]98653[SiteID][id]98493[sekid]0[SiteID]

  2. Wayne Citrin Says:

    Vitaly –

    That’s a rather narrow view of Java/.NET integration that you have. Your pure JNI-related approach is one way, but it’s not the only one by any means. In fact, I think if you stick with pure JNI (or even an object-oriented version), you’ll run into a bunch of complications involving conversion of primitives, strings, and arrays, passing of exceptions across the platform boundary, and object lifecycle management. I’d say that, to make Java/.NET interop at all usable, you need some sort of mediating layer.

    If your architecture allows you to run your Java and .NET in the same process on the same machine, then definitely consider building your interop solution on top of JNI, but be aware that if the Java and .NET need to be in different processes or on different machines then JNI isn’t an option, and in either case you’ll need to have some intermediate layer.


  3. Vitaly Says:

    Forget about .NET. What do you do while integrating with some C++ module? You write JNI code to solve the integration task. My JNI SDK for .NET (written as very small DLL of 140K in mixed C++ and without P/Invoke) does the same but in any .NET language: MCpp, VB, C#, J#. So if integrated modules run in the same OS you can use Java-Java interoperability or .NET-.NET interoperability and need not to invent the wheel.

Leave a Reply