I would like some advice on how to approach a programming task.
I am creating a website that collects data over time (users enter data) and then it displays spatial maps (upon request) created from that data.
Each time a user enters data I am using a webservice to store data into a SQL database (using ef4).
The design decision I have now is when a client requests a map/image, how should I return the image to them.
Should I:
Upon calling a WCF service construct
the image and return that image via
the service
Upon calling a WCF service construct
the image, store
it server side somewhere, return a path
or URI/URL to the image
I was hoping to do (2), but I am unsure of where to save the image and what implications that has when trying to expose it.
The WebService and Asp.Net application will most likely run from the same server if that helps at all.
Any advice on how to proceed would be most appreciated, particularly details like where it is safe to save from a WCF service etc
Thanks.
(I am using a service because there will be other clients other than the Asp.Net app that request the data).
It would largely depend on what kind of API your clients can consume? If they need SOAP API then you have to use either WCF services or asmx to provide the images. However, the better alternative is clearly a HTTP API i.e a unique URL is provided for accessing the particular image - you may use REST style URL or may choose to accept parameters via query string. Essentially, URL should have all information needed to retrieve image from the database.
Now, you may directly choose REST based WCF services to serve these images or may put ASP.NET based HTTP Handler (as facade) over WCF services to serve them. If you are going to use WCF and image sizes are large then do consider streaming. I will prefer a putting a facade as it helps you to move some important concerns such as caching and streaming outside WCF world. So in such scenario, WCF services will use the best end-point possible to deliver image data from data store. Your facade HTTP handler would translate the url in necessary WCF service call, get the image data, cache into the file system and serve to client. The subsequent requests would be served via this cached image. Because you are using URLs and get requests, images would also cache on client side (you can control this by emitting explicit headers in your facade handler). Typically, requests to fetch the image would be substantially high than requests to update data - by serving get requests via different handler, you may scale it independently of WCF services.
I would use an HTTP handler to consume your WCF service based on some parameters. I use something similar to retrieve an image stored as a BLOB in a database and set some default sizes on the image.
The HTTP handler would be called from an image tag on the asp.net page.
This article has more info on http handlers
Related
I have a simple HTTP server where you can create and manage todos. You can also add plugins in order to, for example, send an email to the people who starred a todo when that todo has been completed. I currently check for all enabled plugins through an query to the database, and then query each API endpoint for the different plugins (Gmail, Notion, Trello, etc). After this is finished, I send a response back to the user. This is a problem, because it means I rely on the speed of the external API's I am requesting for my response. If the Notion api is slow, then my endpoint is also slow.
Is there a way to first send a response after, for example, the server marks the todo as completed, but then send a different response after all the plugins have been queried (Gmail, Notion, Trello, etc)? Would I have to use web sockets? Or is the way I currently handle external API queries the only way to do it?
You are right thinking that you want to decouple requests from customers with backend processing (reaching out other providers); and web sockets is one of options to do that. HTTP2 streams is another options. And, of course, pulling is also a way (simple, but not too efficient).
I need to implement a file upload service, which may include some larger files. I initially used a WCF service and was using non streamed (i.e. I sent a byte[]), but would get out of memory exception (reading a file into the byte[] on the client).
I then tried using Streams in the WCF. This seemed to work fine for large files, but the huge restriction is that you seem to need to only send the Stream by itself. I don't seem to be able to also send the file metadata (e.g. filename, timestamp etc)
This service may have many client apps uploading, so I can't really see how to match up file meta data sent in a separate call to just a stream with no other information.
I am wondering if Web API may be a better way. I haven't tried it yet, but in some samples I have seen, you appear to be able to send other data along with the stream.
If using Web API, it will be self hosted (not running, in IIS, it will be running in a Windows service).
So, to me it is starting to look like Web API may be a better choice here? Or is there a way to send metadata with a file Stream in WCF?
Thanks in advance for any ideas!
You can achieve it using WCF by wrapping necessary metadata in a data contract or message contract object. You can refer the implementation on: http://www.codeproject.com/Articles/166763/WCF-Streaming-Upload-Download-Files-Over-HTTP
Web API is an alternative if your clients prefer to communicate in JSON/XML and you do not want to worry about the serialization/deserialization of JSON/XML in WCF. Your client can send a HTTP POST request with multipart/form-data content type to upload the file using Web API.
Should I leverage an ASMX service or the ASP.NET Web API for my two simple API's?
I want to create two simple APIs in my ASP.NET MVC project. One takes in 3 parameters (currentUserID, DataType, ActionName). It returns them and an XML string of the data they have requested. The API is consumed by client-side JavaScript code. The other API receives an XML string and uses that on the server side to perform actions on the database.
I just answered a related question:
What is the future of ASP.NET MVC framework after releasing the asp.net Web API
Basically, the frameworks provided by Microsoft to develop Web Services are:
ASMX. XML Services based on SOAP.
WCF. Web services based on SOAP. These services were the evolution of the traditional ASMX services and basically they focused to separate the service itself from the transport protocol. That's why you can expose the same service using several endpoints and therefore several protocols (TCP, HTTP, Named Pipes, MSMQ, HTTPS). This flexibility came with the configuration problem. One of the main complaints in the community about the WCF is the tedious and extensive configuration
WEB API. Based on HTTP not in SOAP. This new API is a new framework to create services. The main difference with the other two predecesors, is the fact that it's based on HTTP and not on SOAP, therefore you can use several HTTP features like:
It contains message headers that are very meaningful and descriptive - headers that suggest the content type of the message’s body, headers that explain how to cache information, how to secure it etc.
use of verbs to define the actions (POST, PUT, DELETE..)
it contains a body that can be used to send any kind of content
It uses URIs for identifying both information paths (resources) and actions
WEB API is focused on writing services to expose them via HTTP (only on HTTP at the moment). If you want to expose your service using another protocol, then you should consider using WCF.
WEB API is based on MVC (if you want to know the reasons why it's based on MVC, they are simple)
Another goal of the WCF Web APIs was to incorporate known concepts that would help developers to overcome some of the drawbacks they faced with WCF, such as huge configurations, overuse of attributes, and the WCF infrastructure that did not support testing well. Thus the Web APIs used IoC, enabled convention-over-configuration, and tried to offer simpler configuration environment.
ASP.NET MVC infrastructure with its elegant handling of HTTP requests and responses, and its support of easy-to-create controllers seemed like the proper way to go for creating this new type of services.
Take the following points into consideration to choose between WCF or WEB API
If your intention is to create services that support special scenarios – one way messaging, message queues, duplex communication etc, then you’re better of picking WCF
If you want to create services that can use fast transport channels when available, such as TCP, Named Pipes, or maybe even UDP (in WCF 4.5), and you also want to support HTTP when all other transports are unavailable, then you’re better off with WCF and using both SOAP-based bindings and the WebHttp binding.
If you want to create resource-oriented services over HTTP that can use the full features of HTTP – define cache control for browsers, versioning and concurrency using ETags, pass various content types such as images, documents, HTML pages etc., use URI templates to include Task URIs in your responses, then the new Web APIs are the best choice for you.
If you want to create a multi-target service that can be used as both resource-oriented service over HTTP and as RPC-style SOAP service over TCP – talk to me first, so I’ll give you some pointers.
For a more detailed comparison:
http://www.codeproject.com/Articles/341414/WCF-or-ASP-NET-Web-APIs-My-two-cents-on-the-subjec
It seems you are really doing much with Views so I think Web API would be more concise solution at this point.
If possible, I would use an Web Api Controller in mvc4. You can return an generic ienumerable list or model and it will automatically output the data to whatever format is requested such as xml or json. Its pretty amazing.
I have a simple web application that allows users to upload a file to the server and store the data in the Database.
There will be a decoupled service (probably WCF) which needs to act upon the data, but i am not sure what the best mechanism is to alert the service? Is it a good idea for the WCF service to poll the database every few minutes to check for new data? Or should i be looking at other patterns (?) to better accomplish this task? using Events perhaps?
I have not done anything like this before so looking for some guidance to start off with.
Thanks
Why don't you want to call the service from the web application in the same code that performs the upload? Typically, an application calls a service, not the other way around.
Polling from client side is an option. Or you can have a non duplex service for file upload and have a duplex service for callback on the progress of the upload.
Also Take a look this sample which uses non duplex channels to track file upload and download.
Suppose I have either an ASP.NET displaying my results, or a Silverlight client. And I'd like to show the current status of my server, or embedded device. (pretend the device reads temperature and humidity stats)
How should I send the status information from my device to the front end? Should I poll the device and save the results to SQL, Azure Table, or the like? (Azure is a technology that fits with this project for other reasons. That's why I mention it)
Or should I create a WCF service that polls the device directly and returns the current status.
What makes more sense?
In either ASP.NET or Silverlight you are going to have to poll from the client (web page or Silverlight app) to the backend to get the current status. In ASP.NET I'd look into doing this via an AJAX poll to a service using Javascipt (look at using Jquery or something similar to make this easier).
In silverlight you will need to have some sort of service configured to return the results and poll it using the Timer control running on a seperate thread.
You can also using a "push" binding within your silverlight app. Basically instead of you manually polling the server, the server will send you a push notification anytime it deems it necessary to let the client know of any change.