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] 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
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.commailto: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 g...@mira.netmailto: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
RE: SPAM-LOW Re: WCF service best practises
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 g...@mira.net 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
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
On Sat, Feb 2, 2013 at 2:09 PM, Paul Glavich subscripti...@theglavs.comwrote: 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
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 crai...@gmail.com 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
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 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.comozdotnet-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 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
RE: SPAM-LOW Re: WCF service best practises
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 subscripti...@theglavs.commailto: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.commailto: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 crai...@gmail.commailto:crai...@gmail.com wrote: ASP.NEThttp://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.commailto: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
On Fri, Feb 1, 2013 at 7:44 PM, Paul Glavich subscripti...@theglavs.comwrote: 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: changed to protect the guilty 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 changed to protect the guilty 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
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
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 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
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 subscripti...@theglavs.com 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 apis. 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 crai...@gmail.com 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
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 subscripti...@theglavs.com 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: changed to protect the guilty 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 changed to protect the guilty says: true -- David Connors da...@connors.com mailto:da...@connors.com | M +61 417 189 363 tel:%2B61%20417%20189%20363 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
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 g...@mira.net 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: WCF service best practises
What about the death of WCF as everything else in the modern technological landscape seems to be dying? Is WCF another one? Sorry to butt in, but I figure why waste your time? Or are you wasting it? Is WCF still common and worth learning? From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Wednesday, January 30, 2013 5:08 PM To: ozDotNet Subject: WCF service best practises Folks, I have created the stub of a WCF service that I've sanity checked is working okay when hosted in IIS, Azure, a Windows Service and even the command promt. It will be consumed by desktop apps and Silverlight. The initial code came out of the VS2012 new project template and I just started adding methods. It mostly moves plain POCO and DTO classes back-and-forth to manipulate a database. Before I go any further, I just wanted to check here that I'm not missing any recent advances in techniques for writing WCF services that will future proof it, follow best practises and make life easier for myself. So I'm just fishing for general comments from anyone who was written some serious services. Web searches produce these links, but I haven't had time to digest them yet: http://bloggingabout.net/blogs/gerben/archive/2010/02/01/wcf-best-practices.aspx http://www.codeproject.com/Articles/317232/How-to-Build-Flexible-and-Reusable-WCF-Services http://www.devproconnections.com/article/windows-communication-foundation-wcf2/Implementing-SOA-Patterns-with-WCF-and-NET-4-0-125163 (and many more) Greg
Re: WCF service best practises
What about the death of WCF as everything else in the modern technological landscape seems to be dying? Is WCF another one? Everything that dies has to be replaced in some form or another. If WCF is dying, what's its replacement? If I want to publicly expose my .NET service over the wire, what else can I use? SOAP, Sockets, Remoting, REST, two tin cans and a string? I'm I missing some gossip about sweeping changes in this area? If anyone knows, please speak up. Greg
Re: WCF service best practises
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. On Fri, Feb 1, 2013 at 7:50 AM, Greg Keogh g...@mira.net wrote: What about the death of WCF as everything else in the modern technological landscape seems to be dying? Is WCF another one? Everything that dies has to be replaced in some form or another. If WCF is dying, what's its replacement? If I want to publicly expose my .NET service over the wire, what else can I use? SOAP, Sockets, Remoting, REST, two tin cans and a string? I'm I missing some gossip about sweeping changes in this area? If anyone knows, please speak up. Greg
RE: WCF service best practises
http://xkcd.com/927/ Cheers Ken From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Friday, 1 February 2013 8:53 AM To: ozDotNet Subject: Re: WCF service best practises They've been flogging WebAPI in recent MSDN magazines, but I got the impression that it's just REST more formalised with contracts. Perhaps this makes sense from the hints I've been reading. WCF is heavy and complicated and over-engineered to be general purpose (which is fine and I've benefited from that). REST is consumable by everyone, but it's a typeless mess. Putting some structure over REST and giving it a name sounds like a typical progression. Oh well, I'd better start converting my brand new code to yet another standard. You can't have too many standards I reckon. Greg
