ColdFusion .Net Integration
Again - forgive the haphazard nature of the notes.
.Net Integration Session
Why? Leverage functionality available in .Net. Leverage MS products like Word, Excel, Outlook, etc.
Idea is to keep it simple. (Like rest of ColdFusion.) Right now you can talk to .Net using web services (if the .Net code is available via web services.) With Scorpio you will be able to do it directly.
How can we interact with .Net?
Web Services (available now)
Messaging
Using COM
Runtime Unification (new in Scorpio)
Runtime Unification:
Make .net components locally available. Invoke .net components directly from CFM.
Using cfobject and createObject. Works very much like cfobject/createobject for Java
<cfobject type=".net" class="xxx" assembly="foo.dll" name="something">
<cfset foo = something.method>
Web Services versus RU:
Loose coupling versus tight coupling.
Coarse granular and less programmatic control versus fine granular and more programmatic control.
Low on performance/realiability versus better performance/reliability.
Stateless versus Stateful.
Web services more useful for external clients where RU is better for internal clients.
Features:
Seamless (no configuration)
Location independent (components can be remote or local)
Platform independent (CF can be on any platform calling .Net on a Windows platform)
Hot deployment of assemblies.
Can talk to multiple .net servers.
Secure
Automatic conversion from/to basic CF datatypes and .Net datatypes.
Syntax:
cfobject: class, name, assembly, protocol, secure, server, port
For assembly, can be a list of exe's or dlls or proxy jars. mscorlib.dll always included.
For protocol, binary is default with best performance. HTTP can be used across the net.
For constructors, you manually call init() after the cfobject call.
For static methods, no need to call init.
Example shows getting running processes via .Net. Next example is creating Word docs via ColdFusion.
For datatypes - decimal type not supported. You can use JavaCast on the CF side. JavaCast updated to support byte, short, and char. They have a full mapping of .Net to Java conversions. (Too much to type.)
A proxy is used to handle communication. This means that if you are on a non-Windows machine, must use a command line tool to create the proxies. Proxies generated for .Net 1.x can be used for 2.0 as well. Proxies generated for 2.0 can only be used for 2.0.
Deploment scenario: .net and cf on same machine - no configuration - simplest.
CF and .Net on 2 different machines. The ".Net Side Agent" needs to be installed on other machine and you have to register the assemblies that CF will have access too.
CF on non-Windows machine. .Net side agent needs to be installed on the .Net machine. Generate proxy. This is done on .Net machine and you copy the generated JAR to the CF machine.
Limitations:
Enum and Decimal data type not supported.
Methods with out parameters as arguments.
Methods with pointers as arguments or return type.
.Net UI components
Callbacks
Comments
* Equal adoption of J2EE and .Net in marketplace.
* In CF7 - use Webservices to communicate with .net components.
* MSIL - intermediate lang. like class file in Java
* CLR is JVM - memory, threads, etc.
* Assembly - Packaged form of class files - .dll or exe
* Clobal assembly cache - All apps running on machine can access assembly cache
* CF interop strategies
o Web Services - Communicate using Soap XML packets
o Messaging - JMS< MQSeries - Event Gateways
o COM - Create COM wrapper to .net assemply. Create Java proxy and invke from CF. Complex.
o Runtime Unification (Scorpio) - Make .net components locally available. Invoke .net components from CFML. cfobject type=".net" class="" assembly="" name="" />. Provides tight coupling, granular control, performance, stateful, for use in internal enterprises.
o Location independent, platform independent, hot deployment
* mscorlib.dll assembly will always be included
* assembly - list of dll/exes and/or proxy jars.
* protocol - binary (default, better perf.) or http (can be used across firewall)
* constructors - use init and pass constructor args
* static method - no need to init() to call static method
* Call methods on object just like any other
* accessing public fields
* Used to generate Word doc
* Automatic conversion of primitive .net datatypes to cf java datatypes to .net
* use javacast if required
* datatype mapping
Is their .NET integration something they're pulling off in a similar fashion as New Atlanta does (they recompiled their Java app server using J#)? Or is Adobe using their existing Java-based engine and adding extensions to talk to .NET?
In other words... will they have separate ColdFusion/Java and ColdFusion/.NET products, or one product that does both?
Could I create a page that does something like:
<cfobject type="java" name="jObj" ...>
<cfobject type=".net" name="nObj" ...>
<cfset myValue = jObj.getSomething() + nObj.getSomething()>
The .NET section of our company have already created a plethora of classes and inside these classes they are referencing the connectionString thus:
string connectionString = ConfigurationManager.AppSettings["sqlDatabaseServer"];
This, I am told, is the standard way that .NET works, by putting the string into the web.config file. This would seem to be akin to putting the datasource inside the Application.cfc.
So I suppose my question is twofold.
1. Is it possible to use a connectionString that isn’t hardcoded into the class
2. If so, do we have to somehow instantiate the web.config from ColdFusion first.
Thanks
Yes, you can use a Connection String in a configuration file with the Cold Fusion 8 java bridge. But it won't be a "web.config" because the bridge doesn't run in a ASP.NET process. If your machine is set up like mine is (I just ran the Cold Fusion 8 installer with all the defaults), it is hosted by a service process.
On my machine, the config file for that process is C:\ColdFusion8\jnbridge\JNBDotNetSide.exe.config. If you add the appSettings collection plus the add statement for the appSetting you are using with the connection string, I believe that will work.
What might be preferable (and I know will work because I tested it) is to follow the convention of using the connectionStrings collection instead of appSettings. In the config file, it looks something like this...
<connectionStrings>
<add name="SPIRE" connectionString="Password=xxxxxx;User ID=xxxxx;Data Source=SPRTEST"></add>
</connectionStrings>
With C# code, you access the connection string like this...
String cnn=ConfigurationManager.ConnectionStrings["SPIRE"].ToString();
As you may know, this statment requires 1) a "using" statement for the System.Configuration namespace and 2) that your assembly references System.Configuration.dll.
Best of luck,
Rich Laird