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.
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'm looking to make a RESTful API on ASP.NET for a website. My problem is that I need it to be integrated into the website and not as a separate project.
I understand that WCF makes this really easy and its the ideal way to do it, but I don't think you can combine a WCF Service Project and a ASP.Net Website, Is this correct?
Is there a way we can do this using a webservice (asmx) file (since I know that asmx services use SOAP no?)
The reason I need this to be in the same project is that the customer will be able to purchase ssl for their domain (which the website is going to use) and I need to make the API secure as well, but the customer should not be asked to purchase two ssl or even a wildcard one.
Knowing this, is there a better easier way of doing this using WCF?
Take a look at the new MVC4 Beta, it's set to go live sometime between March and April this year and should be able to accommodate your requirement to build a RESTful web service alongside a web application. I haven't spent too much time with MVC4 to go into the details, but it's definitely worth a look. Links: Get MVC4; MVC4 and WebAPI blog.
Hope this helps!
You can use ASPNET MVC to build an API along with your website.
See How can I implement a site with ASP.NET MVC without using Visual Studio? for some details on building a basic MVC site.
ASPNET MVC services can respond in JSON or XML, or both.
There will be no special requirement for two SSL certs.
I have an ASP.NET MVC 3 application that exposes both WCF REST services. I'm using .NET 4. You'll have to pay attention to how you configure your routing. For example, my WCF services are prefixed with something like "api/v1/" while all other requests are handled by ASP.NET MVC 3.
I had a problem because IIS refused to serve some "localhost" requests (like when your MVC 3 controllers try to consume your WCF rest services). That was solved by adding an entry to my hosts file. Also be aware of this when implementing an OAuth 2.0 Resource Server or Authorization Server.
Using WCF for REST services works ok in .NET 4, but the JSON serialization sucks big time. There are issues with default dates and it is rather slow. You may want to look at using a different serializer. With WCF you sacrifice some flexibility for some features you get for free.
ASP.NET MVC 4 (and the WEBAPI) is still in BETA, so I'd avoid that for a project with a short term release date.
I'd actually use NancyFX. Setting up routes is super-easy, and it comes with built in XML and JSON serializers that act based on the data in the headers.
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.
I'm responsible for a .NET process running under windows.
The process is running as a windows service.
I would like to have the ability to be able to get some info from the service in a web browser.
For that matter I would like to write a small ASP.NET web service.
The problem is that I want the run the web service within my process.
As far as I know, I can't do that since ASP.NET must run from within an IIS.
so...my question is, is it possible to host ASP.NET server within another process?
I know that in the common scenario, I should have the "process code" run as "code behind" the ASP.NET but in my case, the .NET service is already a part of our product so in this case I'd like to have the opposite.
Thanks a lot.
You don't have to host ASP.NET inside your service. You can use inter-process communications techniques to communicate between your service and a new or existing ASP.NET webapp. Here's an example using named pipes. Or if you're using .NET 3.5 or higher you can use WCF.
If you really want the service to host its own site I don't think embedding ASP.NET is possible but you can use an http component like this one.