locked
Use proxy for MRDS system service namespaces? RRS feed

  • Question

  • Hello Again,

     

    In the "using" statements at the top of my DSS service class modules, should I be using the Proxy namespace for System Services namespaces?

     

    Here's an example:

    Code Snippet

    using Microsoft.Ccr.Core;

    using Microsoft.Dss.Core.Attributes;

    using Microsoft.Dss.Hosting;

    using Microsoft.Dss.ServiceModel.Dssp;

    using Microsoft.Dss.ServiceModel.DsspServiceBase;

    using Microsoft.Ccr.Adapters.WinForms;

    using dssp = Microsoft.Dss.ServiceModel.Dssp;

     

    using W3C.Soap;

     

    using submgr = Microsoft.Dss.Services.SubscriptionManager.Proxy;

    using ds = Microsoft.Dss.Services.Directory.Proxy;

    using cs = Microsoft.Dss.Services.Constructor.Proxy;

    using mlc = Microsoft.Dss.Services.ManifestLoaderClient.Proxy;

    using plm = Microsoft.Dss.Services.PartnerListManager.Proxy;

     

     

    I've read other messages in this forum that state I should always use the Proxy namespaces for custom services namespaces that I or other developers create.  However, I would like to know if this is also true for the System Services namespaces.

     

    If I should be using the Proxy namespace for System Services namespaces, then why does none of the MRDS documentation or the project templates that come with MRDS use the Proxy namespace?

     

    Thank you,

    Thursday, December 4, 2008 7:35 PM
    Moderator

Answers

  • Hi Bryan,

     

    Just a side comment -

    Right now services use strong naming. Because of this, a service that was built with V1.5 will not run with V2.0. This is by design.

     

    I am interested in comments on this.

     

    Trevor

     

     

    Monday, December 8, 2008 7:28 PM

All replies

  • DsspServiceBase class has several « System » service ports, like ConstructorPort or DirectoryPort that use non-proxy types. I assume that the purpose is to provide local access to system services without having them declared as partner. You should use the proxy types when your service could interact with other nodes.

    For example, if you program a service that provides a win form GUI to create services on a node, you should use “classic” partner declarations and proxy type with interact with constructor service. By changing only the manifest, this kind of service can interact with any node (local or distant). It offers more deployment scenarios.


    To summarize my thought:

    - If your code purpose is to interact only with local system services, use non-proxy types with operation ports provided by DsspServiceBase properties or helpers

    - If your code could call non-local system services, use proxy types with classic partner declarations

    Vincent


    Friday, December 5, 2008 8:09 AM
  • Interesting thoughts.

    I always thought that we should be using the Proxies regardless. At least that was the impression I was left with after I read through all the documentation.

    Since I have just started trying to make some Project templates for in house use I guess I am going to have to look at using the proxies vs the implementation dlls.

    Specifically I am wondering about the Microsoft.Dss.Runtime and its proxy,
    Microsoft.Dss.Runtime.Proxy, since these hold all the frequently used node services.

    *****  I gues you CAN'T use the proxy dll. Well not the
    Microsoft.Dss.Runtime.Proxy dll because it doesn't contain the DsspServiceBase class.

    Now I wonder why they didn't split out the base class implementation into its own dll?
    I would think we should be using the Proxy dll so that as MS changes the implementation from release to release we should not have to recompile our services?

    Bryan
    Friday, December 5, 2008 6:56 PM
  • Hi Bryan,

     

    Just a side comment -

    Right now services use strong naming. Because of this, a service that was built with V1.5 will not run with V2.0. This is by design.

     

    I am interested in comments on this.

     

    Trevor

     

     

    Monday, December 8, 2008 7:28 PM