A Windows service is simply a process that normally runs outside the context of a user so it won't help you at all. Web services really won't help either as they would require that you run a web server and invoke web service methods whenever something of importance happens.
For cross-process calls between a managed and unmanaged application your only real choice is a COM server. The object model would need to reside in an outproc COM server that both applications communicate with. The object model could remain in .NET but you'd need to expose a COM interface. Through the interface you can expose COM events that are raised when important events occur. Complicated but not undoable. There are probably some other alternatives (like MSMQ or something) but most other solutions will not allow for event-style notifications.
If both apps are in managed code then remoting would work as well. One of the applications creates and manages the objects while the other application uses standard .NET logic to listen for events. I'm not 100% sure how events work over remoting so there might be some issues with it. Before you brush off this option as not applicable keep in mind that you can create a C++/CLI library that communicates between the managed class library and the unmanaged code. In this case the unmanaged code relies on the C++/CLI class(es) to handle the notification process. As far as the unmanaged app is concerned it is a C++ class. The C++/CLI class uses remoting or whatever to talk to the managed class library.
Just for completeness I'll also through out the option of using an intermediary system like MSMQ or SQL to actually house the data. In this case both applications use their own libraries to read and write the data. Using SQL 2005 notification infrastructure you can set up notifications for when the data changes. In this particular case you are emulating data sharing when in reality both processes have their own copy of the data so some disconnection will occur.
Michael Taylor - 12/1/06