RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

>> I had the idea that `CreateInstanceAndUnwrap` and `MarshalByRef` used
remoting under the covers

 

Yes I believe they do. Anything MarshalByRef has a bunch of constraints.
Very powerful tho.

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Ben Scott
Sent: Tuesday, 5 February 2013 2:41 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

I had the idea that `CreateInstanceAndUnwrap` and `MarshalByRef` used
remoting under the covers, any marshalled objects needed to stick to what
remoting supports. _Huge_ gotchas in those murky waters...




On Tue, Feb 5, 2013 at 1:31 PM, Paul Glavich mailto:subscripti...@theglavs.com> > wrote:

You can get away without directly using remoting if you want appDomain
isolation. In our app, we have a threadpool and an appDomain pool. Some
items get shunted off to threads to do some work, some off to separate
appDomains for the isolation you mentioned. You can use the AppDomain object
itself, then use the 'CreateInstanceAndUnwrap' method to create an instance
of a 'MarshalByRef' object, then execute methods off that.

 

When all is done, use the AppDomain.Unload method to get rid of it. And no,
just going across appDomains, I would not use the mentioned technologies
(WebApi etc..) as you would be seriously wasting time with unnecessary
network calls, serialisation/de serialisation etc..

 

-  Glav

 

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
] On Behalf Of Ben Scott
Sent: Tuesday, 5 February 2013 12:02 PM


To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

In the MarkPad Code52 project I was using remoting to implement appdomains
for plugins, so that plugins couldn't crash the editor. It didn't work,
probably due to my inexperience, but it seemed like remoting is still the
status quo for appdomains. I don't see why you would try to do that over
something like webapi, NancyFx or even SignalR for cross machine comms.



On Tue, Feb 5, 2013 at 8:53 AM, Paul Glavich mailto:subscripti...@theglavs.com> > wrote:

Nope. Remoting is a way to marshal objects across a boundary whether that be
appDomain (2 separate appDomains on the same machine) or a network boundary
(machine 1 to machine 2). It looks and operates very much like DCOM if that
helps, in that it appears that you have a reference to the same object on
either end. Security wise it is not so strong but it works well and security
can be implemented via it channel sink mechanism. It goes way back to .Net 1
and is embedded in the core framework. Back in .Net 1 days it was either
ASMX web services or remoting to get across machines. As already surmised,
it is not promoted as a communications or messaging strategy since it is
proprietary and quite low level from a framework perspective.

 

System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and
allowed things like easily exposing .Net components via COM+/DCOM (as a
ServicedComponent) through the component services manager (although you
don't have to do this) for use by .Net and non .Net clients alike (primarily
VB 6, C/C++ etc.). I can't say I have used this namespace in a while though
so memory is a little rusty. The component services manager also made it
easier to manage transaction scopes for components and monitor their use, in
particular distributed transactions. The component services manager is
actually quite powerful. You had a bunch of attributes in the namespace
which allowed participation in DTC trx negotiation. There is more which I am
sure others can highlight for you.

 

 

-  Glav

 

 

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
] On Behalf Of Katherine Moss
Sent: Monday, 4 February 2013 5:11 PM
To: ozDotNet
Subject: RE: SPAM-LOW Re: WCF service best practises

 

Now, remind me.  Is System.Net.EnterpriseServices the same as
System.NET.Remoting?  

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh
Sent: Sunday, February 03, 2013 5:21 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

Apparently the .NET remoting documentation has been removed and you have to
hunt around in the archives for it now (I haven't looked myself), so that's
probably a hint about being out-of-date. However, I have a sentimental
feeling for remoting as we have an intensely used client-server app out
there that will have its 10th birthday later this year, so by the date you
can tell it started in Framework 1.0 with Remoting. A newer app from last
year uses WCF and despite the extra work it gives us no particular ad

Re: SPAM-LOW Re: WCF service best practises

[Ben Scott]

I had the idea that `CreateInstanceAndUnwrap` and `MarshalByRef` used
remoting under the covers, any marshalled objects needed to stick to what
remoting supports. _Huge_ gotchas in those murky waters...



On Tue, Feb 5, 2013 at 1:31 PM, Paul Glavich wrote:

> You can get away without directly using remoting if you want appDomain
> isolation. In our app, we have a threadpool and an appDomain pool. Some
> items get shunted off to threads to do some work, some off to separate
> appDomains for the isolation you mentioned. You can use the AppDomain
> object itself, then use the ‘CreateInstanceAndUnwrap’ method to create an
> instance of a ‘MarshalByRef’ object, then execute methods off that.
>
> ** **
>
> When all is done, use the AppDomain.Unload method to get rid of it. And
> no, just going across appDomains, I would not use the mentioned
> technologies (WebApi etc..) as you would be seriously wasting time with
> unnecessary network calls, serialisation/de serialisation etc….
>
> ** **
>
> **-  **Glav
>
> ** **
>
> ** **
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Ben Scott
> *Sent:* Tuesday, 5 February 2013 12:02 PM
>
> *To:* ozDotNet
> *Subject:* Re: SPAM-LOW Re: WCF service best practises
>
> ** **
>
> In the MarkPad Code52 project I was using remoting to implement appdomains
> for plugins, so that plugins couldn't crash the editor. It didn't work,
> probably due to my inexperience, but it seemed like remoting is still the
> status quo for appdomains. I don't see why you would try to do that over
> something like webapi, NancyFx or even SignalR for cross machine comms.
>
>
> 
>
> On Tue, Feb 5, 2013 at 8:53 AM, Paul Glavich 
> wrote:
>
> Nope. Remoting is a way to marshal objects across a boundary whether that
> be appDomain (2 separate appDomains on the same machine) or a network
> boundary (machine 1 to machine 2). It looks and operates very much like
> DCOM if that helps, in that it appears that you have a reference to the
> same object on either end. Security wise it is not so strong but it works
> well and security can be implemented via it channel sink mechanism. It goes
> way back to .Net 1 and is embedded in the core framework. Back in .Net 1
> days it was either ASMX web services or remoting to get across machines. As
> already surmised, it is not promoted as a communications or messaging
> strategy since it is proprietary and quite low level from a framework
> perspective.
>
>  
>
> System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and
> allowed things like easily exposing .Net components via COM+/DCOM (as a
> ServicedComponent) through the component services manager (although you
> don’t have to do this) for use by .Net and non .Net clients alike
> (primarily VB 6, C/C++ etc…). I can’t say I have used this namespace in a
> while though so memory is a little rusty. The component services manager
> also made it easier to manage transaction scopes for components and monitor
> their use, in particular distributed transactions. The component services
> manager is actually quite powerful. You had a bunch of attributes in the
> namespace which allowed participation in DTC trx negotiation. There is more
> which I am sure others can highlight for you.
>
>  
>
>  
>
> -      Glav****
>
>  ****
>
>  
>
>  
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Katherine Moss
> *Sent:* Monday, 4 February 2013 5:11 PM
> *To:* ozDotNet
> *Subject:* RE: SPAM-LOW Re: WCF service best practises
>
>  
>
> Now, remind me.  Is System.Net.EnterpriseServices the same as
> System.NET.Remoting?  
>
>  
>
> *From:* ozdotnet-boun...@ozdotnet.com [
> mailto:ozdotnet-boun...@ozdotnet.com ] *On
> Behalf Of *Greg Keogh
> *Sent:* Sunday, February 03, 2013 5:21 PM
> *To:* ozDotNet
> *Subject:* Re: SPAM-LOW Re: WCF service best practises
>
>  
>
> Apparently the .NET remoting documentation has been removed and you have
> to hunt around in the archives for it now (I haven't looked myself), so
> that's probably a hint about being out-of-date. However, I have a
> sentimental feeling for remoting as we have an intensely used client-server
> app out there that will have its 10th birthday later this year, so by the
> date you can tell it started in Framework 1.0 with Remoting. A newer app
> from last year uses WCF and despite the extra work it gives us no
> particular advantage and it works just the same. If don't need all the
> hyped flexibility and generalisation t

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

You can get away without directly using remoting if you want appDomain
isolation. In our app, we have a threadpool and an appDomain pool. Some
items get shunted off to threads to do some work, some off to separate
appDomains for the isolation you mentioned. You can use the AppDomain object
itself, then use the 'CreateInstanceAndUnwrap' method to create an instance
of a 'MarshalByRef' object, then execute methods off that.

 

When all is done, use the AppDomain.Unload method to get rid of it. And no,
just going across appDomains, I would not use the mentioned technologies
(WebApi etc..) as you would be seriously wasting time with unnecessary
network calls, serialisation/de serialisation etc..

 

-  Glav

 

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Ben Scott
Sent: Tuesday, 5 February 2013 12:02 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

In the MarkPad Code52 project I was using remoting to implement appdomains
for plugins, so that plugins couldn't crash the editor. It didn't work,
probably due to my inexperience, but it seemed like remoting is still the
status quo for appdomains. I don't see why you would try to do that over
something like webapi, NancyFx or even SignalR for cross machine comms.




On Tue, Feb 5, 2013 at 8:53 AM, Paul Glavich mailto:subscripti...@theglavs.com> > wrote:

Nope. Remoting is a way to marshal objects across a boundary whether that be
appDomain (2 separate appDomains on the same machine) or a network boundary
(machine 1 to machine 2). It looks and operates very much like DCOM if that
helps, in that it appears that you have a reference to the same object on
either end. Security wise it is not so strong but it works well and security
can be implemented via it channel sink mechanism. It goes way back to .Net 1
and is embedded in the core framework. Back in .Net 1 days it was either
ASMX web services or remoting to get across machines. As already surmised,
it is not promoted as a communications or messaging strategy since it is
proprietary and quite low level from a framework perspective.

 

System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and
allowed things like easily exposing .Net components via COM+/DCOM (as a
ServicedComponent) through the component services manager (although you
don't have to do this) for use by .Net and non .Net clients alike (primarily
VB 6, C/C++ etc.). I can't say I have used this namespace in a while though
so memory is a little rusty. The component services manager also made it
easier to manage transaction scopes for components and monitor their use, in
particular distributed transactions. The component services manager is
actually quite powerful. You had a bunch of attributes in the namespace
which allowed participation in DTC trx negotiation. There is more which I am
sure others can highlight for you.

 

 

-  Glav

 

 

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
] On Behalf Of Katherine Moss
Sent: Monday, 4 February 2013 5:11 PM
To: ozDotNet
Subject: RE: SPAM-LOW Re: WCF service best practises

 

Now, remind me.  Is System.Net.EnterpriseServices the same as
System.NET.Remoting?  

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh
Sent: Sunday, February 03, 2013 5:21 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

Apparently the .NET remoting documentation has been removed and you have to
hunt around in the archives for it now (I haven't looked myself), so that's
probably a hint about being out-of-date. However, I have a sentimental
feeling for remoting as we have an intensely used client-server app out
there that will have its 10th birthday later this year, so by the date you
can tell it started in Framework 1.0 with Remoting. A newer app from last
year uses WCF and despite the extra work it gives us no particular advantage
and it works just the same. If don't need all the hyped flexibility and
generalisation that WCF give you then it doesn't contribute much.

 

If you just want two .NET app ends to talk over tcp or pipe with minimal
configuration or code bloat then remoting is still viable. I have a tiny
utility project with minimal remoting server and client classes that I throw
into a project if I quickly need two things to communicate. However, there
is little need for it lately as loading stuff into an AppDomain and talking
via a proxy is easier, and guess what ... it uses remoting internally to
talk between AppDomains. So remoting isn't dead, it's just gone into hiding.

 

Greg

 

Re: SPAM-LOW Re: WCF service best practises

[Ben Scott]

In the MarkPad Code52 project I was using remoting to implement appdomains
for plugins, so that plugins couldn't crash the editor. It didn't work,
probably due to my inexperience, but it seemed like remoting is still the
status quo for appdomains. I don't see why you would try to do that over
something like webapi, NancyFx or even SignalR for cross machine comms.



On Tue, Feb 5, 2013 at 8:53 AM, Paul Glavich wrote:

> Nope. Remoting is a way to marshal objects across a boundary whether that
> be appDomain (2 separate appDomains on the same machine) or a network
> boundary (machine 1 to machine 2). It looks and operates very much like
> DCOM if that helps, in that it appears that you have a reference to the
> same object on either end. Security wise it is not so strong but it works
> well and security can be implemented via it channel sink mechanism. It goes
> way back to .Net 1 and is embedded in the core framework. Back in .Net 1
> days it was either ASMX web services or remoting to get across machines. As
> already surmised, it is not promoted as a communications or messaging
> strategy since it is proprietary and quite low level from a framework
> perspective.
>
> ** **
>
> System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and
> allowed things like easily exposing .Net components via COM+/DCOM (as a
> ServicedComponent) through the component services manager (although you
> don’t have to do this) for use by .Net and non .Net clients alike
> (primarily VB 6, C/C++ etc…). I can’t say I have used this namespace in a
> while though so memory is a little rusty. The component services manager
> also made it easier to manage transaction scopes for components and monitor
> their use, in particular distributed transactions. The component services
> manager is actually quite powerful. You had a bunch of attributes in the
> namespace which allowed participation in DTC trx negotiation. There is more
> which I am sure others can highlight for you.
>
> ** **
>
> ** **
>
> **-  **Glav
>
> ** **
>
> ** **
>
> ** **
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Katherine Moss
> *Sent:* Monday, 4 February 2013 5:11 PM
> *To:* ozDotNet
> *Subject:* RE: SPAM-LOW Re: WCF service best practises
>
> ** **
>
> Now, remind me.  Is System.Net.EnterpriseServices the same as
> System.NET.Remoting?  
>
> ** **
>
> *From:* ozdotnet-boun...@ozdotnet.com [
> mailto:ozdotnet-boun...@ozdotnet.com ] *On
> Behalf Of *Greg Keogh
> *Sent:* Sunday, February 03, 2013 5:21 PM
> *To:* ozDotNet
> *Subject:* Re: SPAM-LOW Re: WCF service best practises
>
> ** **
>
> Apparently the .NET remoting documentation has been removed and you have
> to hunt around in the archives for it now (I haven't looked myself), so
> that's probably a hint about being out-of-date. However, I have a
> sentimental feeling for remoting as we have an intensely used client-server
> app out there that will have its 10th birthday later this year, so by the
> date you can tell it started in Framework 1.0 with Remoting. A newer app
> from last year uses WCF and despite the extra work it gives us no
> particular advantage and it works just the same. If don't need all the
> hyped flexibility and generalisation that WCF give you then it doesn't
> contribute much.
>
>  
>
> If you just want two .NET app ends to talk over tcp or pipe with minimal
> configuration or code bloat then remoting is still viable. I have a tiny
> utility project with minimal remoting server and client classes that I
> throw into a project if I quickly need two things to communicate. However,
> there is little need for it lately as loading stuff into an AppDomain and
> talking via a proxy is easier, and guess what ... it uses remoting
> internally to talk between AppDomains. So remoting isn't dead, it's just
> gone into hiding.
>
>  
>
> Greg
>

RE: SPAM-LOW Re: WCF service best practises

[Katherine Moss]

Okay.  I should probably disable that on the server then considering I don't 
think I'll be using it.  I'm pretty sure I inadvertently had Com+ enabled when 
I first installed application server.  That's pretty interesting though.  It 
looks like Project Jenks could be getting a rethinking after this series of 
messages, and not to mention, I haven't even done a WCF demo yet, though I 
can't wait till I get there.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Paul Glavich
Sent: Monday, February 04, 2013 5:53 PM
To: 'ozDotNet'
Subject: RE: SPAM-LOW Re: WCF service best practises

Nope. Remoting is a way to marshal objects across a boundary whether that be 
appDomain (2 separate appDomains on the same machine) or a network boundary 
(machine 1 to machine 2). It looks and operates very much like DCOM if that 
helps, in that it appears that you have a reference to the same object on 
either end. Security wise it is not so strong but it works well and security 
can be implemented via it channel sink mechanism. It goes way back to .Net 1 
and is embedded in the core framework. Back in .Net 1 days it was either ASMX 
web services or remoting to get across machines. As already surmised, it is not 
promoted as a communications or messaging strategy since it is proprietary and 
quite low level from a framework perspective.

System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and 
allowed things like easily exposing .Net components via COM+/DCOM (as a 
ServicedComponent) through the component services manager (although you don't 
have to do this) for use by .Net and non .Net clients alike (primarily VB 6, 
C/C++ etc...). I can't say I have used this namespace in a while though so 
memory is a little rusty. The component services manager also made it easier to 
manage transaction scopes for components and monitor their use, in particular 
distributed transactions. The component services manager is actually quite 
powerful. You had a bunch of attributes in the namespace which allowed 
participation in DTC trx negotiation. There is more which I am sure others can 
highlight for you.



-  Glav



From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Katherine Moss
Sent: Monday, 4 February 2013 5:11 PM
To: ozDotNet
Subject: RE: SPAM-LOW Re: WCF service best practises

Now, remind me.  Is System.Net.EnterpriseServices the same as 
System.NET.Remoting?

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh
Sent: Sunday, February 03, 2013 5:21 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

Apparently the .NET remoting documentation has been removed and you have to 
hunt around in the archives for it now (I haven't looked myself), so that's 
probably a hint about being out-of-date. However, I have a sentimental feeling 
for remoting as we have an intensely used client-server app out there that will 
have its 10th birthday later this year, so by the date you can tell it started 
in Framework 1.0 with Remoting. A newer app from last year uses WCF and despite 
the extra work it gives us no particular advantage and it works just the same. 
If don't need all the hyped flexibility and generalisation that WCF give you 
then it doesn't contribute much.

If you just want two .NET app ends to talk over tcp or pipe with minimal 
configuration or code bloat then remoting is still viable. I have a tiny 
utility project with minimal remoting server and client classes that I throw 
into a project if I quickly need two things to communicate. However, there is 
little need for it lately as loading stuff into an AppDomain and talking via a 
proxy is easier, and guess what ... it uses remoting internally to talk between 
AppDomains. So remoting isn't dead, it's just gone into hiding.

Greg

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

Nope. Remoting is a way to marshal objects across a boundary whether that be
appDomain (2 separate appDomains on the same machine) or a network boundary
(machine 1 to machine 2). It looks and operates very much like DCOM if that
helps, in that it appears that you have a reference to the same object on
either end. Security wise it is not so strong but it works well and security
can be implemented via it channel sink mechanism. It goes way back to .Net 1
and is embedded in the core framework. Back in .Net 1 days it was either
ASMX web services or remoting to get across machines. As already surmised,
it is not promoted as a communications or messaging strategy since it is
proprietary and quite low level from a framework perspective.

 

System.Net.EnterpriseServices is kind of a COM+/DCOM wrapper for .Net and
allowed things like easily exposing .Net components via COM+/DCOM (as a
ServicedComponent) through the component services manager (although you
don't have to do this) for use by .Net and non .Net clients alike (primarily
VB 6, C/C++ etc.). I can't say I have used this namespace in a while though
so memory is a little rusty. The component services manager also made it
easier to manage transaction scopes for components and monitor their use, in
particular distributed transactions. The component services manager is
actually quite powerful. You had a bunch of attributes in the namespace
which allowed participation in DTC trx negotiation. There is more which I am
sure others can highlight for you.

 

 

-  Glav

 

 

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Katherine Moss
Sent: Monday, 4 February 2013 5:11 PM
To: ozDotNet
Subject: RE: SPAM-LOW Re: WCF service best practises

 

Now, remind me.  Is System.Net.EnterpriseServices the same as
System.NET.Remoting?  

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh
Sent: Sunday, February 03, 2013 5:21 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

Apparently the .NET remoting documentation has been removed and you have to
hunt around in the archives for it now (I haven't looked myself), so that's
probably a hint about being out-of-date. However, I have a sentimental
feeling for remoting as we have an intensely used client-server app out
there that will have its 10th birthday later this year, so by the date you
can tell it started in Framework 1.0 with Remoting. A newer app from last
year uses WCF and despite the extra work it gives us no particular advantage
and it works just the same. If don't need all the hyped flexibility and
generalisation that WCF give you then it doesn't contribute much.

 

If you just want two .NET app ends to talk over tcp or pipe with minimal
configuration or code bloat then remoting is still viable. I have a tiny
utility project with minimal remoting server and client classes that I throw
into a project if I quickly need two things to communicate. However, there
is little need for it lately as loading stuff into an AppDomain and talking
via a proxy is easier, and guess what ... it uses remoting internally to
talk between AppDomains. So remoting isn't dead, it's just gone into hiding.

 

Greg

RE: SPAM-LOW Re: WCF service best practises

[Katherine Moss]

Now, remind me.  Is System.Net.EnterpriseServices the same as 
System.NET.Remoting?

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Sunday, February 03, 2013 5:21 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

Apparently the .NET remoting documentation has been removed and you have to 
hunt around in the archives for it now (I haven't looked myself), so that's 
probably a hint about being out-of-date. However, I have a sentimental feeling 
for remoting as we have an intensely used client-server app out there that will 
have its 10th birthday later this year, so by the date you can tell it started 
in Framework 1.0 with Remoting. A newer app from last year uses WCF and despite 
the extra work it gives us no particular advantage and it works just the same. 
If don't need all the hyped flexibility and generalisation that WCF give you 
then it doesn't contribute much.

If you just want two .NET app ends to talk over tcp or pipe with minimal 
configuration or code bloat then remoting is still viable. I have a tiny 
utility project with minimal remoting server and client classes that I throw 
into a project if I quickly need two things to communicate. However, there is 
little need for it lately as loading stuff into an AppDomain and talking via a 
proxy is easier, and guess what ... it uses remoting internally to talk between 
AppDomains. So remoting isn't dead, it's just gone into hiding.

Greg

Re: SPAM-LOW Re: WCF service best practises

[mike smith]

On Sat, Feb 2, 2013 at 2:09 PM, Paul Glavich wrote:

> At the risk of being argumentative, we asked for this. Maybe not you or me
> specifically, but the community at large has. I agree the number of
> technologies at play, particularly in this space is large but it makes it
> all the more **interesting** to make those architectural choices. In some
> ways, less choice is better as the number of possibilities and combinations
> are less, thus decisions are more constrained and easier to get to.
>
> ** **
>
> However, the flexibility afforded to us now is great. The better
> technologies will rise, the lesser ones either improved, integrated or
> discarded and this is our task. In a properly architected system, the risk
> of choice of a communications technology can be mitigated. However, we are
> also human and can introduce dependencies where in hindsight, this was a
> bad thing. We live and learn. It goes back to the “circle of dev life”
> previously mentioned. Never believe the hype. Accept it for what it is,
> experience it, come to an informed decision based on that, and your
> educated judgement. Remember, .Net remoting is still there J
>
> **
>


By that token, so is DCOM.  (bitter laughter)

-- 
Meski

 http://courteous.ly/aAOZcv

"Going to Starbucks for coffee is like going to prison for sex. Sure,
you'll get it, but it's going to be rough" - Adam Hills

Re: SPAM-LOW Re: WCF service best practises

[Greg Keogh]

Apparently the .NET remoting documentation has been removed and you have to
hunt around in the archives for it now (I haven't looked myself), so that's
probably a hint about being out-of-date. However, I have a sentimental
feeling for remoting as we have an intensely used client-server app out
there that will have its 10th birthday later this year, so by the date you
can tell it started in Framework 1.0 with Remoting. A newer app from last
year uses WCF and despite the extra work it gives us no particular
advantage and it works just the same. If don't need all the hyped
flexibility and generalisation that WCF give you then it doesn't contribute
much.

If you just want two .NET app ends to talk over tcp or pipe with minimal
configuration or code bloat then remoting is still viable. I have a tiny
utility project with minimal remoting server and client classes that I
throw into a project if I quickly need two things to communicate. However,
there is little need for it lately as loading stuff into an AppDomain and
talking via a proxy is easier, and guess what ... it uses remoting
internally to talk between AppDomains. So remoting isn't dead, it's just
gone into hiding.

Greg

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

>> I thought that .net remoting is kind of out-of-date

It kinda is and my mention at it was a failed attempt at some humour. Sorry
bout that.

 

As to your OSS project, I would hate to discourage you in any way and I
don't know enough what you plan to do to recommend a particular technology.
WCF is a very capable tech, and as some have already mentioned, can be a
little daunting. I would be looking at your ideal way of exposing your
information, who would consume it, and how they would typically consume
this, and base your decision on that. Talking to AD is usually (in my
experience) not done via WCF but through LDAP or something like that. WCF
(and other similar technologies) are more around exposing of services or
even components. I was writing an information consumption app a while back
(one of the million pet projects I nearly completed) that used WCF to allow
plugging in of any type of module to consume any type of information simply
by implementing an interface so its definitely a reasonable choice.

 

-  Glav

 

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Katherine Moss
Sent: Monday, 4 February 2013 5:25 AM
To: ozDotNet
Subject: RE: SPAM-LOW Re: WCF service best practises

 

I thought that .net remoting is kind of out-of-date and shouldn't be used
because of all of the new technologies.  Or is it out-of-date?  And now
you're making me question my plans for my first Open Source project that I
was going to put up in a year or two.  I was going to have it use WCF hosted
as a Windows Service to talk to some other modules like ADLDS and stuff like
that but now I should maybe rethink Project Jenks.  Or is WCF appropriate
for talking to things like that?  Such as, one of my ideas for Jenks (it is
going to be a bunch of things; modules that one can plug into a single
interface as needed), is to create a sort of contact-management interface
that links to both my web site (or any web site for that matter), and to
ADLDS.  And for the ADLDS part, I would have it's directory access module
piggy-back on Microsoft's provided web service interface.  PowerShell
already uses it, but why not create another interface other than ADSIEdit
for managing ADLDS  too?  So hopefully in the coming months and year, you
should see something on CodePlex if I can ever get all of this backlog on
learning programming out of the way.  I've been so busy and have had to give
up some things for now due to prioritization. Programming is secondary to me
at the moment, so it's more important that my Microsoft certification
process gets underway.

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Paul Glavich
Sent: Friday, February 01, 2013 10:10 PM
To: 'ozDotNet'
Subject: RE: SPAM-LOW Re: WCF service best practises

 

At the risk of being argumentative, we asked for this. Maybe not you or me
specifically, but the community at large has. I agree the number of
technologies at play, particularly in this space is large but it makes it
all the more *interesting* to make those architectural choices. In some
ways, less choice is better as the number of possibilities and combinations
are less, thus decisions are more constrained and easier to get to.

 

However, the flexibility afforded to us now is great. The better
technologies will rise, the lesser ones either improved, integrated or
discarded and this is our task. In a properly architected system, the risk
of choice of a communications technology can be mitigated. However, we are
also human and can introduce dependencies where in hindsight, this was a bad
thing. We live and learn. It goes back to the "circle of dev life"
previously mentioned. Never believe the hype. Accept it for what it is,
experience it, come to an informed decision based on that, and your educated
judgement. Remember, .Net remoting is still there :)

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Stephen Price
Sent: Saturday, 2 February 2013 11:52 AM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

I must be getting old too Greg. Your rants are starting to make sense. I'm
even nodding my head as I read. 

 

I've said it before, they invent this stuff faster than anyone can learn it.
Lets hope its heading in the right direction. For the children's sake.

 

On Sat, Feb 2, 2013 at 7:15 AM, Greg Keogh mailto:g...@mira.net> > wrote:

Folks, I'm pleased to see that other people here are irritated by the number
of choices we have for communication and by the complexity of WCF. I was
also pleased to see someone else was bewlidered by having WebAPI buried
inside MVC and found a way of starting with a managable skeleton project.

 

Luckily I can delay my confusion over using 

RE: SPAM-LOW Re: WCF service best practises

[Katherine Moss]

I thought that .net remoting is kind of out-of-date and shouldn't be used 
because of all of the new technologies.  Or is it out-of-date?  And now you're 
making me question my plans for my first Open Source project that I was going 
to put up in a year or two.  I was going to have it use WCF hosted as a Windows 
Service to talk to some other modules like ADLDS and stuff like that but now I 
should maybe rethink Project Jenks.  Or is WCF appropriate for talking to 
things like that?  Such as, one of my ideas for Jenks (it is going to be a 
bunch of things; modules that one can plug into a single interface as needed), 
is to create a sort of contact-management interface that links to both my web 
site (or any web site for that matter), and to ADLDS.  And for the ADLDS part, 
I would have it's directory access module piggy-back on Microsoft's provided 
web service interface.  PowerShell already uses it, but why not create another 
interface other than ADSIEdit for managing ADLDS  too?  So hopefully in the 
coming months and year, you should see something on CodePlex if I can ever get 
all of this backlog on learning programming out of the way.  I've been so busy 
and have had to give up some things for now due to prioritization. Programming 
is secondary to me at the moment, so it's more important that my Microsoft 
certification process gets underway.
From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Paul Glavich
Sent: Friday, February 01, 2013 10:10 PM
To: 'ozDotNet'
Subject: RE: SPAM-LOW Re: WCF service best practises

At the risk of being argumentative, we asked for this. Maybe not you or me 
specifically, but the community at large has. I agree the number of 
technologies at play, particularly in this space is large but it makes it all 
the more *interesting* to make those architectural choices. In some ways, less 
choice is better as the number of possibilities and combinations are less, thus 
decisions are more constrained and easier to get to.

However, the flexibility afforded to us now is great. The better technologies 
will rise, the lesser ones either improved, integrated or discarded and this is 
our task. In a properly architected system, the risk of choice of a 
communications technology can be mitigated. However, we are also human and can 
introduce dependencies where in hindsight, this was a bad thing. We live and 
learn. It goes back to the "circle of dev life" previously mentioned. Never 
believe the hype. Accept it for what it is, experience it, come to an informed 
decision based on that, and your educated judgement. Remember, .Net remoting is 
still there :)


-  Glav

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Stephen Price
Sent: Saturday, 2 February 2013 11:52 AM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

I must be getting old too Greg. Your rants are starting to make sense. I'm even 
nodding my head as I read.

I've said it before, they invent this stuff faster than anyone can learn it. 
Lets hope its heading in the right direction. For the children's sake.

On Sat, Feb 2, 2013 at 7:15 AM, Greg Keogh 
mailto:g...@mira.net>> wrote:
Folks, I'm pleased to see that other people here are irritated by the number of 
choices we have for communication and by the complexity of WCF. I was also 
pleased to see someone else was bewlidered by having WebAPI buried inside MVC 
and found a way of starting with a managable skeleton project.

Luckily I can delay my confusion over using WCF or whatever else is trendy this 
week, as the core working code of my service is actually inside a neutral DLL. 
I can write and test this code totally independly of how it will be published, 
then later I can wrap it in thin code to publish it in whatever ways I want. 
That will give me time to fiddle around with Web API.

Overall though, I'm getting utterly fed-up with the number of technologies, 
kits, standards, languages, scripts, dependencies, conventions, platforms, etc. 
Every month I get the MSDN magazine posted to me and I dread opening it to see 
how many dozen new acronymns have been invented and discover how all of my old 
apps are obsolete because there is a new and better things to do it.

I must be getting old too, as I pine for the previous decades of programming 
where there was less choice and everything just goddamn worked and was 
documented. Now I spend whole days futzing around to try something out or 
desperately searching the Internet for clues on an incomprehensible errors. 
There was a time when you could feel good as being a well-rounded programmer 
with good general knowledge. These days it's practically impossible to be 
well-rounded in every significant aspect of programming without experimenting 
and studying 18 hours every day and sk

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

At the risk of being argumentative, we asked for this. Maybe not you or me
specifically, but the community at large has. I agree the number of
technologies at play, particularly in this space is large but it makes it
all the more *interesting* to make those architectural choices. In some
ways, less choice is better as the number of possibilities and combinations
are less, thus decisions are more constrained and easier to get to.

 

However, the flexibility afforded to us now is great. The better
technologies will rise, the lesser ones either improved, integrated or
discarded and this is our task. In a properly architected system, the risk
of choice of a communications technology can be mitigated. However, we are
also human and can introduce dependencies where in hindsight, this was a bad
thing. We live and learn. It goes back to the "circle of dev life"
previously mentioned. Never believe the hype. Accept it for what it is,
experience it, come to an informed decision based on that, and your educated
judgement. Remember, .Net remoting is still there :)

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Stephen Price
Sent: Saturday, 2 February 2013 11:52 AM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

I must be getting old too Greg. Your rants are starting to make sense. I'm
even nodding my head as I read. 

 

I've said it before, they invent this stuff faster than anyone can learn it.
Lets hope its heading in the right direction. For the children's sake.

 

On Sat, Feb 2, 2013 at 7:15 AM, Greg Keogh mailto:g...@mira.net> > wrote:

Folks, I'm pleased to see that other people here are irritated by the number
of choices we have for communication and by the complexity of WCF. I was
also pleased to see someone else was bewlidered by having WebAPI buried
inside MVC and found a way of starting with a managable skeleton project.

 

Luckily I can delay my confusion over using WCF or whatever else is trendy
this week, as the core working code of my service is actually inside a
neutral DLL. I can write and test this code totally independly of how it
will be published, then later I can wrap it in thin code to publish it in
whatever ways I want. That will give me time to fiddle around with Web API.

 

Overall though, I'm getting utterly fed-up with the number of technologies,
kits, standards, languages, scripts, dependencies, conventions, platforms,
etc. Every month I get the MSDN magazine posted to me and I dread opening it
to see how many dozen new acronymns have been invented and discover how all
of my old apps are obsolete because there is a new and better things to do
it.

 

I must be getting old too, as I pine for the previous decades of programming
where there was less choice and everything just goddamn worked and was
documented. Now I spend whole days futzing around to try something out or
desperately searching the Internet for clues on an incomprehensible errors.
There was a time when you could feel good as being a well-rounded programmer
with good general knowledge. These days it's practically impossible to be
well-rounded in every significant aspect of programming without
experimenting and studying 18 hours every day and skipping eating and
bathing. It's like trying to understand every working part of a Jumbo Jet.
Instead of converging and stabilising in modern times, software development
is disintegrating into a jumble of parts, of which many are nearly
duplicated, conflicting, poorly documented, unstable, overly-complex,
inter-dependent and multi-versioned. I'm finding that the joy of computer
programming is being sucked out of me week by week. The thing that sh*ts me
most is what came out of the discussion weeks ago about how there is no
single reliable way of writing multi-platform software. To do that you have
to be boffin of C#, C, C++, JavaScript, Java and all of their supporting
kits.

 

Oh well, back to Silverlight 4 coding this morning ... and that's nearly
obsolete already!!

 

Greg

 

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

Your kinda missing the point. Abstracting is not just so you can swap out
another tech in its place. In fact, that aspect of abstraction is somewhat
of a practical fallacy but that is another thing.

 

Working with WCF and MSMQ is quite easy.

Using the same principles, you can work with TCP without having to know
strictly about TCP socket inner workings (although granted it certainly
helps)

Working with HTTP and WCF is also relatively easy and while WCF can do REST,
I would never use it for that. However, SOAP, and the WS-* stack are pretty
full featured and not so easy to implement. WCF hides a huge amount of that
complexity, one of the major goals of an abstraction. Your specific example,
while valid in your scenario, is specific and does not negate its benefits.
I have used WCF in many ways in enterprises with great success. I believe
there is also a set of relay bindings for the Azure service bus too so you
get to use those same concepts again.

 

Having said all that, if you don't like it, don't use it. Perhaps you chose
the wrong tech in the first place?

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of David Connors
Sent: Saturday, 2 February 2013 9:28 AM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

 

On Fri, Feb 1, 2013 at 7:44 PM, Paul Glavich mailto:subscripti...@theglavs.com> > wrote:

Webapi is a reaction to attitudes as described below.

 

[ ... ]

 

Ofcourse WCF can do REST too, you just have to twiddle a few hundred
different knobs on the right way. I would argue WCF is not bullshit. WCF
comprises way more than REST and has a very good feature set (albeit with a
some implementation flaws). Support for MSMQ, TCP, ServiceBus etc. all via
config is no easy feat.

 

>> you want to do an intermittently connected app then use some sort of
message queuing framework/system or roll your own 

And the circle of development life continues...

 

Abstractions are great when they exist for a genuine need. I'd much rather
write a computer game against DirectX than whatever nightmare you normally
use to talk to GPUs in assembly. I'd rather write a business app in terms of
SQL than managing structures on disk myself. The benefit of the scenario
with the abstraction vs without is decisive. 

 

However when abstractions are thought up by some egg heads in response to a
need that doesn't exist, then you end up with something like WCF. The cure
is worse than the disease. 

 

In the case of the two examples I provided above, the leverage you get from
the abstraction is clear. In the case of WCF abstracting rest - why? Even if
you wrote your REST calls directly using sockets, it is STILL trivial. If I
needed an intermittently connected app to use MSMQ, I could use MSMQ. How
many times have you heard of anyone writing an app and then after it is done
going "oh shit, we need to change the app to use SMTP instead of TCP
sockets." I mean WTF. Seriously. It is an abstraction that doesn't
abstraction for added productivity or anything else. 

 

Case in point. I recall helping the developer hired by one of our clients
get a WCF service up and running on some of our infrastructure. We spent a
couple of days beating our heads against why it was failing before finally
determining that WCF assumes the existence of an HTTP host header when
generating some of its own internal URLs (which is not normally present in
on a fixed dedicated IP brinding). Failing that it reverted back to using
the machine's netbios machine name in some of its internal comms, which was
failing (again, in a high end hosting scenario the internal machine name is
never going to resolve on the Internet and normally sit because an app
accelerator or firewall etc) . Completely retarded behaviour and purely in
existence in and of and because of the abstraction itself. I could have
written all of the end-point communication for the project myself in less
time than it took to resolve that one issue.

 

In the debrief with the client:

 says:

 I see what you mean when talking about how WCF can be difficult to work
with. It's been a huge learning experience for me.

David Connors @ codify.com <http://codify.com>  says:

 It is just too hard for what it does

 says:

 true

 

-- 

David Connors

da...@connors.com <mailto:da...@connors.com>  | M +61 417 189 363
 

Download my v-card: https://www.codify.com/cards/davidconnors

Follow me on Twitter: https://www.twitter.com/davidconnors

Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

I actually fully agree. I have been in the industry for a while now as well
and have seen the circle of dev life :) Kinda like clothes….. one day, those
blue spandex shorts will come back into fashion :)

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of Davy Jones
Sent: Friday, 1 February 2013 9:49 PM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

 

I must be getting old.

 

XML-rpc  (simple XML http)

XML-soap complex ish

Wcf. Really complex

Rest/Jason complex ish

Web API simple 

 

A full turn of the wheel in 12 years. 

 

I get a new intern on my team next week, I wonder what "new" ideas he will
bring. Maybe flat text config files? 

 

Davy the Older



Sent from my starfleet datapad.


On 1 févr. 2013, at 10:45, Paul Glavich mailto:subscripti...@theglavs.com> > wrote:

Webapi is a reaction to attitudes as described below.

 

People were foregoing WCF due to complexity and a variety of other reasons.
MVC was being used (with a bit of code) to produce simple JSON/XML Rest
api’s. The team took this onboard, altered their view of world as they were
writing the Web Web Api and thus we have WebApi. As with most things,
simplicity wins out and WebApi was the framework attempt at that.

 

Ofcourse WCF can do REST too, you just have to twiddle a few hundred
different knobs on the right way. I would argue WCF is not bullshit. WCF
comprises way more than REST and has a very good feature set (albeit with a
some implementation flaws). Support for MSMQ, TCP, ServiceBus etc… all via
config is no easy feat.

 

>> you want to do an intermittently connected app then use some sort of
message queuing framework/system or roll your own 

And the circle of development life continues…..

 

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com <mailto:ozdotnet-boun...@ozdotnet.com>
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors
Sent: Friday, 1 February 2013 9:10 AM
To: ozDotNet
Subject: SPAM-LOW Re: WCF service best practises

 

On Fri, Feb 1, 2013 at 7:23 AM, Craig van Nieuwkerk mailto:crai...@gmail.com> > wrote:

ASP.NET <http://ASP.NET>  WebAPI seems to be the new hotness. I don't have
much experience with WCF, but everyone I talk to says it is too heavy and
complicated. WebAPI tries to simplify things.

 

WCF is a bunch of bullshit. People who use it just do so for the sake of
adopting some shiny new technology - it is just pointless middleware for the
sake of it. I don't understand why it exists anyway - as if we are some day
doing to need to re-platform off tcp any time soon.

 

If I needed to do a lot of IPC stuff today I'd just use rest/json like
everyone else on the Internet. If you want to do something screaming fast,
use protobufs. If you want to do an intermittently connected app then use
some sort of message queuing framework/system or roll your own. I don't know
why a common API needs to sit on top of a bunch of unrelated use cases,
doing none of them very well.

 

$0.02. 

 

-- 

David Connors

da...@connors.com <mailto:da...@connors.com>  | M +61 417 189 363

Download my v-card: https://www.codify.com/cards/davidconnors

Follow me on Twitter: https://www.twitter.com/davidconnors

Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

Re: SPAM-LOW Re: WCF service best practises

[Stephen Price]

I must be getting old too Greg. Your rants are starting to make sense. I'm
even nodding my head as I read.

I've said it before, they invent this stuff faster than anyone can learn
it. Lets hope its heading in the right direction. For the children's sake.


On Sat, Feb 2, 2013 at 7:15 AM, Greg Keogh  wrote:

> Folks, I'm pleased to see that other people here are irritated by the
> number of choices we have for communication and by the complexity of WCF. I
> was also pleased to see someone else was bewlidered by having WebAPI buried
> inside MVC and found a way of starting with a managable skeleton project.
>
> Luckily I can delay my confusion over using WCF or whatever else is trendy
> this week, as the core working code of my service is actually inside a
> neutral DLL. I can write and test this code totally independly of how it
> will be published, then later I can wrap it in thin code to publish it in
> whatever ways I want. That will give me time to fiddle around with Web API.
>
> Overall though, I'm getting utterly fed-up with the number of
> technologies, kits, standards, languages, scripts, dependencies,
> conventions, platforms, etc. Every month I get the MSDN magazine posted to
> me and I dread opening it to see how many dozen new acronymns have been
> invented and discover how all of my old apps are obsolete because there is
> a new and better things to do it.
>
> I must be getting old too, as I pine for the previous decades of
> programming where there was less choice and everything just goddamn worked
> and was documented. Now I spend whole days futzing around to try something
> out or desperately searching the Internet for clues on an incomprehensible
> errors. There was a time when you could feel good as being a well-rounded
> programmer with good general knowledge. These days it's practically
> impossible to be well-rounded in every significant aspect of programming
> without experimenting and studying 18 hours every day and skipping eating
> and bathing. It's like trying to understand every working part of a Jumbo
> Jet. Instead of converging and stabilising in modern times, software
> development is disintegrating into a jumble of parts, of which many are
> nearly duplicated, conflicting, poorly documented, unstable,
> overly-complex, inter-dependent and multi-versioned. I'm finding that the
> joy of computer programming is being sucked out of me week by week. The
> thing that sh*ts me most is what came out of the discussion weeks ago about
> how there is no single reliable way of writing multi-platform software. To
> do that you have to be boffin of C#, C, C++, JavaScript, Java and all of
> their supporting kits.
>
> Oh well, back to Silverlight 4 coding this morning ... and that's nearly
> obsolete already!!
>
> Greg
>

Re: SPAM-LOW Re: WCF service best practises

[Greg Keogh]

Folks, I'm pleased to see that other people here are irritated by the
number of choices we have for communication and by the complexity of WCF. I
was also pleased to see someone else was bewlidered by having WebAPI buried
inside MVC and found a way of starting with a managable skeleton project.

Luckily I can delay my confusion over using WCF or whatever else is trendy
this week, as the core working code of my service is actually inside a
neutral DLL. I can write and test this code totally independly of how it
will be published, then later I can wrap it in thin code to publish it in
whatever ways I want. That will give me time to fiddle around with Web API.

Overall though, I'm getting utterly fed-up with the number of technologies,
kits, standards, languages, scripts, dependencies, conventions, platforms,
etc. Every month I get the MSDN magazine posted to me and I dread opening
it to see how many dozen new acronymns have been invented and discover how
all of my old apps are obsolete because there is a new and better things to
do it.

I must be getting old too, as I pine for the previous decades of
programming where there was less choice and everything just goddamn worked
and was documented. Now I spend whole days futzing around to try something
out or desperately searching the Internet for clues on an incomprehensible
errors. There was a time when you could feel good as being a well-rounded
programmer with good general knowledge. These days it's practically
impossible to be well-rounded in every significant aspect of programming
without experimenting and studying 18 hours every day and skipping eating
and bathing. It's like trying to understand every working part of a Jumbo
Jet. Instead of converging and stabilising in modern times, software
development is disintegrating into a jumble of parts, of which many are
nearly duplicated, conflicting, poorly documented, unstable,
overly-complex, inter-dependent and multi-versioned. I'm finding that the
joy of computer programming is being sucked out of me week by week. The
thing that sh*ts me most is what came out of the discussion weeks ago about
how there is no single reliable way of writing multi-platform software. To
do that you have to be boffin of C#, C, C++, JavaScript, Java and all of
their supporting kits.

Oh well, back to Silverlight 4 coding this morning ... and that's nearly
obsolete already!!

Greg

Re: SPAM-LOW Re: WCF service best practises

[David Connors]

On Fri, Feb 1, 2013 at 7:44 PM, Paul Glavich wrote:

> Webapi is a reaction to attitudes as described below.
>
>
[ ... ]


> Ofcourse WCF can do REST too, you just have to twiddle a few hundred
> different knobs on the right way. I would argue WCF is not bullshit. WCF
> comprises way more than REST and has a very good feature set (albeit with a
> some implementation flaws). Support for MSMQ, TCP, ServiceBus etc… all via
> config is no easy feat.
>
> ** **
>
> >> you want to do an intermittently connected app then use some sort of
> message queuing framework/system or roll your own 
>
> And the circle of development life continues…..
>

Abstractions are great when they exist for a genuine need. I'd much rather
write a computer game against DirectX than whatever nightmare you normally
use to talk to GPUs in assembly. I'd rather write a business app in terms
of SQL than managing structures on disk myself. The benefit of the scenario
with the abstraction vs without is decisive.

However when abstractions are thought up by some egg heads in response to a
need that doesn't exist, then you end up with something like WCF. The cure
is worse than the disease.

In the case of the two examples I provided above, the leverage you get from
the abstraction is clear. In the case of WCF abstracting rest - why? Even
if you wrote your REST calls directly using sockets, it is STILL trivial.
If I needed an intermittently connected app to use MSMQ, I could use MSMQ.
How many times have you heard of anyone writing an app and then after it is
done going "oh shit, we need to change the app to use SMTP instead of TCP
sockets." I mean WTF. Seriously. It is an abstraction that doesn't
abstraction for added productivity or anything else.

Case in point. I recall helping the developer hired by one of our clients
get a WCF service up and running on some of our infrastructure. We spent a
couple of days beating our heads against why it was failing before finally
determining that WCF assumes the existence of an HTTP host header when
generating some of its own internal URLs (which is not normally present in
on a fixed dedicated IP brinding). Failing that it reverted back to using
the machine's netbios machine name in some of its internal comms, which was
failing (again, in a high end hosting scenario the internal machine name is
never going to resolve on the Internet and normally sit because an app
accelerator or firewall etc) . Completely retarded behaviour and purely in
existence in and of and because of the abstraction itself. I could have
written all of the end-point communication for the project myself in less
time than it took to resolve that one issue.

In the debrief with the client:
 says:
 I see what you mean when talking about how WCF can be difficult to work
with. It's been a huge learning experience for me.
David Connors @ codify.com says:
 It is just too hard for what it does
 says:
 true

-- 
David Connors
da...@connors.com | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

RE: SPAM-LOW Re: WCF service best practises

[Katherine Moss]

But then with all of these, you have to also think of Microsoft's new Service 
Bus for Windows server (used to only be on Azure).  This supports I think some 
of the things that WCF never did such as publish/subscribe.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Davy Jones
Sent: Friday, February 01, 2013 5:49 AM
To: ozDotNet
Subject: Re: SPAM-LOW Re: WCF service best practises

I must be getting old.

XML-rpc  (simple XML http)
XML-soap complex ish
Wcf. Really complex
Rest/Jason complex ish
Web API simple

A full turn of the wheel in 12 years.

I get a new intern on my team next week, I wonder what "new" ideas he will 
bring. Maybe flat text config files?

Davy the Older


Sent from my starfleet datapad.

On 1 févr. 2013, at 10:45, Paul Glavich 
mailto:subscripti...@theglavs.com>> wrote:
Webapi is a reaction to attitudes as described below.

People were foregoing WCF due to complexity and a variety of other reasons. MVC 
was being used (with a bit of code) to produce simple JSON/XML Rest api's. The 
team took this onboard, altered their view of world as they were writing the 
Web Web Api and thus we have WebApi. As with most things, simplicity wins out 
and WebApi was the framework attempt at that.

Ofcourse WCF can do REST too, you just have to twiddle a few hundred different 
knobs on the right way. I would argue WCF is not bullshit. WCF comprises way 
more than REST and has a very good feature set (albeit with a some 
implementation flaws). Support for MSMQ, TCP, ServiceBus etc... all via config 
is no easy feat.

>> you want to do an intermittently connected app then use some sort of message 
>> queuing framework/system or roll your own
And the circle of development life continues.



-  Glav

From: ozdotnet-boun...@ozdotnet.com<mailto:ozdotnet-boun...@ozdotnet.com> 
[mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of David Connors
Sent: Friday, 1 February 2013 9:10 AM
To: ozDotNet
Subject: SPAM-LOW Re: WCF service best practises

On Fri, Feb 1, 2013 at 7:23 AM, Craig van Nieuwkerk 
mailto:crai...@gmail.com>> wrote:
ASP.NET<http://ASP.NET> WebAPI seems to be the new hotness. I don't have much 
experience with WCF, but everyone I talk to says it is too heavy and 
complicated. WebAPI tries to simplify things.

WCF is a bunch of bullshit. People who use it just do so for the sake of 
adopting some shiny new technology - it is just pointless middleware for the 
sake of it. I don't understand why it exists anyway - as if we are some day 
doing to need to re-platform off tcp any time soon.

If I needed to do a lot of IPC stuff today I'd just use rest/json like everyone 
else on the Internet. If you want to do something screaming fast, use 
protobufs. If you want to do an intermittently connected app then use some sort 
of message queuing framework/system or roll your own. I don't know why a common 
API needs to sit on top of a bunch of unrelated use cases, doing none of them 
very well.

$0.02.

--
David Connors
da...@connors.com<mailto:da...@connors.com> | M +61 417 189 363
Download my v-card: https://www.codify.com/cards/davidconnors
Follow me on Twitter: https://www.twitter.com/davidconnors
Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

Re: SPAM-LOW Re: WCF service best practises

[Davy Jones]

I must be getting old.

XML-rpc  (simple XML http)
XML-soap complex ish
Wcf. Really complex
Rest/Jason complex ish
Web API simple

A full turn of the wheel in 12 years.

I get a new intern on my team next week, I wonder what "new" ideas he will
bring. Maybe flat text config files?

Davy the Older


Sent from my starfleet datapad.

On 1 févr. 2013, at 10:45, Paul Glavich  wrote:

Webapi is a reaction to attitudes as described below.



People were foregoing WCF due to complexity and a variety of other reasons.
MVC was being used (with a bit of code) to produce simple JSON/XML Rest
api’s. The team took this onboard, altered their view of world as they were
writing the Web Web Api and thus we have WebApi. As with most things,
simplicity wins out and WebApi was the framework attempt at that.



Ofcourse WCF can do REST too, you just have to twiddle a few hundred
different knobs on the right way. I would argue WCF is not bullshit. WCF
comprises way more than REST and has a very good feature set (albeit with a
some implementation flaws). Support for MSMQ, TCP, ServiceBus etc… all via
config is no easy feat.



>> you want to do an intermittently connected app then use some sort of
message queuing framework/system or roll your own

And the circle of development life continues…..





-  Glav



*From:* ozdotnet-boun...@ozdotnet.com
[mailto:ozdotnet-boun...@ozdotnet.com]
*On Behalf Of *David Connors
*Sent:* Friday, 1 February 2013 9:10 AM
*To:* ozDotNet
*Subject:* SPAM-LOW Re: WCF service best practises



On Fri, Feb 1, 2013 at 7:23 AM, Craig van Nieuwkerk 
wrote:

ASP.NET WebAPI seems to be the new hotness. I don't have much experience
with WCF, but everyone I talk to says it is too heavy and complicated.
WebAPI tries to simplify things.



WCF is a bunch of bullshit. People who use it just do so for the sake of
adopting some shiny new technology - it is just pointless middleware for
the sake of it. I don't understand why it exists anyway - as if we are some
day doing to need to re-platform off tcp any time soon.



If I needed to do a lot of IPC stuff today I'd just use rest/json like
everyone else on the Internet. If you want to do something screaming fast,
use protobufs. If you want to do an intermittently connected app then use
some sort of message queuing framework/system or roll your own. I don't
know why a common API needs to sit on top of a bunch of unrelated use
cases, doing none of them very well.



$0.02.



-- 

David Connors

da...@connors.com | M +61 417 189 363

Download my v-card: https://www.codify.com/cards/davidconnors

Follow me on Twitter: https://www.twitter.com/davidconnors

Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors

RE: SPAM-LOW Re: WCF service best practises

[Paul Glavich]

Webapi is a reaction to attitudes as described below.

 

People were foregoing WCF due to complexity and a variety of other reasons.
MVC was being used (with a bit of code) to produce simple JSON/XML Rest
api's. The team took this onboard, altered their view of world as they were
writing the Web Web Api and thus we have WebApi. As with most things,
simplicity wins out and WebApi was the framework attempt at that.

 

Ofcourse WCF can do REST too, you just have to twiddle a few hundred
different knobs on the right way. I would argue WCF is not bullshit. WCF
comprises way more than REST and has a very good feature set (albeit with a
some implementation flaws). Support for MSMQ, TCP, ServiceBus etc. all via
config is no easy feat.

 

>> you want to do an intermittently connected app then use some sort of
message queuing framework/system or roll your own 

And the circle of development life continues...

 

 

-  Glav

 

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com]
On Behalf Of David Connors
Sent: Friday, 1 February 2013 9:10 AM
To: ozDotNet
Subject: SPAM-LOW Re: WCF service best practises

 

On Fri, Feb 1, 2013 at 7:23 AM, Craig van Nieuwkerk mailto:crai...@gmail.com> > wrote:

ASP.NET   WebAPI seems to be the new hotness. I don't have
much experience with WCF, but everyone I talk to says it is too heavy and
complicated. WebAPI tries to simplify things.

 

WCF is a bunch of bullshit. People who use it just do so for the sake of
adopting some shiny new technology - it is just pointless middleware for the
sake of it. I don't understand why it exists anyway - as if we are some day
doing to need to re-platform off tcp any time soon.

 

If I needed to do a lot of IPC stuff today I'd just use rest/json like
everyone else on the Internet. If you want to do something screaming fast,
use protobufs. If you want to do an intermittently connected app then use
some sort of message queuing framework/system or roll your own. I don't know
why a common API needs to sit on top of a bunch of unrelated use cases,
doing none of them very well.

 

$0.02. 

 

-- 

David Connors

da...@connors.com   | M +61 417 189 363

Download my v-card: https://www.codify.com/cards/davidconnors

Follow me on Twitter: https://www.twitter.com/davidconnors

Connect with me on LinkedIn: http://au.linkedin.com/in/davidjohnconnors