I'm having a look at the best way of developing a server application that presents an ASP.NET MVC front end for management/reporting.
The server app (service?) will also need to provide TCP listener as well as communicate to devices on a COM port.
The most obvious way I can think of doing this is to have an ASP.NET MVC web app and have a windows service that talks to the web app using a web calls/services. I guess then I'd talk to the service using the tcp listener or remoting?
The only other way would be to actually host an web server component in the service, and not use IIS which seems a bit to over the top.
Does anyone have any experience of this/recommendations?
It's a bit open ended but hope I've explained the basics.
TIA
Sam
I would probably try and decouple things a bit more.
Start off w/ a core project where all your business logic lies (agnostic of how users interact with it); sort of the DDD Domain Model idea.
Then, create two projects which consume that core project, one that is your MVC app, and another that's a WCF or ServiceStack-based service which can handle your TCP stuff.
Share state between them using the normal means; either inter-process comms, shared database, etc.
It sounds to me like you're looking for something very close to Windows Communication Foundation. Your requirements for IIS hosting, ASP.NET communication, and TCP communication. MSDN has a brief overview of WCF up here. There's also an article available about the transportation protocols here.
There are some good -- if a little old -- WCF questions here on Stack Overflow. I've just started delving into this world myself, and I have to admit that it's daunting at first. The Beginner's Guide (found under the first hyperlink above) has some slightly old, but very useful tutorial videos about WCF.
I will say that, although it may seem daunting or difficult, it's certainly better to use an existing, established technology for your purposes than to try to write your own homebrewed solution for something like this.
I started ServiceStack because I needed a high-performance web services framework option that promotes the correct way to develop web services.
ServiceStack can be run on top of any ASP.NET host or self-hosted using the HttpListener option. See the Starter Templates for example projects of a Console App or Windows Service hosts. Although even under IIS, ServiceStack is very fast and imposes very little overhead with a hello world service executing in sub <1ms response times.
ServiceStack also comes with .NET's fastest text serializers and a myriad of high-performance caching providers so you can escape the XML config bound ASP.NET's session and caching provider model.
Because ServiceStack encourages a clean message-based development model your same web services can take advantage of the Redis MQ Host allowing it to be invoked outside of HTTP context using Redis as a broker - with no code-changes required.
Redis is one of the fastest distributed NoSQL data stores.
Related
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
I need advise on the architecture of my new application. In the environment I work in, we normally create Win based apps and these compose a UI layer, Business Layer, WCF Service Layer, and Data Access Layer. These are on a 3 tier architecture with Services Server, Database Server and clients machines accessing the application via Citrix on an Application Server. I just created a web aplpication and my admin has suggested this should be hosted on a separate web server, my question is, is there a need for my web application to use a WCF Service Layer, since it can be hosted on the same application server? Basically, do websites need to use wcf/service layers and what are the benefits?
1.
Read this:
http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic
My advice:
At the least, you should use WCF, and use "named pipes". You can deploy both the Host (WCF) and the Client (Asp.Net website) on the same machine.
The Asp.Net website will be the "client" and access the service.
Then, if you ever want to horizontally scale, all you have to do is change the .config settings to use a different protocol besides named-pipes.
Aka, you'll have the "logical separation", even if you deploy both on the same physical machine(s).
They (websites, any project) don't "need" to do anything.
You can write inline sql code behind buttons on webforms if you want.
But its not maintainable. And its not scalable. And it is probably foolish.
But putting in the time to SOA a mid to large sized application is worth the effort in the beginning, IMHO.
This is a question without a concrete possible answer, do you need a wcf? well that depends on the requirements and the architecture you want to put in place.
based on the small context you provide maybe you can get some the following benefits
WCF Provide state for operations
Fast processing (binary serialization)
WCF are more likely 'to be testable' than legacy asmx web services
You can access the same backend you built for your desktop applications
regarding if than can be accessed from the same server, the short answer is yes (obviously you need to measure your server capabilities)
I've done some app's that doesn't use a wcf at all, and other that use it for certain operations you can take a look to this SO answer to get a good example where a wcf could be a good candidate in an app.
I have a Delphi Application with a Client-Server Architecture. Now, I want to write a Web-application for this Delphi Client-Server Application.
To write a this Web App I don't want to use Delphi - I want to use a "modern" Web Architecture like a PHP Framework, ASP.NET, Ruby on Rails etc.
So far i came to one possible Solution with RemObjects (http://www.remobjects.com/ro/) and ASP.NET:
In this approach the Delphi Application communicates with an ASP.NET WebServer over RemObjects where the Delphi Application is the REM Objects Server and the ASP.NET App is the Client.
My questions are:
Is this approach really a good idea and if not why?
What are other possible approaches to solve this problem?
Thank you for your help.
Edit:
Thank you for your answers so far!
How about establishing a neutral link like a Database?
You need a two-way messaging / inter process communication solution. Typically SOAP, REST and other web services (RemObjects) are synchronous, request-response style communication.
A messaging middleware can be implemented in a way which totally decouples the applications so that you can restart any part of the system (for example for maintenance and update installation) without disturbing the others.
Popular open source products in this field are for example Apache ActiveMQ, Open Message Queue and RabbitMQ, which offer cross-platform/cross language clients.
An alternative could be SOAP, or a RESTful connection.
R/O is faster than SOAP, for sure, and well integrated to both sides (Delphi and C#).
And, since you are already using R/O between Delphi client and Server, it will be the first option to consider.
IMHO any RESTful connection between Delphi Server and a C# client may do the work also. And will probably be faster, so is to be considered only in a second phase, if you find any performance or stability problem with a R/O connection.
I am new to WCF and going through tutorials right now. I was wondering what are the benefits and disadvantages of using a WPF or an ASP.NET web application as a client for a service. I understand it will depend on the kind of service, but besides the common difference of one being a windows app and other a web application, what are the advantages of one over other.
First of all, the choice of client technology does not depend at all on the kind of service you will be talking to. Both WPF/Winforms and a Web app will be perfectly capable to talk to a web service.
Instead, choice of client technology should purely be driven by requirements on the client side
Factors that you should consider when coosing one client technology over the other are:
Know-How available to you (and your team)
Deployment scearios: How do you get your app to the users, etc.
Client environment: How many OSs do you need to support, how many different browsers would you have to support when doing a web app?
Do you have occasionally connected scenarios, or do you need privileged access to client resources? - This would tip the scale somewhat towards a Rich client.
Even so, in many cases a web app appears to be a very valid option as you have access to a wealth of non-MS tech like Javascript Frameworks, CSS resources etc. etc.
On a personal note: Do not use WCF to define your web services - there are fantastic Open Source Frameworks, most notably ServiceStack that will make you more productive and concentrate on what your service does and less on the mechanics and abstractions.
I have a .net application running on server. Now I want to comunicate between my ASp.NET website and the server application.
Currently I use database, server writes info to the db and site uses it etc. However adding new fields to echange and exchanging complex object is a pain.
Is remoting the way out? If yes, what are the common things to keep in mind while doing this.
both server and asp.net site is on the same server
both is under my control
is there any other better way than using remoting?
It is .NET 2.0
The purists will say that remoting is an old, dead technology, and the way to do it now is to use WCF.
If you're attempting to have some SOA thing, the best thing is to a web service for your server application and access it from your ASP.net website application. It's the best way to do.
However I don't really understand what the purpose of the "server" is? Couldn't your ASP.net website - as you say - be your front-end of the server application?? Your "server" would then simply be the business and data layer and there would be no need to use remoting or WCF.
I would say webservices if want to stay .net 2.0, otherwise it think you should take a look at WCF.
If you need direct interaction between assemblies (ASP.NET and some server application or service) you should use Application Domains and cross-domain calls (some good example here) or using WCF, which is better. Also you can use web services if your server application can be accessed via web without major resulting drawbacks (security issues, server deployment change, etc.).
Actually, u can deploy a WebService on that server. WebService is base on SOAP, it can exchange data object with your website.
If you can update to .Net Framwwork 3.5, you can try to use WCF instead.