Server side WCF #1200
Comments
|
Hi, I too appreciate WCF, and use it a lot.
I think this could really be a showstopper for .Net core, if it will not have WCF server side support. Guy |
|
Helllo, We also use WCF extensively in our applications.
Menahem |
|
WCF applications on Core would be a huge boon. The only thing I would explicitly like to add to the OP's features are all of the behavior types (not just the ones available in Service Fabric)
I distributed transactions are a prohibitive factor, they can be thrown out the window though. |
|
Service Bus binding of WCF is absolutely amazing for building push based reactive applications |
|
I do consider a full WCF implementation to be a prerequisite for moving to .NET core. Without it, it will remain a variation of the .NET Framework that cannot be utilized behind the firewall of major enterprise applications that employ Service Orientation. The major features I rely on that haven't been mentioned are:
The two bindings are required to enable the efficiency of communication that Service Oriented systems require behind the firewall. The interception is critical to allow architects to provide the necessary aspects of the system in a way that does not require the developers to do anything except code as they normally would. Contexts and Headers are required to propagate information that is ubiquitous through the application’s stack from the client layer all the way down to the data layer and back up again without affecting the call contracts. Here, I’m thinking about identity information as a universal example. The contract-based coding model is really necessary to avoid going back to the string-parsing voodoo that had us living in a type-uncertain, data-validity-in-question wild-west back when Microsoft thought passing hash tables to and from SOAP web services was a good idea. |
|
Thanks for input. The implementation of back-end systems needs a mature communication stack, such as WCF. As you pointed out in the thread, a .NET Core positioned on the client side is in my mind taking away the potential of what .NET Core can be. I'm sure we all can wire basic communication (TCP, HTTP, ...) and then get bogged down into details about message parsing, to get some implementation of back-end on .NET Core. I'll stick my neck out and claim that WCF takes a lot of plumbing away from development (reduces waste and error prone code), letting us focus on business value. That is the reason why I enjoy WCF so much, and really would love to see support for server side WCF in .NET Core, rather sooner than later. |
|
Thanks for all the feedback on WCF Server top features! Keep it coming! Providing WCF Server support for .NET Core is on the radar. As you know, our current POR is to provide the WCF client-side libraries in .NET Core to enable UWP/ ASP.NET Core/.NET Core applications to call .NET Framework based WCF Services. We are very interested to better understand your scenarios where WCF server side functionality is required. |
|
A specific business case I have is that we have an investment management system with several million lines of code for which the server side is currently hosted on premise on MS Windows Servers at about 200 insurance companies and banks world wide. We have about 100+ service types, of which in the largest installations there are 700 to 800 concurrent service instances at play. Our product is driving important parts of the core businesses. The expenditure on IT is huge for our customers. This is also the place where we are looking to make major improvements over the coming years. A part of that is to find alternative hosting environments. A favorable choice would be Windows Nano, or the .NET Core on Linux. For being able to adopt .NET Core (or Windows Nano) we are missing the WCF server side. Since we are very happy with WCF as a programming model, there is no incentive to rewrite our applications other than that WCF server side is unavailable in our future hosting environments. Particular features that we use is long. But to start .NET Core adoption are, these are the important ones:
Yes. We would continue building WCF services also on .NET Core. |
|
In my case it is needed for new solutions, where WCF services can be agnostic deployed (Windows, Linux, OSX, cloud) on .NET Core. |
|
Over the past 6 years, in the solutions I have been involved in (in the .net area), we have always relied on WCF to handle the service layer (behind the firewall & intranet) of the solutions. Nothing out there gives us the same level of flexibility and support for different communication channels like WCF does. I have been holding back moving to .net core for production environments for the lack of WCF support specifically. Not supporting WCF server on .net core creates a need to rewrite a lot of infrastructure code; which will probably end up mimicking the WCF programming model anyway. The biggest solution I worked on was used by over 300 health care institutes, rewriting the server layers and functionalities is a big investment to say the least, not to mention high risk. |
|
My scenario is pretty much similar to @olilanz's, except that my business case is Point of Sales. Like him, we have our application deployed to numerous stores world wide. We are also looking for alternate ways of hosting our application in order to reduce infrastructure costs. As @jan-johansson-mr said, agnostic deploying WCF services would be great and would give us a huge flexibility. WCF plays a major role in our application: it is based on a plug-in architecture where which plug-in is basically a WCF Service, so communication between plug-ins are actually WCF calls. Changing this aspect would mean have to rewrite/rethink a lot of infrastructure code. In our case, self hosting using instances of ServiceHost and the Contract based programming model is crucial. Our plan is not only migrate existing services, but also create new services. |
|
Hi, For us the most important features are:
Responding to Erica:
Thanks! |
|
I have done a lot of projects that leverage the many aspects of WCF. Most of what I leverage in WCF (pretty much everything) is currently missing from .NET Core. Much of this missing capability would require various 3rd party libraries (or extensive custom code) to fill in the gaps and it's just not worth that level of investment when WCF already works, brilliantly. WCF is, above all else, a great productivity enhancer for my teams. The biggest piece missing for me, currently, is the extensibility model that WCF provides. We also leverage many other aspects of WCF such as: Without WCF (or equivalent capabilities) in .NET core I would lose way too much productivity and cannot justify the switch. It would be great to have all of these powerful capabilities in a platform that can be used in any type of environment. Imagine, productivity of WCF plus cost-savings of cheaper hosting environments. That is a tremendous business value. Thanks for tracking this issue, |
|
I agree with @websitewill as I am in that exact situation. I'd also like to point out that WCF in the full .NET Framework is done, finished, complete. If that spec were implemented to the letter in .NET Core I'd be very content and would be able to start transitioning projects. Thanks, |
|
I have to throw my support for WCF in .NET Core as well. My primary client is a fairly large, heterogeneous WAN with intermittent connectivity. I have dreamed for years of having WCF across their entire network so that I can finally (!) have reliable transactions and durable services spanning their various generations of Linux and Windows. The thought of bringing all of WCF's many capabilities (as enumerated in this thread) to my client's entire infrastructure would literally be a dream come true. We can spend the vast efforts we've previously put toward plumbing into the services that can streamline everything we do, and take us to the next level. Please, please make this happen. -Thomas |
|
Let me also mention the value of WCF in .NET core. WCF gives the best capabailities across all my services. (Perhaps we need a sexier name for it) but in general, I use and wish to continue to use:
And when we can run these services on Linux (and eventually IOS), it allows the most solid framework Paul |
|
Having WCF on .Net core is not only desirable, it is essential. At it's current state WCF is THE most universal and mature framework to communicate between devices, and within devices using Named Pipes. Over the wire, it adheres to common standards allowing other platforms to communicate as well. But with WCF running in .Net core, the choice will be easy to make. |
|
We have a strong need to run .NET/WCF on Linux, so please add this to the road map! We have invested heavily in WCF over the past decade and would hate to give up all the WCF benefits others have listed so well just because this was passed over by .NET Core. We use most features and benefit greatly from being able to customize/extend the framework to suit our needs, such as custom message broker support (alternatives to MSMQ). |
|
Having WCF supported in .NET Core is a great idea and my list of key features are: Security |
|
Our team used WCF to build an entire SOA platform. Each service is hosted in it's own app domain that provides complete isolation for every service. This allowed us to monitor resources, per service, and unload a service and swap it out with the app hot. I know app domains are gone, but what could possibly replace wcf? Service Bus + Net Messaging Binding you have a super reliable, and extendable set of tools. wcf provides the best tools for building enterprise applications. Without it, you simply end up rebuilding it. Bringing the power of wcf to other platforms would be huge. Linux + sql + wcf + service bus + .net core looks good to me. |
|
I'm curious. From what I understand, Azure itself is written, in large part, usIng WCF (or at least something that provides all the capabilities of WCF) behind the firewall. That being the case, why would it be excluded from .NET Core in the first place? Seems odd to exclude such a powerful and foundational toolset. Sent from my iPhone
|
|
Another use case could be, using WCF on a gateway like device for example in home automation using linux based controllers with an ARM CPU and 512MB memory is not that uncommon. Being able to use .NET core on those types of devices and using WCF to allow creating a SOA like programming model, making use of named pipes and allowing to move around context and create reliable communication could create a whole other way of working than the current C daemons, dbus communicating way of doing things. Using WCF could also than be used to for example let your app communicate with your WCF service in your house, for offline controlling. It would provide better integration with service bus allowing efficient communication to and from cloud based services. Bjorn |
|
We have quants writing server side code in Mono (they need cross platform) who were almost jumping up and down in glee with the introduction of .Net Core ... until I told them that it wouldn't support AppDomains, which they currently rely on heavily. The look on their faces was one of despair. I have showed them a viable alternative using WCF and named pipes (to give them the isolation they desire without compromising performance). They were even more interested when I showed them that they could then scale these services across machines and across platform (if WCF services were supported on Linux) So, this is blocking adoption of .NET Core in this scenario and we would be looking to port existing processes/services to .NET Core as well as developing new services using .NET Core. David |
|
My company (one of the largest financial product company) has huge investment in Linux/Ubuntu. The windows infrastructure is relatively tiny but has tons of WCF services running for business critical applications. Running WCF on .NET Core running in Linux environment is a huge benefit in integrating with other (non-windows) services and platform consolidation point of view. |
|
Thank you -- this is really great feedback and much appreciated. We hear you and are collating this feedback as well as reaching out to other known WCF customers. Especially useful are the specific features called out (e.g. queuing, transaction, etc.) because it allows us to prioritize and do targeted investigations. For the record, the "missing" features of the full .NET framework's WCF were not deliberately excluded from .NET Core WCF. Rather, the initial goal was to support all the existing Windows Store WCF API's on NET Core (which are all client-facing) before tackling other mission-critical features of WCF. It might help to know that much of the work of porting WCF features involves re-implementing OS-level libraries that WCF depends on (e.g. socket layer, cryptography, etc.) to allow it to work cross-platform. So lighting up WCF features usually involves replacing OS-level libraries for each platform first. It might help to think that the "W" in WCF is no longer a given in NET Core. This is one reason why it is so valuable to hear from you which features matter most, because it lets us investigate more deeply questions like "Which libraries are required to do feature X on Linux? OS X?, etc.". Please keep those suggestions and specific scenarios coming! |
|
|
+1 please provide a way for me to build on WCF and host on linux Having moved away from windows (an subsequently WCF) here are the things I miss the most and would love to have back. #1 bindings > named pipes in particular, then tcp |
I would like to add, I don't really care. I just use WCF as a marker to avoid an org / project / product etc :) |
|
"People seem to be throwing the word ‘enterprise’ around like it helps justify their need for WCF." If the enterprise already has a WCF SOA, then it does... |
Great thing about microsoft is they virtually never declare anything actually dead. They just move on, stop doing stuff and stop talking about stuff and eventually everyone "gets the message that wasn't directly said". Except silverlight. They declared that one,. ... which became the basis of coreclr! undead :) |
|
full-featured, singular communication stack into .NET Core so we can host @websitewill : and I will add to that I would like greater reach! I was very disappointed when I sat down years ago to write my first store app, and found out it could not work with my infrastructure, no WCF in it. Same goes for core, UWP, all of it. I can't use any of that. The whole point of those technologies being in service would be to give me the ability to extend my infrastructure across platforms, have other types of clients orchestrated by the infrastructure. This would be huge! |
|
This says much more about you than it does anything about any technology.
We are not here to educate those who insist upon remaining ignorant of good
tools. You can continue to drive screws with your hammer if you choose.
Move along.
…On Tue, Jan 9, 2018 at 11:59 AM, Damian Hickey ***@***.***> wrote:
WCF is not something that should be implemented in .NET Core.
I would like to add, I don't really care. I just use WCF as a marker to
avoid an org / project / product etc :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1200 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ASs0gWUt8yzrIytSPfPKRZkBUzkrKW17ks5tI5r5gaJpZM4Ikmmx>
.
--
*Will Comeaux* <websitewill@gmail.com>
LinkedIn <http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw>
Twitter <https://twitter.com/wilmercomeaux>
Facebook <http://www.facebook.com/WilmerComeaux>
|
|
Anyone who thinks Microsoft has "moved on" obviously hasn't talked with any
of the teams building Azure - leveraging LOTS of WCF behind it.
Hrmmmm.
…On Tue, Jan 9, 2018 at 12:02 PM, Damian Hickey ***@***.***> wrote:
people discuss if things are dead or not.
Great thing about microsoft is they virtually never declare anything
actually dead. They just move on, stop doing stuff and stop talking about
stuff and eventually everyone "gets the message that wasn't directly said".
Except silverlight. They declared that one,.
... which became the basis of coreclr! undead :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1200 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ASs0ge34XZpaxa9j2zJiEjpee8z4DQ7-ks5tI5uogaJpZM4Ikmmx>
.
--
*Will Comeaux* <websitewill@gmail.com>
LinkedIn <http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw>
Twitter <https://twitter.com/wilmercomeaux>
Facebook <http://www.facebook.com/WilmerComeaux>
|
|
"For HTTP web services, there's a better .NET Core version of it - ASP.NET TCP? System.Net.Sockets To me this reply is equal parts helpful and ridiculous. It's helpful because those things do what you say. It's ridiculous because it ignores that you call do all of them in WCF, WITHOUT CODE CHANGES. Want to offer a method via REST and IPC? Add a binding. |
|
Damianh ad hominem attacks aren't appreciated. |
|
And my lack of any public repositories means, what, exactly?
That I work for people who choose to not give away their code?
That I don't work on many open-source projects?
Kudos on your evidence of... What, exactly? :)
…On Tue, Jan 9, 2018 at 12:06 PM, Damian Hickey ***@***.***> wrote:
Sure thing @websitewill <https://github.com/websitewill>
[image: image]
<https://user-images.githubusercontent.com/57436/34733184-c5d451e6-f567-11e7-95fa-5e6139c5557a.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1200 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ASs0gWhNbF0dAit_tCtrg0GPJHyhCS9Vks5tI5yVgaJpZM4Ikmmx>
.
--
*Will Comeaux* <websitewill@gmail.com>
LinkedIn <http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw>
Twitter <https://twitter.com/wilmercomeaux>
Facebook <http://www.facebook.com/WilmerComeaux>
|
|
Let's stop with commenting on people in the thread (and that includes the finger pointing that X is old and you need to move to Y) before I lock the issue because it has descended into trolling and flaming. |
|
I remember reading some 2-3 years ago some MS document where the recommended framework to use for new web projects was WebAPi or Asp.Net MVC. WCF was mentioned in some legacy context. Personally, I think WCF does too much for its own good. Let me choose what I need. Allow me to switch easily some component for another in my app. |
|
Web API is for http services. This is not comparable in any meaningful way to the full WCF. |
|
For exposing service outside the fire, yes, of course. But gain, that's a
*very* small part of the concern WCF is used for.
IMO, I don't even use WCF for that part because yes, Web API (or now just
MVC).
That's focusing on only one tiny thing, which is the problem with this
thread as that's pretty much what most of the population knows about WCF,
which is a shame.
That's like saying .NET is only about int and string.
…On Tue, Jan 9, 2018 at 12:14 PM, Mike Mogosanu ***@***.***> wrote:
I remember reading some 2-3 years ago some MS document where the
*recommended* framework to use for *new web projects* was WebAPi or
Asp.Net MVC. WCF was mentioned in some legacy context.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1200 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ASs0ga3QVfGw8KiP9lBb0ZvmSJ9jXu55ks5tI557gaJpZM4Ikmmx>
.
--
*Will Comeaux* <websitewill@gmail.com>
LinkedIn <http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw>
Twitter <https://twitter.com/wilmercomeaux>
Facebook <http://www.facebook.com/WilmerComeaux>
|
|
@blowdart +1 for locking. It's going nowhere. |
|
Damian since you have no skin in the game and are being the most divisive here, I'd suggest banning you before locking those of us with business needs for WCF out of the WCF thread... |
|
This is about cross-platform WCF, as it is still available on the full fx, correct? It does not read as an indictment of WCF, its utility, programming model, or popularity. There is a valid question of whether the effort to de-Windows WCF is a sound investment. Given that it has the W right in the name, my instinct says it's not. |
|
The business needs have been expressed and the alternatives + market direction have been presented. I have lots of skin in the .net game. I strongly feel that WindowsCF has no place in .net core for it to be competitive in the cloud landscape and for the type of community it need to (re-)attract. Its available and supported (but not actively developed) on .net desktop. Continue with that. Final thing I can say is - look where the puck is going. |
|
@sapiens yes! And, that has been a continuing issue. Like any other large organization, we can expect that MS will not always have their message completely aligned with reality. Remember way back when WCF came out? MS marketed it as being 'all about web services'. Which, in fact, they had invented something completely different. WCF had almost nothing to do with web services. And yet, that fact remain lost even today. Look how many references to web services and SOAP have been made in this thread alone! WCF is actually an extensibility model, an extensible interception based pipeline. the first component oriented platform. I have had some interesting conversation with 'thought leaders' that originally said WebAPI was the wave of the future and that WCF / Service Fabric / etc was not needed. Those are also some of the same people that delivered addresses this year at conferences you all know of on those very topics: WCF / service fabric etc. It's not immediately obvious to everyone that not everything can be done over raw http interactions. So, yes, you have been given recommendations. But, you have to decide for your scenarios what is best. And I do use WebAPI, but, for a very specific purpose. Same can be said for WCF, Service Fabric, asp.net, etc. They're complimentary to each other but are very different things used for very different purposes and not really equatable or 100% comparable to each other in terms of feature sets or usage scenarios. |
|
That's a fair point and the topic of renaming it, IIRC, came up in this
thread.
About the only part of WCF that is really "windows-specific" is the fact
that it can very seamlessly interact with MSMQ via an OOTB binding -
something that could be made an auxiliary package. If you are targeting
MSMQ you aren't going to target .NET Core anyway, so that would be just
fine to use regular .net anyway. Everything else has a corollary in
non-windows, AFAIK.
On the other hand, if I did target .net core but still wanted to host on
windows instances, I want the ability to just configure a binding to
leverage MSMQ (along with bindings for other queue techs such as Rabbit,
Zero, Azure, SQS, etc).
Nothing in my actual code needs to care, at all. The beauty of WCF.
…On Tue, Jan 9, 2018 at 12:33 PM, Bryan Watts ***@***.***> wrote:
This is about cross-platform WCF, as it is still available on the full fx,
correct?
It does not read as an indictment of WCF, its utility, programming model,
or popularity.
There is a valid question of whether the effort to de-Windows WCF is a
sound investment. Given that it has the *W* right in the name, my
instinct says it's not.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1200 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ASs0gW593de-r-kJPgfdh6LqWO5bkBJmks5tI6L8gaJpZM4Ikmmx>
.
--
*Will Comeaux* <websitewill@gmail.com>
LinkedIn <http://www.linkedin.com/pub/wilmer-comeaux/43/14/404?trk=shareTw>
Twitter <https://twitter.com/wilmercomeaux>
Facebook <http://www.facebook.com/WilmerComeaux>
|
|
look where the puck is going. A lot of us were here when they dropped the puck into the game and we've been watching the puck the whole game and we also know where it goes next. I can use my WCF in service fabric. I could use my .net in WCF. I could use my COM in .net. |
|
Don't let the marketing confuse you, there is nothing that is coupled to Windows that must be coupled to Windows. That's all the name is - marketing. |
I'm doing a lot azure. zero WCF on the outside. AFAIK the stuff I'm using is also not using much wcf on the inside. I have no data to proof that, but just one simply argument: everything I use is moving over to core. If these parts of azure would rely on wcf that much, then core would support WCF already. |
|
As someone who works as a dev at Microsoft on Azure services and has spent a significant part of the last 18 months building software that helps customers who have SOAP based services, let me offer my perspective with hopefully no judgement on the value of the tech. I think the folks who are hoping they can convince Microsoft to build WCF style services in .NET Core are wasting their time. Your time would be better spent working together on an simplified OSS version of WCF. I'm not from the .net team, so my opinion is just that but when I needed a WSDL parser to do my work, I wrote a new one instead of depending on WCF. My 2c. |
|
"Your time would be better spent working together on an simplified OSS version of WCF." If by that you mean writing it from scratch, then that defeats the entire purpose of asking for this. If instead you mean the community should maintain WCF going forward, then by all means, send me a link to the compilable source code and I'll have the GitHub project spun up in an hour, and a version running without MSMQ on .NET Core an hour after that ;) |
I could do without SOAP if need be, but I still would like a communication framework with automatic services + automatic proxies suited for RPC, which is configurable and supports a wide array of security and transport options and which comes out of the box in .Net Core. |
|
You do know it's the first week of 2018, right?
…On Jan 9, 2018 9:06 AM, "Damian Hickey" ***@***.***> wrote:
Sure thing @websitewill <https://github.com/websitewill>
[image: image]
<https://user-images.githubusercontent.com/57436/34733184-c5d451e6-f567-11e7-95fa-5e6139c5557a.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1200 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABo_EknIjEksxYL1ArkzlWw63lFuloQRks5tI5yTgaJpZM4Ikmmx>
.
|
|
OK we're done here, and that makes me sad. People want WCF because they're connecting to systems outside of their control, or for back compat, or for the things REST simply doesn't do. Berating them to move to REST when it's impossible for them is neither clever nor helpful. I will remind you that we have a code of conduct which includes prohibitions on
Please read it and understand why we have this in place. |
and others
Hi,
I'd like to start a thread to have a dialog about server side WCF on .NET Core. For me the WCF stack is quite impressive, and support for server side WCF on .NET Core would be fantastic. Please feel free to add your opinions to the thread.
Here is a list of some of the WCF features (that comes to my mind):
These features and more are for me very desirable, but some might be harder to support (e.g. WCF transactions relies on MS DTC (as fas as I know), but transactions enabled communication on a server side is a very important feature).
I hope you're as excited as I am about WCF, and even more so for a server side WCF on .NET Core.
The text was updated successfully, but these errors were encountered: