locked
Advice needed on creation of stateful unmanaged objects via .NET Remoting RRS feed

  • Question

  • Current architecture:

    l         I have several instances of a .NET 2.0 windows application (client) concurrently running on workstations

    l         These client apps connect via remoting to a Singleton Server-activated- object deployed as a Windows service.

    l         This SAO object in turn holds a native unmanaged Business Object (BO).

    l         This native BO is a singleton.

    l         The client apps execute methods on the remote server which in turn passes on the request to the BO. The BO processes the request and sends response back.

    l         The BO is stateless.

     

    In order to fulfill new requirements, I need to be able to do the following:

    l         The BO needs to maintain state across method calls.

    l         Each instance of the client application has to be served by a dedicated instance of the native BO. CAO doesn’t help here because the BO is a singleton.

    l         I need to have a message routing mechanism by which I can hook up a BO object to each client instance and route messages from each client to the appropriate BO.

    l         The initial start up of the BO is a time consuming operation. So I will need to create several instances of the BO at startup, and then, as and when new client requests come in, I need to be able to route the requests to the appropriate BO instance.

    l         The BO instances need to be created on the server side, it cannot be created on the client side.

     

    What will be the best way to achieve this?

    l         Should I create each instance of native BO in a different App domain on the server side? Will app domain provide the necessary isolation, given that the BO is legacy unmanaged code and could potentially have global variables, class static members, etc.

    l         Is there any way I can leverage IIS app pools for this? May be create each BO instance in a separate worker process?

    l         Is there a way to custom-manage the message routing when the remote server object is hosted as Windows service or in IIS?

    Friday, April 24, 2009 4:56 PM

All replies

  • Hi

    • Have thought of using the Window Communication Service framework. Hosting the WCF Service in COM environment. Their provision hosting window communication service in COM+.
    • Issues of states can be easily in window communication framework provided by Microsoft.

    Regards.
    Phijo Mathew Philip.


    PHIJO MP
    Saturday, April 25, 2009 3:08 PM
  • Hi

    Some links for WCF service hosting in COM+

     Integrating with COM+ Applications
    •  http://msdn.microsoft.com/en-us/library/ms733094.aspx

    Integrating with COM+ Applications Overview
    • http://msdn.microsoft.com/en-us/library/ms734723.aspx

    How to: Use the COM+ Service Model Configuration Tool
    • http://msdn.microsoft.com/en-us/library/ms732241.aspx

    How to: Configure COM+ Service Settings
    • http://msdn.microsoft.com/en-us/library/ms734782.aspx


    How to: Deploy a COM+ Integration Application
    •  http://msdn.microsoft.com/en-us/library/aa751924.aspx

    Hosting WCF Service using COM+
    • http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/11be378f-209c-41de-b40f-0fb5dde1f392/


    Hosting WCF in COM+ with different
    • transportshttp://blogs.msdn.com/distilled/archive/2006/02/15/532807.aspx
    Hope that the links will help you out.

    Regards,
    Phijo Mathew Philip.




    PHIJO MP
    Saturday, April 25, 2009 5:08 PM
  • Hi

    • Since Your business logic is unmanaged application.
    • You can use platform invoke and using DllImport from the managed memory you can pass and get values from the unmanaged business object.
    • Then you can call methods in wcf service and then host the wcf service in +COM.

    Regards,
    Phijo Mathew Philip,
    PHIJO MP
    Saturday, April 25, 2009 5:19 PM
  • l         This SAO object in turn holds a native unmanaged Business Object (BO).

    l         This native BO is a singleton.

    l         The client apps execute methods on the remote server which in turn passes on the request to the BO. The BO processes the request and sends response back.

    l         The BO is stateless.

     


    How are you using an SAO singleton (which is stateful) that is holding a native BO that you state is also stateful, then the last line there you say they are stateless.  Aren't you already stateful?  If you need to have the BO maintain state across clients, then it sounds like you are already there with your singleton SAO.

    So assuming you made a typo and your BO is indeed currently stateless.  Switch your initial remoting object to an SAO singleton (stateful).  You can pre-instance your SAO in the service startup code and have remoting serve that object so that your initial BO creation is done when the service is first started (otherwise your first caller will get a much longer wait).

    What do you mean when you say you need to create a message routing mechanism to route your msgs to the right BO?  If you have multiple BO's (hopefully that are stateless) why not just instance them from the client?

    Several of your statements seem a bit contradictory or maybe I am just reading them wrong.  If you could clear those up I might be able to help you more.

    as a last note, I would second what everyone else has said, WCF is transport mechanism to use for this but it won't change the basis for what you are trying to do.
    Monday, April 27, 2009 1:08 AM
  • My apologies for creating this confusion, let me rephrase my question a little bit..

    The SAO is singleton and the BO is also a singleton (stateful).

    The problem I face is this: How do I create multiple instances of the BO, given that BO is singleton by design.
    There can be several instances of the client application concurrently running. Each client instance needs to talk to a dedicated instance of the BO. For several reasons, we cannot deploy the BO to the client side. So we need to create multiple BO instances on the server side.

    Hence my questions on the feasibility of using App domains / IIS app pools and message routing.
    Hope this clears it up...

    We are still on .NET 2.0, so WCF will not be a feasible option..
    Many Thanks for your help on this..
     

    Monday, April 27, 2009 5:04 AM
  • Let me make sure I understand correctly.  Your native BO (com?) is a singleton and thus and you are creating an SAO that connects to that singleton.  If that is the case, then you are already fine.  If the remoting BO is an SAO Singleton then each client can get it's own reference to that SAO and everyone will be calling into the same object.  An SAO Singleton can be referenced by many clients at once.  You just have to realize that your SAO Singleton will service the client calls in a multithreaded manner (so you need to put thread safety around instance class variables).

    Now, if what you actually mean is that you want multiple separate instances of a singleton then you have to ask yourself a couple questions.  Primarily, why are you making it a singleton in the first place when you really don't need a singleton?  Are you just doing it to make the object stateful?  If that is the case, why not use a CAO instead?

    Perhaps it would also help to tell us what these objects are doing.

    -Allen Anderson
    .Net Architect / Richer Components, Inc.
    Monday, April 27, 2009 5:19 AM
  • Yes, what I really want is multiple separate instances of an unmanaged singleton.
    Why is the BO a singleton in the first place? Its probably only to make it stateful, but we cannot change that because most of the users of the BO are Excel-based. In any case the BO is a separate component managed by another global team within my organisation and its not within my control to make architectural changes to it. We just have to work around it.

    Even if I create multiple CAOs, the underlying BO is still a singleton. So even if multiple client apps go through multiple CAOs, all the calls will get ultimately routed to the single instance of BO.

    As to what these objects are doing, the BO is a legacy computation engine in C++. The Remoting server is just a thin wrapper around it, does not have any logic of its own. The client apps are MDI based windows apps. The user could provide several input parameters which are passed down to the BO via the remoting server. The BO takes care of all the computation and provides back the results.

    Thanks once again..

    Monday, April 27, 2009 6:05 AM
  • A StaticThreadAttribute on your private static singleton instance (http://msdn.microsoft.com/en-us/librar/system.threadstaticattribute%28vs.71%29.aspx )
    may help in your situation, assuming that you will create a different thread for each user.
    Monday, April 27, 2009 2:43 PM
  • ok, so when you boil this all down and remove everything else, you basically need a way to instance a COM singleton multiple times.

    so the primary question that comes to mind is, why not just remove declare_classfactory_singleton and make the com object instanceable? 
    Allen Anderson - Enterprise Architect http://www.richercomponents.com
    Monday, April 27, 2009 4:08 PM
  • >>> A StaticThreadAttribute on your private static singleton instance (http://msdn.microsoft.com/en-us/librar/system.threadstaticattribute%28vs.71%29.aspx ) may help in your situation, assuming that you will create a different thread for each user.
    >>>

    I could try this. But since it is unmanaged code and could potentially be using global variables, it might not work as expected.

    >>> why not just remove declare_classfactory_singleton and make the com object instanceable?
    >>>

    Unfortunately I do not have access to change the BO's codebase.

    My question is this: Will appdomains provide enough isolation for isolating unmanaged objects?
    Tuesday, April 28, 2009 10:15 AM
  • Is your com object in a dll or exe?  dll singletons and exe singletons act differently.  To be honest, this is the wrong forum for your question.  You'll get a much better more informed response from the COM/ATL forum.  I did COM/ATL for a long time, but it's been 8 years since I did those technologies full time.


    Allen Anderson - Enterprise Architect http://www.richercomponents.com
    Tuesday, April 28, 2009 3:24 PM