Remoting
This page "Remoting APIs are obsolete" doesn't describe reasons for the decision to obsolete the technogy.
My understanding is that Remoting is related to AppDomain technology, which is also obsoleted. But may be also other reasons exist?
Remoting was able to use shared memory (in GenuineChannels library opensourced with time).
There also was a plugin technology (MAF - Managed Add in Framework), which depended on Remoting, how these features are implementing now with gRPC?
WCF/netWCF
Why WCF and netWCF are obsolete?
Is the transition to HTTP/2 the main reason to their deprecation? ("Why we recommend gRPC for WCF developers")
Related
The setup at the current employer has one set of back office functions on a Java platform and another group of functions on two separate .NET-based platforms. There is no overall architect.
The Java guys decided to go for Apache QPID and AMQP for messaging, presumably amongst themselves, with the .NET systems and other external systems.
.NET architecture involves WCF services hosted in IIS/WAS and Windows Server AppFabric.
Does anyone have any experience of AmqpBinding and IIS/WAS, if there are any possible pitfalls?
I think your first problem will be IIS/WAS/AppFabric because non HTTP services hosted in WAS have additional requirements for infrastructure which consists of additional process (listener) running usually as as a windows service and communicating with worker process. This process is responsible for receiving and sending messages and allows service activation in WAS. I don't think that the QPID project has the listener process already created. You will most probably have to implement the listener yourselves - check this sample for custom UDP activator.
I am developing services which will be consumed by many different platforms like Java,PHP,C or C++ etc. I want to know what protocol or binding type should I use for these kind of services. There should be a common protocol which can be used by all kind of technologies or most of them. I used BasicHTTPBindig for this purpose but this does not support transactions on client application. The supported Binding types are wsHttpBinding and others. I can use transactions supported types which are available with WCF but I don't know other technologies support them or not.
So the Question is What is the best Recommended Protocol or Binding type which support most of major technologies to consume WCF services.
Any kind of help/suggestion will be appreciated.
I expect that by client side transaction you mean distributed transaction (flowing transaction started at client to server). This is quite challenging because interoperable support for distributed transactions requires WS-AtomicTransaction and WS-Coordinator protocols to be implemented by the platform. In short almost none service stack provides these protocols (except WCF and several Java stacks). So you will probably make this work with .NET, Java, C/C++ (but the configuration will not be easy) but you will have a hard time to use it in PHP, Python, etc. These protocols are also not supported on mobile devices.
Distributed transactions are considered as internal server to server feature. So if you are going to make public service you should change your design. If you are going to make public service / service consumed by client applications (not servers) then you should choose basic HTTP binding (or create REST service) for maximal interoperability.
I haven't looked at WCF for awhile (I don't know what - if anything - has changed in .Net 4.0, for example) ... but if you wanted to interface to non-MS/non-WCF clients, you used to need WSE (Web Services Enhancements).
Here's a good link:
http://msdn.microsoft.com/en-us/library/ee958158.aspx
I have an HttpModule that gathers some basic information on every Http request to an ASP.NET site. The module has to send this information for further processing to an external program (a windows service or a console app.) I am currently using a WCF service with named pipes (with a ChannelFactory). I have to say that it all seems to work nicely, perfectly, actually.
My main requirement for the HttpModule is superior performance and reliability.
Is there a better way of doing such inter-process communication, especially within an HttpModule (on a highly loaded site). Are there any potential performance issues/bottlenecks ? :)
What do you think? any ideas or references for some reading on this topic would be highly appreciated!
Thank you in advance!
I'm assuming that the communication between Http Module and the data service is always on the same machine.
Performance: you're unlikely to beat Named Pipes, as they use shared memory for the transport. WCF adds a little overhead with its framing protocol and encoding scheme - you could pass your data raw over a pipe using the System.IO.Pipes types directly if you wanted to avoid the WCF overhead, but for many applications this is not worth the extra effort. If you stick with WCF, set the transport security mode to None as explained here.
Reliability: Named Pipes are objects managed by the OS kernel, and the WCF binding a fairly thin wrapper over them, particularly with transport security disabled: reliability is high.
I understand to an extent that it helps applications communicate regardless of their location. Why is it important and what is an example of a real-world use of WCF?
WCF is a generic communication mechanism that allows you to setup generic client/host communication between two parties. The neat thing about WCF is that is allows you to configure service properties such as transport (http/pipes/tcp/Tibco EMS), security models (any of the W3C standards), compression, encoding, timeouts, etc, without changing ANY code. That is powerful. Best of all, you can configure it so that you can have a service in C# and a client in Java (or any other language or the other way around), as long as they both talk using the same mechanisms.
You can create a standard HTTP SOAP web service using WCF and one day decide to switch it to use the faster named pipes for local communication. You can create web services that talk over TibcoEMS and have easy failover on the queue level. You can create a file streaming web service that distributes all kinds of images/videos to your application.
Here Are some brain dump i think might be useful to understand the whole scenario.
Reason of Creating WCF : Background
Modern Application[Distributed Application] development we use different architechtures and technologies for communication
i.e:
COM+
.NET Enterprise Services
MSMQ
.NET Remoting
Web Services
As there are various technologies. they all have different architechtures. so learning all them are tricky and tedious.
one need to focus on each technologies to develop rather than the application business logic
so microsoft unifies the capabilities into single, common, general service oriented programming model for Communication. WCF provides a common approach using a common API which developers can focus on their application rather than on communication protocol.
Now-a-days we call it WCF.
N.B: image collected from - http://www.codeproject.com/Articles/255114/Windows-Communication-Foundation-Basics
What Exactly WCF Service Stands For?
WCF lets you asynchronus messages transform one service endpoint to another.
The Message Can be simple as
A Single Character
A word
sent as XML
complex data structure as a stream of binary data
Windows Communication Foundation(WCF) supports multiple language & platforms.
WCF Provides you a runtime environment for your services enabling you to expose CLR types as Services and to consume other Services as CLR Types.
A few sample scenarios include:
A secure service to process business transactions.
A service that supplies current data to others, such as a traffic report or other monitoring service.
A chat service that allows two people to communicate or exchange data in real time.
A dashboard application that polls one or more services for data and presents it in a logical presentation.
Exposing a workflow implemented using Windows Workflow Foundation as a WCF service.
A Silverlight application to poll a service for the latest data feeds.
Why on Earth We Should Use WCF?
from a Code Project Article, thanks to #Mehta Priya I found the following Scenarios to illustrate the concept. Let us consider two Scenario:
The first client is using java App to interact with our Service. So for interoperability this client wants the messages in XML format and the Protocol to be HTTP.
The Second client uses .NET so far better performance this clients wants messages in binary format and the protocol to be TCP.
Without WCF Services
now for the stated scenarios if we don't use WCF then what will happen let's see with the following images:
Scenario 1 :
Scenario 2:
These are two different technologies and have completely differently programming models. So the developers have to learn different technologies
so to unify & bring all technologies under one roof. Microsoft has come with a new programming model called WCF.
How WCF Make things easy ?
one implement a service and he/she can configure as many end points as it required to support all the client needs .
To support the above 2 client requirements
-we would configure 2 end points
-we can specify the protocols and message formats that we want to use in the end point of configuration
References:
WCF : What , Why and When https://vishalnayan.wordpress.com/2010/12/31/wcf-what-why-when/
Why we use WCF Service? http://www.codeproject.com/Tips/815742/Why-We-Use-WCF-Service-and-Sample-of-WCF-Service
What Is Windows Communication Foundation https://msdn.microsoft.com/en-us/library/ms731082(v=vs.110).aspx
Windows Communication Foundation Basics http://www.codeproject.com/Articles/255114/Windows-Communication-Foundation-Basics
There's little to add to the responses so far, especially the one from "siz".
One thing to add is that WCF is the current way to do web services on the .NET platform. It's not the "new" way, it's the current way. ASMX web services are the old and just barely maintained way. One Microsoft employee has publicly stated that only critical security fixes will be made to the ASMX platform, so if you intend for your services to be useful more than a year from now, don't use ASMX.
In addition to the typical "web service" use cases, WCF handles atypical cases, like binary communication over named pipes, message queues, etc. To a very large extent, the service you write to support something simple like SOAP over SSL can also support these other protocols, with no changes to the code.
To answer the "real world" bit, I'm just finishing up a dispatch system by which a Visual Basic 6.0/access alarm receiver, a WPF/SQL ERP system and an iPhone application all share information to schedule and execute jobs.
Essentially the use case is where you want two separate applications to talk to each other somehow and their locations are unknown (could be same machine (but different application domain), same network or on the other side of the internets)
You can easily embed it into a Windows Forms application. That was a nice thing to discover. It is so much easier than .NET Remoting too.
There are a number of reasons why it is advantageous over classic ASP.NET web services (.asmx).
A couple of these off the top of my head are:
The ability to have multiple bindings for the same service call means the message doesn't have to serialise into XML and back if you simply want to communicate inside a web farm.
The way contracts are defined is much more forgiving when it comes to multiple versions of the same contract.
I am looking at using MSMQ as a solution to do asynchronous execution in my upcoming project. I want to know the differences between using WCF and frameworks like MassTransit or even hand written MSMQ client to place/read task off MSMQ.
Basically the application will be several websites (internal through LAN or external through the Internet) reading/writing data through a service layer (be it WCF or normal web service). Then this service layer will do one of two things: 1. write data to database 2. and/or trigger the background process by placing a message in the queue. 3. obviously it can also retrieve data from database. The little agent (a windows service) on the other side of the queue will monitor the queue and execute based on the task command.
This architecture will be quite easy to scale (add more queues and agents) and easy to implement compared to RPC or distributed execution or whatever. And the agent processing doesn’t need to be real time. And the agent and service layer are separate applications except they share the common domain objects and Repositories etc.
What do you think? Architecture suggestions for the above requirements are welcomed. Thank you!
WCF adds an abstraction over MSMQ. In fact, once you define compatible contracts (operations must be OneWay), you can switch out MSMQ in the config, transparently. (For instance, you could switch to normal HttpWS or a NetTcp binding.)
You should evaluate the other WCF benefits, like security and so on, to see how those fit in with your needs. Again, they should be reasonably transparent of the fact you're using MSMQ underneath. For instance, adding SOAP security and so on should "just work", independent of using MSMQ.
(Although, IIRC, you still need to login to the desktop on each machine that uses MSMQ, with the service account that will use MSMQ, to generate the certificate in the machines local profile. And then, it doesn't work very well from IIS6, since user profiles aren't loaded. A real pain in general, but nothing to do with WCF specifically.)
Apart from that:
Have you looked at SQL Server Service Broker? After using MSMQ + WCF and SSSB, I think that SSSB is vastly easier to configure and manage. SSSB works with T-SQL commands over any SQL client (I use it from Mono, on Linux, with transactions). It'll also give you transactional send/receive, even remotely (I think MSMQ 4 now allows this). It really takes a lot of the pain away from message queuing, and if you're using SQL Server already...
SSSB is often overlooked since the SQL Management Studio doesn't have GUI designers for it all, but it isn't hard and is a great option. The one downside is that if you want local send capability (i.e., queue message when network is down), you'll need to run a local SQL Express instance.
Your architecture seems sound and reasonable. However you should consider using the WCF net MSMQ transport over hand coded MSMQ classes. WCF wraps this common functionality into a nice programming model. Also I believe there is some improvements in the protocol used by wcf compared to basic System.Messaging
Have a look at the value-add over plain MSMQ:
http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html
In summary, you get a lot of messaging concepts clearly presented in the API with MassTransit; to an extent you wouldn't have if you hand-coded it or used WCF.