EnterpriseServices config file

[dsmalley]

I have what may be a wrong-headed question, but I can't quite seem to find an answer in the examples.

I want to write a component and expose it as a serviced component under Enterprise Services. I have worked through the example for Spring Calculator, but here is my question:

I want my component to do some database work. This implies I need to configure it with a DB provider, etc. Of course I've done all this before, in, for example, an object exposed as a web service, where I used Web.config.

A Serviced component lives in the COM+ container. A command-line program can register my component using ServicedComponentExporter (and EnterpriseServicesExporter for the application), but after that, the command-line program doesn't get run again.

So does the EnterpriseServicesExporter auto-magically bind my application context info into the assembly it generates, along with the "plumbing" to load it? It seems it would have to, since the application can be started and stopped from the COM+ services panel.

On a related note, if I didn't want to use the EnterpriseServicesExporter, i.e., write a "standard" ServicedComponent, but still use Spring within it, for example, for data access, would I have to either bind my context xml into the assembly and manually load it, or try and use an application.manifest, application.config, and set an application root directory to get a config file for my COM+ application?

Sorry if this seems obtuse,

Dave

[steinard]

Hi!

First of all, I'm not very experienced in com+. Most of our middleware services are MTS or serviced components. These days we are porting the components to remoting, although I have some experience in Spring.Net, my com+ colleagues have no experience in Spring.Net. In late 2006 and early 2007 I did set up a com+ component with Spring.Net and NHibernate, but after some months we went for remoting instead. The calculator example is a perfect com+ example because it is stateless and does not need to set up a lot of resources (like initiating the IoC container). Because it is too simple and does not take into account the problems that most developers encounter when they try to set up a com+ component with Spring.Net, it is not very useful. The only usefulness I can see is the demonstration of the serviced component exporter.

Maybe I did something wrong or maybe it is possible to set up a com+ service that is always running and has the dependency injected objects in the IoC container alive and accessible when entering the middleware. Only if this is possible would I go for a com+ solution again. The main reason is that we use NHibernate. NHibernate must be set up (this is done once by a win-service that wires the server side together and exposes configured remoting services, but with com+ I noticed that each com+ instance had to do the setup job itself. This took a lot of time and was not very efficient). Also, all NHibernate caching strategies couldn't be shared, anyway, I'm sure there might be ways around this.

The simplest way around this, is to create a win-service that sets up everything and exposes remoting services that the serviced component (being stateless and live for a short time) simply forward calls to. This is how I would solve this in the future if I ever need a serviced component, instead of making the serviced component set up and wire my middleware together, I would make it as thin and dumb as the calculator example.

I think I have some old threads describing how I did set it up, I do remember that I had to specify application.manifest, application.config and the application root directory. All this is described in the old posts, I just did a search but I could not find them. Anyway, I also have the old config files and will attach them to this post. The attached config files may be a little outdated, but should give you a pricture of what you need to do to get this working.

I hope this helps,
Steinar.

[dsmalley]

Thank you very much for the sample files. I wouldn't say all is clear yet for me, except thst it appears a Spring.NET EnterpriseServices component isn't a good fit for me.

Looking again at the Calculator example, I noticed that a (commented out) example of setting a property on the calculator component is done via a product template when a client side reference is instantiated. What I had been intending to do was have a COM+ object which would keep state and do some heavy lifting database querying. It would actually be accessed via a web service, so I would have been creating the remote reference there, not in the end client.

Now it took me awhile to realize something about web services in Spring.NET (meaning exposing PONO's as web services with the exporter). Taking calculator as an example, the service object is in fact a singleton which lives for the life of the web service appdomain, and it is the proxy generated by the exporter which is stateless and lives only for the duration of the request. Maybe this has always been obvious to other people, but it wasn't to me.

The analogy in web services written without Spring.NET would be crerating the service object in Application.Start() and disposing it in Application.Stop(). So in other words, this service object is long-lived, lasting hours or maybe even days (until IIS is restarted or the app pool is recycled). It can therefore be very stateful (except of course this state would be global to all callers).

What I am doing is having an object collect and cache a lot of information from multiple databases, and returning the current cached data when a client calls. The cache is updated on its own schedule, on multiple threads, etc.

Now if I followed the paradigm of getting an unconfigured objct from COM+ into the web service, configuring and then running it there, the call to COM+ becomes not much more than a glorified new(), I guess with location transparency. In my case, doesn't buy me anything.

If I try and make the COM+ object the "real" object, I need to do things like set the application root, load the context myself, and then additionally try and coerce that COM+ object into being a long-lived singleton. That just kicks against the stateless paradigm of COM+.

So I conclude in my case, I might as well let this object live in the web service application context, or, if I really want it outside the web container, make it something like a Windows service.

Too bad; I like playing with new things.


Dave

[Erich Eichinger]

Hi,

Sorry that it took a while. But finally I found & just committed the solution. Please get it with the next nightly build and check out the updated Spring.Calculator example.

Exported COM+ components now use ContextRegistry to create an ApplicationContext at component startup and obtain the actual service instances from the context. This means that you don't have to care about instantiating the ApplicationContext yourself now (and of course it is only instantiated once).

Note, that you must set the property EnterpriseServicesExporter.UseSpring=true explicitly as this is not the default yet for preserving backwards compatibility.

cheers,
Erich