Re: soapsuds

From: Sahil Malik (contactmethrumyblog_at_nospam.com)
Date: 06/09/04 

Date: Wed, 9 Jun 2004 10:02:09 -0400

I don't know what wise men would say, but here is what I'd say.

> Thanks for your comments. I have come across this view many times,
however,
> I do not understand it. I have had no problems using soapsuds at all apart
> from the one that I have mentioned in this post which I have now resolved.
> This would appear to be related to namespacing. If the interface in the
> 'general' assembly is in the same namespace as the implementation object
in
> the 'server' assembly, then the soapsuds extraction falls over. Placing
the
> objects in different namespaces resolved the issue. Is there a restriction
> in .Net that namespaces cannot span assemblies? I am not aware of it. In
any
> case, it is easy enough to code the 'proxy' remote class code including
the
> Soap attributes by hand.

The problem with Soapsuds is, you cannot have one small exe generate this
information for every possible case out there. Other such examples in .NET
framework, where you are better off implementing stuff yourself are the
Serializable Attribute versus ISerializable, CommandBuilder versus
specifying commands etc. etc. (fairly long list really). Anyway without
wasting time on "Why not to use soapsuds", since there is plenty about that
online, just don't use it .. hehe :).

> I can now use new to instantiate my remote object, access it via an
> interface defined in a shared assembly (which can be implemented my other
> remote objects) which leaves me totally free to redevelop the server
object.
> I have complete control over versioning via the framework. I believe that
is
> what versioning was designed to do. However, nothing is stopping me from
> adding a V2 interface or allowing old clients to connect to new server
> assemblies.

True, and that in my mind is a better approach. You should have a seperate
dll which sits both on the server and the client allowing objects to talk to
each other. Yes you could have a seperate V2 interface in the same dll, but
the question is, why would you want older clients to talk to newer server
assemblies? Ideally the whole product should work as one unified version.
i.e. Server version = 2.x, will work only with Client version 2.x. And the
good news is that you really don't have to do anything to enforce that. As
long as the common dll on both client and server have the same matching
version #'s, the Server and Client will work in tandem. Whats better, you
could now have side by side versions, and actually have 2 servers same
machine different versions running on different ports.

> I am very keen to totally separate the client and server from the remoting
> process and use new to instantiate remote objects so that I can enhance
and
> develop the remoting protocol without having to recode either client or
> server objects. This cannot be achieved via the framework by using
> interfaces or abstract classes. I have seen custom implementations that
> allow using instantiation via new by basically walking through the config
> file to create the remote object, but is that not what the framework does
on
> your behalf? Will I be able to do it better? Furthermore, if I create a
> custom solution, I will most likely not benefit from future enhancements
to
> the framework remoting methodology.

Thats a good idea. With Indigo on the horizon, a few things will change, so
your communication methodology should be changeable. What I have done is,
that I have designed my own class factory. That class factory is responsible
for either doing a "new", or Activator.GetObject depending upon Appdomain,
so my locally configured objects don't get hit by the performance overhead
of remoting (remoting is verrrryyy slow). Another added side benefit from
this is, that really if I use a class factory, when architecture changes,
all I have to do is modify the class factory, and not worry about "new"
doesn't work anymore ore something similar thereof. You get the added
performance bang too :).

> However, my major problem with using interfaces only to control versioning
> is that you may well run into (actually in my view most likely to run
into)
> deployment problems down the road. In particular, how would you force
> existing old clients to use old server assemblies? You may want to. I
would
> not want to make the assumption at the start of the project that v 1.0
> clients will always be able to use v N.0 server assemblies.

I have already elaborated on this in the first paragraph, but let me add
another good peice of info. I have another common dll whose version number I
donot change. When the client starts up, it uses that common dll (you could
eve use soapsuds for something this simple), to check the version number,
and if the client's version is out of whack, it automatically downloads the
new MSI, fires up an installer.exe, which first kills the client, and then
runs the MSI. One important thing to consider here, whenever I recreate the
MSI, I change the product version number, but I DONOT change the product
package GUID and another GUID there, that way it "thinks" that really this
is a re-install of the same product (AHA tricked ya). That way my client
will

a) Always remain updated.
b) Never get out of version errors.
c) The upgrade process is very very simple for the end user.

Hope that helped.

- Sahil Malik
Independent Consultant
You can reach me thru my blog at -
http://www.dotnetjunkies.com/weblog/sahilmalik/

"Richard Bell" <richardb@rogge.co.uk> wrote in message
news:%23JT397gTEHA.3336@TK2MSFTNGP10.phx.gbl...
> Thanks for your comments. I have come across this view many times,
however,
> I do not understand it. I have had no problems using soapsuds at all apart
> from the one that I have mentioned in this post which I have now resolved.
> This would appear to be related to namespacing. If the interface in the
> 'general' assembly is in the same namespace as the implementation object
in
> the 'server' assembly, then the soapsuds extraction falls over. Placing
the
> objects in different namespaces resolved the issue. Is there a restriction
> in .Net that namespaces cannot span assemblies? I am not aware of it. In
any
> case, it is easy enough to code the 'proxy' remote class code including
the
> Soap attributes by hand.
>
> I can now use new to instantiate my remote object, access it via an
> interface defined in a shared assembly (which can be implemented my other
> remote objects) which leaves me totally free to redevelop the server
object.
> I have complete control over versioning via the framework. I believe that
is
> what versioning was designed to do. However, nothing is stopping me from
> adding a V2 interface or allowing old clients to connect to new server
> assemblies.
>
> I am very keen to totally separate the client and server from the remoting
> process and use new to instantiate remote objects so that I can enhance
and
> develop the remoting protocol without having to recode either client or
> server objects. This cannot be achieved via the framework by using
> interfaces or abstract classes. I have seen custom implementations that
> allow using instantiation via new by basically walking through the config
> file to create the remote object, but is that not what the framework does
on
> your behalf? Will I be able to do it better? Furthermore, if I create a
> custom solution, I will most likely not benefit from future enhancements
to
> the framework remoting methodology.
>
> However, my major problem with using interfaces only to control versioning
> is that you may well run into (actually in my view most likely to run
into)
> deployment problems down the road. In particular, how would you force
> existing old clients to use old server assemblies? You may want to. I
would
> not want to make the assumption at the start of the project that v 1.0
> clients will always be able to use v N.0 server assemblies.
>
> What say the wise men?
>
> "Sahil Malik" <contactmethrumyblog@nospam.com> wrote in message
> news:%23lsDy$XTEHA.504@TK2MSFTNGP11.phx.gbl...
> > Wise men say -> Don't use soapsuds
> >
> > --
> > - Sahil Malik
> > Independent Consultant
> > You can reach me thru my blog -
> http://dotnetjunkies.com/WebLog/sahilmalik/
> >
> >
> >
> > "Richard Bell" <richardb@rogge.co.uk> wrote in message
> > news:O2lM2IUTEHA.2716@tk2msftngp13.phx.gbl...
> > > When I use soapsuds to extract mata data for a class which implements
an
> > > interface which is defined in a separate assembly I get a null
reference
> > > error. Do all interfaces/abstract classes which are implement by a
class
> > > being extracted have to be defined within the same assembly, or, am I
> > doing
> > > something wrong. Many thanks.
> > >
> > >
> >
> >
>
>