Say I'm building two applications:
1) A public website
2) A service
The website can be accessed, of course, by users.
The service can be consumed through a web API, but will also be consumed by the website.
This means that common functionality can be put in the service only, rather than having it duplicated in both the website and the service.
Now, when deploying this solution, there seem to be two options:
1) Have the website directly reference the web-service, and deploy both binaries to the web-server, running in the same process.
2) Have the website reference the web-service through the web API, just like all the other consumers. Have the service run in a separate process.
Option 1 would probably be faster for performance, but would require having the two DLLs deployed separately.
Is there any way I can have option 2 (separate processes) but still link the Website to the Service directly, to avoid network latency, serialization, etc?
What technology are you using for your web service? If you're using WCF you can use the NetNamedPipeBinding for your website which is almost as quick as using a dll directly.
Related
I need to calling our C# Methods from another server to perform some Action. I use C# in both servers. One is our Service Application, another one is a WPF application where I consume my Service.
Prefer I use a WCF or WebAPI service for Service Application?
Most People prefer to use Web Api, but web doesn't expose metadata for creating proxy by service.
which one is simple and better choose?
You may use either WCF or WebAPI, if multiple platforms (Mobile, Web, Other Service) are going to interact with your service, then I would recommend Web API, otherwise you may use WCF. Similar discussion has already happened in another question, please refer this link, hope this will be useful
Getting a web service and using android to consume them?
I was reading this article in looking for differences between creating an API using WebAPI and MVC and came across this statement:
In simple load testing on my local machine, I’ve found that Web API
endpoints hosted in console apps are nearly 50% faster than both
ASP.NET controller actions and Web API endpoints hosted within MVC
projects.
As such, I'm interested in how this would take shape in a production environment.
Obviously I'm looking for performance, so I looked into OWIN and self-hosting. However I'm not clear on if this offers the same efficiency as the console app discussed above.
Can someone please explain the proposal of hosting an API console application for consumption in a production environment - i.e. how would you connect a URL to the console app, etc.?
Thanks.
My understanding is self hosted OWIN apps can be run within any kind of app domain e.g console, windows forms, windows service, AWS EC2, Azure Worker Role etc. The application you should run it in is dependent upon the hosting environment you choose, there are lots of options.
If my MVC project is referencing (regular project reference not service reference) a WCF service project, I am not communicating using HTTP right?
I want to make my WCF service exposed to multiple mobile and 3rd party clients via HTTP over the web, but my own application I'd like to use without HTTP due to higher performance.
Is what I'm currently doing achieving this?
If you are using a project reference (i.e. it appears under the "Reference" folder on not the "Service Reference" folder) then you are not using HTTP. You are making a call directly to an assembly/DLL in that case. I generally develop my applications so that there is a Service Layer (sometimes referred to as the Application Layer) that basically mimics the API that the web service presents. This is an assembly that can be referenced directly if I do not want to distribute this service. Then the actual web service is just a thin layer on top of the Service Layer that provides the actual WCF binding and contracts for distributed clients to call.
It depends on how you added it. If you did it via "Add Service Reference" and your app/web.config is littered with WCF client settings then it probably is going over HTTP. You should check the transport and address settings withing your configuration. If you see HTTP then, well, you're using HTTP.
Even if you switch to named pipes there's still an overhead. The fastest transport for local communication is probably the NullTransport sample Roman Kiss developed.
I have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.
I have two questions I hope I can get an answer for with regard to my service oriented application
I am creating a service oriented application where controls have no events, it's all done by calling services... that means the service url is written in my jQuery code, but this seems somehow not nice.... It's like what is the best option to save service urls?! I feel it's hard to maintain and not secure when it's written inside the page or inside javascript referenced file.
I am talking to a hosting company and they told me that I can host this application services on cloud server and the application on another servers.... not all in the same server, but my application services are self hosted, I mean the services are inside the application.... so to make things work as my hosting company wants, shall I host the restful services in IIS or how exactly?
Service URL must be in your page or script source file. It can be local address unless you are using cross domain calls and JSONP - cross domain calls requires absolute address. It is the same as any other web technology. If you want navigation to other page, you must provide URL. If you want some picture or css file you must provide URL. Security is up to you.
This will be the problem of cross domain calls. Normally JS calls can be done only to the same domain where the page is exposed. Once the application server is exposed on different domain name your calls will not work. To avoid that you must use JSONP (WCF 4 has support for that). Exposing rest services consumed by your application from self hosted application is strange. REST services are consumed by your clients - they are front-end services and should be part of your application hosted on front-end web server. Your back-end application server should not host anything directly accessible by your clients.