.NET RIA Services work with an HTTP binding. What about TCP or named pipes?
WCF Named pipes don't work outside of a single machine so they don't count in the case of Rich Internet Applications. Not sure about net.tcp
Net.Tcp does work as far as I know. – the_drow
No, according to it's program manager, Dinesh Kulkarni it's impossible. WCF RIA over Net.TCP binding?
Related
I have setup 2 noted type cluster on FrontEnd and another BackEnd. The FrontEnd has stateless services and the Backend has Statefull and actor services. Now I have seen examples where they use reverse proxy and http:// calls to communicate with stateful services, and other places where they use Remote calls calling fabric:// When should each be used if there is data intensive transfers happening between Frontend and BackEnd node types which would be better protocol?
Actually fabric:// isn't a protocol itself, it's just a syntax for Service Fabric Naming Service to resolve actual location of your service. Remoting is a better choice if you don't have to expose your service to external clients, since it will choose protocol depending on locations on client and service (may use interprocess communication in case both are located on the same node) while using http:// sticks you to only this protocol.
The fabric:// is just an Uri Scheme. It is used to identify named services, like: fabric://MyApp/MyService
There is no right answer to this question, there are many variables to take into account to select the right approach.
You can use both and it will be absolutely fine.
It far more than that, but a a simple overview I can give is:
Using HTTP communication, the services depends only on each other endpoints, and both can be treated isolated from each other during development and deployment, they will communicate even when you change services versions and tech-stack. You can use different technologies like: Java, GO, NodeJS and still have a smooth communication between your services.
Using Remoting, you might get faster communication, but higher coupling between the services, because both need to understand same interfaces and entities used for communication, to keep them in sync(compatible) will most of the time require to deploy new version of both services together.
.
If performance is not an issue at start, I would suggest go simple with HTTP, and migrate if does not attend your demands.
my question is this:
Does WCF(Windows Communication Foundation) have a Micro Web Service feature?And does it only supported by REST?
Check this out: Difference between WCF and Web API and WCF REST and Web Service
Why you want to use WCF for REST service when you can use Web API? Is there something reasonable?
I have a RESTful service and I want to use gSOAP for my REST client. Is it possible to use gSOAP without having gSOAP on the server side, simply communicating with the RESTful service that is offered by the service?
Yes, this is possible. You can use gSOAP for the client side only, for the server side only, or for both.
In my client (in C) I´m using the function "json_call(..., "Some-Service-URL", ...)" to give a JSON-structured http-content to a Java-service.
See here for more details.
Regards Daniel
Would it be a valid approach to host both frontend (asp.net MVC 6) and backend (WCF/WebAPI services) in MS Service Fabric? Fabric is marketed as a platform for running services. Since both MVC and services need to scale, wouldn't it make sense to have both layers in Service Fabric? Not having to deal with hosting the frontend part separatley, let alone scale it, sounds very compelling.
I might be wrong, but I'm not 100% sure you can host an Asp.Net MVC 6 or WCF app inside Service Fabric, but you can certainly host a Web API app. Whatever Asp.Net app you host needs to support OWIN self-hosting, which I'm not totally sure MVC or WCF supports. If you find out that you can host all of those apps, then sure, you should have at it!
I can say that my company's preferred approach is to have a frontend, static application that only serves up static content (HTML, JS) and have that frontend use the Web API we have hosted in Service Fabric. OWIN self-hosting (like what you need to do with Service Fabric), doesn't let you GZip static content without routing it first through a proxy like nginx, and you'll probably want GZip compression with any frontend app. So, you're better off hosting the frontend static application elsewhere, like a traditional Azure Web App that does support GZip compression.
Hope this helps!
I've just created my first Fabric Service app using the latest VS and it allows you create a service as an ASP.Net Core MVC app. Out of the box it uses Kestral as the webserver, but I guess you could use IIS or OWIN as well. If you choose to stick with Kestral, apparently you can add GZip via middleware (GZip middleware), although I haven't tried this myself
Is there any concept like RDS(Remote Data Services) in .net ???
WCF (Windows Communication Foundation)
.Net Remoting
ASP.NET Ajax.
Those are your options and any one of them is a light year ahead of RDS.
Take a look at ASP.NET AJAX and script services:
http://www.asp.net/learn/ajax/tutorial-05-cs.aspx
Javascript in the browser calling web services on the server is probably the closest thing to RDS. The web services don't necessarily have to be XML web services, you could use JSON as an alternative.
If what you mean is VB6's RDS.DataSpace. In .NET, you can use either WebServices(http-based, more analogous to RDS), or Remoting(tcpip-based, more analogous to DCOM, sans the multiple opening of ports).