Richard Bell
6/30/2004 12:18:00 PM
As regards client to server communication, in our minds it depends on who
the target client is. If you want total flexibility, web services would
appear to be the way to go because you are not restricting your client to a
particular operating system or runtime environment. We tend to try and
design our service objects so that they can (at least partially) operate in
a web service scenario, albeit typically with reduced functionality.
As regards Enterprise Services, we do find that lot''s of our middle tier
objects end up going in COM+ for the simple reason that we cannot be sure at
design time whether or not they will end up as part of a transaction. To my
mind, along with resource sharing via object pooling etc., that was the
major thrust of all the Roger Sessions little goblin stuff. Make objects
responsible only for doing their job and let the framework deal with the
transaction.
For what it''s worth, our guess is that Enterprise Services, or something
like it, is here to stay and that the overhead of using it will be reduced
as the functionality becomes more closely tied into the .Net runtime.
"A Mackie" <andrew@mackie14.freeserve.co.uk> wrote in message
news:uxmpD0eXEHA.808@tk2msftngp13.phx.gbl...
> Allen Anderson wrote:
>
> > this debate has really been raging for the past several months.
>
> Was any consensus reached ? The debate has just started raging where I
> work! :-)
>
> I''ve saw numerous articles, but they typically read like this - "in
> some cases remoting is best, in other cases web-services is good, then
> again, you might want Enterprise Services". Hmmm, very helpful!
>
>
> Thanks,
> Andy.