When I first posted this question I had strong coupling between my web service and application controller where the controller needed to open multiple threads to the service and as it received back data it had to do a lot of processing on the returned data and merge it into one dataset. I did not like the fact that the client had to so much processing and merge the returned data before it was ready to be used and wanted to move that layer to the service and let the service open the asynchronous threads to the suppliers and merge the results before returning them to the client.
One challenge I had was that I could not wait till all threads were complete and results were merged, I had to start receiving data as it was available. That called me to implement an observer pattern on the service so that it would notify my application when new set of results are merged and ready to be used and send them to the application.
I was looking for how to do this using either on ASMX webservices or WCF and so far I have found implementing it using WCF but this thread is always open for suggestions and improvements.
OK the solution to my problem came from WCF
In addition to classic request-reply operation of ASMX web services, WCF supports additional operation types like; one-way calls, duplex callbacks and streaming.
Not too hard to guess, duplex callback was what I was looking for.
Duplex callbacks simply allow the service to do call backs to the client. A callback contract is defined on the server and client is required to provide the callback endpoint on every call. Then it is up to the service to decide when and how many times to use the callback reference.
Only bidirectiona-capable bindings support callback operations. WCF offers the WSDualHttpBinding to support callbacks over HTTP (Callback support also exists by NetNamedPipeBinding and NetTcpBinding as TCP and IPC protocols support duplex communication)
One very important thing to note here is that duplex callbacks are nonstandard and pure Microsoft feature. This is not creating a problem on my current task at hand as both my web service and application are running on Microsoft ASP.NET
Programming WCF Services gave me a good jump start on WCF. Being over 700 pages it delves deep into all WCF consepts and has a dedicated chapter on the Callback and other type of operations.
Some other good resources I found on the net are;
Windows Communication Foundation (WCF) Screencasts
MSDN Webcast: Windows Communication Foundation Top to Bottom
Web Service Software Factory
The Service Factory for WCF
This sounds like a perfect use case for Windows Workflow Foundation. You can easily create a workflow to get information from each supplier, then merge the results when ready. It's much cleaner, and WF will do all the async stuff for you.
I'm not so sure that duplex is needed here... IMO, a standard async call with a callback should be more than sufficient to get notification of data delivery.
What is the biggest problem? If you are talking about async etc, then usually we are talking about the time taken to get the data to the client. Is this due to sheer data volume? or complexity generating the data at the server?
If it is the data volume, then I can think of a number of ways of significantly improving performance - although most of them involve using DTO objects (not DataSet/DataTable, which seemed to be implied in the question). For example, protobuf-net significantly reduces the data volume and processing required to transfer data.
One of the ways to achieve this is by invoking your WS asynchronously (http://www.stardeveloper.com/articles/display.html?article=2001121901&page=1, http://www.ondotnet.com/pub/a/dotnet/2005/08/01/async_webservices.html), and then updating the GUI in the callback.
However, you could have timeout problems if the querying of data takes too long. For example, if one of the supplier's web site is down or very slow, this could mean that the whole query could fail. Maybe it would be better if your business logic on the client side does the merging instead of WS doing it.
Not sure if this solution fits your particular task, but anyway:
Add paging parameters to your WS API (int pageNumber, int pageSize, out int totalPages)
Add a short-living TTL cache that associates request details (maybe a hash value) with output data
When your application asks for the first page, return it as soon as it's ready and put the whole bunch of collected/merged data to cache so when the next page is required you may use what is already prepared.
But note that you won't get the most up-to-date data, configure cache reloading interval cautiously.
The absolute best way to archive in your scenario and technology would be having some kind of token between your web app / library against your web service and your controller needs to have a thread to check if there are new results etc. However please note that you will require to get the complete data back from your WS as it's merge can result in removed items from the initial response.
Or I still think that handling threads would be better from controller with the use of WCF Webservices
Related
Suppose I have a thousand of hardware device(about 20,000) which send the data in real time. I have to capture this data and send all data to database and also show information in application.For this I am thinking to develop a WCF service which poll all the devices and get the data from devices and store in database.
So my question is "Is WCF efficient to do this or I should follow another approach "
I am thinking to develop a WCF service which poll all the devices
A WCF service cannot "poll". A consumer can poll, which is to say it can call a service over and over again, however there is no polling pattern built into WCF client channel. So any polling behavior will need to be programmed.
So my question is "Is WCF efficient to do this or I should follow
another approach "
What I suspect is that you actually want your devices to call the service and pass data, so what you are actually asking is Can a WCF service handle a high volume of calls?, to which the answer is Yes.
However, in order to get the best scalability you should expose a per-call service, and do this over netTcpBinding (basically sockets), which uses optimised encoding and is therefore higher performance.
This would only be available to a consumer running the WCF client stack. If WCF is not available on your devices then the next best option is probably an HTTP endpoint over webHttpBinding, which provides the best interoperability.
Can you please suggest some other technology?
Well, if you are happy using http on your devices you should look at nancyfx for hosting your service - it's a really nice, lightweight http container for .net.
I am unsure of whether this is possible and have conducted a handful of quick searches on the web and I don't think it is but here goes.
I have a web service (old school .asmx) which retrieves a list of items from a database. I want my client app to be notified if there are any items to be processed INSTEAD of the client app every so often making a request to the web service. Is this possible?
I know this is possible via WCF (duplex communication) however due to complications I can't use that approach.
Oops I just realised that I would also require the web service to poll itself or get something to call it asynchronously? Don't think this is a good solution...
Thanks in advance, Onam.
It is either polling (initiated by the client) or by maintaining a session like Exchange, Imap etc does. Classic .asmx communication is initiated by the client. Therefore it provides no events.
You can implement duplex yourself by developing a callback service hosted by your client. Your webservice can then invoke the callback client. However you must find a good solution to register and unregister the clients to the webservice.
Actually, I would not be a good idea to let the database invoke the items on each poll. You could cache the results in the logic layer referenced by the webservice. If you prefer the classic .asmx approach, you can create a bool method that checks whether new data is in the cache that is implemented by the logic. This would reduce the performance inpact, and then it won't be that bad to poll the server.
We are trying to write an inner wcf service between 2 servers.
one off the application is a server application for our clients.
the clients sends us files and we then process them and converting them.
this whole process takes some time mean while the client session is open, i dont this using async is possible? which way can we make this methodology faster ?
keep in mind that we have aprox 1000 files an hour ...each client sends up to 200 files an hour also
G
You could to send an address to be called back when that file processing is done and it will notify the consumer server. Or to use a message queue on both ends.
This article (link) by Juval Lowy is all about one-way services, wcf call-back methods, etc. It should show you how to set your services up to handle what you're looking for.
One-way services make the call asynchronous - fire and forget. Setting up a call-back does what it sounds like - you can specify a service/method to be called back after a method executes.
Better yet, check out chapter 5 in Lowy's Programming WCF Services (link). It goes into MUCH greater detail than the article above.
I think the first link is enough to get started though.
I want to design a new distributed application, but I have a few queries that I need some genius advice on, hopefully from you people:
Scenario
I currently support a legacy application that is starting to fall between the cracks.
It is a distributed Client-Server app implemented using .Net Remoting. I can't explain exactly what it does, because I'm not allowed to.......But let's just say that it does LOTS of MATHS. I want to re-design and re-write the application using WCF.
Pre-requisites
The server side of the implementation will be hosted in a Windows Service.
The client side will be a windows forms application.
The server side will perform lots of memory-intensive processing.
The server will spit this data out to multiple thin clients (20-ish).
The majority of the time the server will be passing data to the clients, but occasionally the clients will be persisting data back to the server.
The speed at which the data is transmitted is highly-important, however I'm well aware that WCF can handle fast distribution of data.
Encryption/Security is not that important as the app will run on a highly protected local network.
Queries
Given the information above:
1)What sort of design pattern am I best going with? - Baring in mind I want the server to continually PUSH the newly calculated information immediately to the clients, as opposed to the current implementation that involves the client pulling from the server continuously.
2)What type of WCF binding should I use to ensure maximum speed of data transfer? (as close to real-time as possible is what I'm after)
3)Should I use a class library to share the common objects between the client and the server applications?
4)What is the best way in which to databind my objects on the client side in order to see live updates continually as data changes?
If I've forgotten anything then feel free to point this out
Help greatly appreciated.
1) What sort of design pattern am I best going with?
Based on your comments, you're wanting to transform the current polling mechanism to an event-based mechanism. That is, instead of the client constantly checking the server for results, have the server notify the client when a new calculation result is available.
I would recommend using Juval Lowy's Publish-Subscribe Framework for this.
(source: microsoft.com)
.
This framework is described in detail in this MSDN article. And you can download the framework's source code for free at Lowy's website, IDesign.net.
Basically, the server logic that performs the calculations inside the Windows service is the Publishing Client in the graphic, and the various WinForm applications are the Subscribing Clients. The Pub/Sub Service lives in your Windows service. It manages the list of subscribing clients and provides a single endpoint for your server to publish calculation results to. In this way, your server performs a calculation and publishes the result once to the Pub/Sub Service endpoint. The Pub/Sub Service is then responsible for publishing the result to the subscribed clients.
2) What type of WCF binding should I use to ensure maximum speed of data transfer?
If all of your WCF communication were on a single machine, you'd want to use the NetNamedPipeBinding. However, since you will be distributed, you want to use the NetTcpBinding.
For WCF binding decisions, I have found this chart useful.
3) Should I use a class library to share the common objects between the client and the server applications?
Since you are in control of both the client and server side, I would highly recommend sharing a class library instead of using Visual Studio's "Add Service Reference" feature. For a detailed discussion of this, refer to this SO question-and-answer.
4) What is the best way in which to databind my objects on the client side in order to see live updates continually as data changes?
I suspect this will depend on what controls you use to display the data. One way that immediately comes to mind would be to have your client fill an in-memory data table as each calculation result is received. This data table could then be bound to a ListBox control, for example, that shows the results in calculation order.
This to me looks like you need to implement the Observer pattern, but distributed. Whereby new calculations are made to the service, and WCF just happens to be the mechanism by which you push your notification back to the client.
Generally speaking, you have your business logic housed in a windows service, whereby a type is a Subject (Observable). You could publish an endpoint for clients to register for notifications. This would be a WCF service, with potentially two operations:
RegisterClient(...)
UnregisterClient(...)
When a client is registered with service, it can receive updates, broadly speaking, the when the service has finished calculating a result, it could iterate through all registered clients and initiate a push. The push being a communication through an endpoint on the client.
A client endpoint might typically by
Notify(Result...);
And your server simply calls that when it has new data...
Typically you'd use TCP to maximise throughput.
This is by no means exactly what you should do, but perhaps its a direction to start in?
I'm trying to use WCF to implement a comet style server push to an ajax web application.
In my WCF service, I've implemented a WaitForEvents method that calls Monitor.Wait to suspend the thread until new data arrives. At that point, the Monitor is pulsed, and the method returns the new data which closes the comet style request.
The request is made again when this happens.
Currently, this works fine but I noticed that WCF needs to create a new thread for each connected user. This is probably because the thread cannot be returned to the threadpool until data comes in, and so each connected user requires a new thread.
I want to make this implementation more efficient by having one thread service multiple connections. If I were to use a socket, this could be done by leaving the socket open and returning the thread to the thread pool first. When new data arrives, it will be delivered by another thread and we can write the new data directly to the socket and close it.
Does anybody know how this can be done via WCF?
I have been looking at "Push-Style Streaming" http://msdn.microsoft.com/en-us/library/bb472551.aspx and they mention that "WCF implements a "pull" model in which the application code (the service) returns an instance of Stream and relies on the lower-level infrastructure to pull data from this stream and write it out to the network." but I cant find any examples of this one the website.
Many thanks in advance!
Check out nComet
It's not using WCF, but I believe the author is working on a version that uses WCF. Contact him via codeplex and ask him :-)
"nComet is a .NET implementation of
the Comet (reverse-AJAX push)
architecture. This server-side
pipeline uses long-lived
client-initiated HTTP connections to
push messages to the client. Once the
client receives a response, it
immediately opens another HTTP
request, which the server holds until
a message is ready. This architecture
allows the server to push dynamic
html/xml/json/etc to the browser,
rather than the browser polling the
server.
This project is scoped to the .NET
server-side architecture, initially
providing a HttpListener (for a custom
host communicating with HTTP.SYS
directly) as well as a ASP.NET
implementation, where the ASP.NET
implementation can be hosted inside
IIS as well as an external process.
The library will simplify the
implementation of common message
patterns such as pushing the latest
data, as well as sync. Example code
and links to multiple client-side
javascript implementations will also
be provided."
You may also want to check out WebSync, a .NET comet implementation. Works just dandy with WCF.
(Disclaimer: I work for the company).