The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
They are wrong. WCF is... DEADBORN. So it's hard to say "zombie is alive/not alive", it's just zombie who fed by MS money and enthusiasm of stupids.
We already have more than enough - TCP/IP, SOAP, JSON-RPC and even Protocol buffers from Google students. WHY MORE?! I say why - to hold stronger your eggs on MS hooks. Period. No any tech reason exist to jump on another "order of bytes in a stream".
I see a lot of stupid statements on the Internet. While it is certainly true that WCF has fallen out of the shiny favor. But that is far from dead. Many of those probably believe that soon everything on the internet will be done through a restful http interface.
We are just switching to it for our JSON communication and love it.
The configuration is pretty easy now. Used to be harder but now it is simpler.
It also has cool AOP features, such as that ability to manipulate all packets before the WCF service even sees it with a message inspector. SignalR might be simpler at first glance, but does it have such AOP features? Can I authenticate all web services in one piece of code without adding a single line of code in each of my services?
The feature set of WCF is huge and pretty much blows away anything else on the market.
[Authentication Token Service for WCF Services (Part 1)](http://www.rhyous.com/2015/02/05/basic-token-service-for-wcf-services-part-1)
Personally I prefer message queues these days. Several people have mentioned SignalR, and the hub could be considered a broker of sorts I guess. I've recently used both RabbitMQ (via the EasyNetQ library) and NetMQ to build microservices. For [potentially] load balanced services over a network, I prefer Rabbit. For single-process service containers (sounds strange at first, but we use in-process microservices at work to make individual components completely self-contained, allowing parallel development by many teams) I like using NetMQ with inproc sockets. NetMQ is also capable of TCP connections but IMHO the monitoring tools are not as good as the ones available for Rabbit.
So, to answer the original question - is WCF dead? I don't think so. I think it's similar to WPF; not dead, but nobody is really working on new features or improvements either.
Okay, I am actually amazed that, after considerable Googling, Amazoning, and SafariBooksOnlining, I have been unable to find a book that covers this topic with much depth at all. All the SW design and architecture books that I have come across start with the assumption that the requirements of the product are fully-formed in the mind of the architect (or at least the customer). So they dive right into architecutral specifications and object-oriented design principles (agile, or otherwise), and they skip right over the preliminary stage of "Idea Development".
I want a book that starts back at the seed of an idea, and then explains how to germinate it and cultivate it and bring it to reality.
I am in a situation (and I don't think it's rare) where the customer (a scientist, in this case) has an inkling of an idea of what he needs (and it's pretty complex, and he's fairly certain that the solution is going to require custom software) but that's all. So my job at this point is to help nurture his idea along. He doesn't yet have a full-fledged vision of what the tool should look like, just some vague business objectives that he still has a hard time articulating in any concrete way. He is still unsure whether a solution might already exist (a COTS tool), whether he might solve his problem with a conglomeration of Excel workbook macros, or whether he needs me to build a fully-architected .NET application. (Knowing a good deal about the complexity of the problem, I personally believe it is going to be the latter; but I'm trying not to inject my bias too forcefully at this stage.)
I've done a lot of SW design and architecture before, but this is going to require a different toolset altogether: I need to help my customer take an inherently nebulous problem and "knead" it until he can succinctly define what he needs, precisely characterize a viable solution, and articulate a succinct vision for the entire project.
So in this respect, I'm not just the SW architect, I'm the Greenfield Vision Consultant. If you've even run across a good book that addresses this facet of SW Design, I'd love to kmow about it.
I can't recommend a book however one thing I learnt, in my last job working with scientists, that saved me a few times, was how to approach developing something from scratch.
You probably know this and if it comes across as patronising then I apologise - what I learnt was find out what he needs to do, not what he wants or even how he wants to do it. If you can find out what he needs to do then you might find that the solution presents itself and writing the solution should be easier.
It also depends on which branch of science he works in. My experience with biological scientists was that they were very good at understanding high volumes of complex information, however as they were used to following prescribed recipes(using lab books) for their work they were not as used to thinking their way around problems as the some of chemists I interacted with who tended to have a better understanding of mathematics and logic.
I would also say that as long as you stick to SOLID[^] software engineering principles you will be fine from the software side - it should also make it easier when he changes his mind.
“That which can be asserted without evidence, can be dismissed without evidence.”
I don't have any book recommendations, but I have done this kind of development many times in my 25+ year career. My degree is in chemistry, and I have worked on scientific software in the past.
I start by collecting a list of "stuff the software needs to do". It is a high level list of what the scientist wants the software to do, such as "document some stuff", "read data from instruments", "perform calculations", "output reports". Explore each of these areas with the scientist to get more detail. Try to get an idea for the type of data you will need to handle in each "stuff the software needs to do" (network data, document data, key/value pair data, or maybe just regular old rdbms data). Now that you have a better idea about what needs to be done and what kind of data you will be handling, try to imagine the types of software best suited for each of the things (web ui/ mobile app/ databases/ services).
You should start imagining how the different pieces will interact with each other, and deciding on an architecture for ui/data/services. There may be many different pieces, and each of them may use different tools (db, ui, services). Try to split out reusable parts into services so you can use them from web, desktop, or mobile clients; you can always run the services locally if you end up with a desktop-only system.
Now as you start, keep things as simple as possible; do not introduce ANY unneeded complexity (especially imagined future complexity). If you include complexity early, design changes will be MUCH more difficult as you continue, but if you keep it simple as you go, it will be easy to modify as you discover new necessary features. Simplicity goes for the data as well; do not introduce some large db framework early, but wait until as late as possible. For example, with .Net, linq2sql is simple and flexible for fast progress. You may need to change to Entity Framework later, but it is much easier to update data structures in linq2sql than in Entity Framework (which has some issues with the update process). This will keep progress moving forward without drag from tool issues as changes will be happening very quickly in the early stages.
As you continue, you will be able to refine your ideas about the amount of work involved, the time it will take to complete, and start setting milestones for continued development.
Thanks for the ideas, Scott. It's that starting paragraph that I am wrestling with right now (compiling the "what it needs to do" list). I suppose I was hoping for some step-by-step guidelines to help me navigate that jungle. But I guess it probably just boils down to good ol' brainstorming.
I know you are going to think that the book is just about some methodology, but you have to see who wrote the book (Booch is one of the authors). Also, please don't focus on the fact that it mentions a methodology name. Methodology names are not important.
The process and what you learn from it is what is so valuable.
1. This book is all about thinking about how to approach an entire project.
2. It's about how to pull it all together while thinking from various stakeholder's positions.
The authors have a lot of experience between them and it's a very good read.
I think you'll find it quite informative and the next level of what you are looking for.
Hover to the upper left and you will see a green/red arrows, alright triangles, click the green one. The red one has been disabled due to abuse. This up ticks his reputation which is the only way to reward a good response.
Never underestimate the power of human stupidity