I have a Linux/c client app that connects to a WCF web service over HTTP/SOAP (BasicHTTPBinding). I am using gSOAP. Can I implement the calls to the web-service using callback? I want to get the data asynchronously as call back.
Update: I have updated the question title.
WCF does support Duplex services, or those that have the ability to call back to the requesting client. Duplex services can be very complicated, as they are not only stateful, but they impose an contract implementation requirement on their clients.
Duplex services require the use of the WSDuplexHttpBinding. You will need to make use of the OperationContext to get a reference to the callback channel. Your clients MUST implement the callback contract in some class, and provide an InstanceContext that contains an instance of the callback class to the client proxy. Communications in both directions must be supported, and if the client is behind its own firewall or across the internet, this can be a complicated matter to resolve. Take care when writing duplex services...they are often more trouble than they are worth...so make sure you really need it. ;-)
The following page might be helpful:
http://msdn.microsoft.com/en-us/library/ms731064.aspx
The basicHttpBinding does not support callbacks. Another approach might be to have another method that the client can poll on for the response.
I am facing the same issue and the approach I am trying is to have a pair of gsoap servers/clients. Basically each process will listen on a port for soap calls and make its client calls to the other server. This way I avoid the polling or other complex approaches. The code has to be obviously thread safe for whatever business logic is implemented but the client/server combo pair is the simplest solution i have thought of so far.
Obviously one needs to be in control of both sides of the solutions the mentioned server and the mentioned client.
Related
I'm creating a wcf project with a wpf client using mvvm design pattern,
Where do I need to implement the ICallback interface so I will be able to update the
window.
The callback contract should be implemented on the client-side. Likewise, the service contract should be implemented on the server-side, with which the server can send data to the client-side by the callback contract.
Please refer to my example of the previous post.
TimeOut exception in WCF while implementing duplex
the client sends a parameter to the server by using the service interface, subsequently, the server sends the handled result to the client with the callback contract so that the client application gets the updated.
Feel free to let me know if there is anything I can help with.
I'm not sure if I'm on the right lines but this is what I'm trying to do, I have a Silverlight application and a WCF service, the Silverlight app "subscribes" to the WCF service using PollingDuplex and the service can send data to any connected clients which works.
The service is marked with [ServiceContract(CallbackContract = typeof(IServiceCallback))] and it is single instanced
The problem is there is another service which should be able to call a standard method on this service to pass it data that will get distributed to the connected Silverlight clients, but because of the above settings it requires it to use callbacks (I can't change the other service).
Is there a way to have both types of operations, callback and standard in the same service if that makes sense?
Thanks for your time
Yes. It is possible. I guess CallbackContract parameter will not stop you from using your service as a regular request/response service (though I have not tried it).
But for the same contract, you may have to define two end points with different bindings, one with PollingDuplexHttpBinding and another one with basicHttpBinding (with silverlight this is the only other option).
You have to make sure that you are calling the right operation from the clients using duplex and basic http bindings.
I am using a WCF service between the Client side UI (Silverlight 3.0) and the Data Layer. We are using NHibernate for Database Access. So please tell me if my below understanding is correct or not:
UI calls WCF for a Save Method (for eg).
The WCF has a Save method in it which actually encapsulates a Save method from the Data
Access Object.
The Data Access Object method of Save in turn encapsulates a default Save Method of
NHibernate which actually saves some Business Object/s into the Database.
Also can someone tell me that how do we pass objects from WCF to the UI (Silverlight 3.0) layer and vice versa. I have read that we use DTO for that. But how does a DTO work? Do they correspond to the 'Data Contracts' in the WCF? If not then is the DTO declared on WCF (server) side and Client side code as well?
No, not quite....
UI calls the client-side proxy method Save
the WCF runtime takes that call and all parameters being passed in, and serializes them into a message (typically a XML serialized message)
the WCF runtime sends the serialized message over some kind of a transport media (whatever it is)
on the server side, the WCF runtime takes the incoming message
the message is deserialized, the appropriate class and method to handle it are identified
typically: a new instance of a service class is instantiated to handle the request
the WCF runtime unpacks the parameters and calls that appropriate message on the service class
same steps - basically backwards - are done for response
Important point: the only thing between the client and the server is a serialized message (which could be sent by e-mail or pigeon courier) - there's no other connection - no "remote object call" or anything like that at all
marc_s mentions the client-side proxies, which can be generated via the service references in your Silverlight project. The generated proxies are decent enough and provide an async model for running requests from the Silverlight side; those will look mostly like remoted procedure calls.
Another approach is to use the leaner (but maybe more advanced?) channel factory directly. A simple example of that can be found here. Both methods take care of most of the serialization details for you.
I understand how I can use a raw socket to listen to a server application and recieve information but I need an easy to access API and I am very familiar with REST.
Is there a way to push (not by using long pooling) data using a WCF service?
Here's my idea of how things should happen, at least at the begining:
The client accesses a URI with it's access parameters (ip, port, apikey).
The server responses with success/failure.
The server opens a socket for each channel with the client's details.
The server accesses a URI indicating that all channels are now streaming.
But how do I wrap the client or the server socket to access a URI?
Edit:
Maybe I should open a socket that notifies about changes on a channel and on the client side require that it will listen and raise the event accordingly.
This is not a very generic solution isn't it?
You should look into the Net.TCP binding, as described by Tomek (one of the WCF team members) here. You use it more-or-less like you would use the HTTP Duplex binding (i.e., the HTTP Long Poll), but it's much, much faster. It's still more complicated than REST, but it's dramatically easier than sockets, and I don't think you'll find a REST-type solution that does what you need.
Can anyone think of a good way to allow the server to notify the client based upon server processing? For example, consider the following events:
A user requests a deletion of data, however, due to it's long-running time, we kick it off to a queue.
The client receives a "Yes we completed your transaction successfully".
The server deletes the item and now wants to update any local structures any clients may be using (I'd also like to notify the user).
I know this can be done by client-side polling. Is there a event bus type way to do this? Any suggestions are welcome, but please keep in mind I am using GWT with App Engine.
The standard AJAX interaction is that the client sends requests to the server and expects some sort of response back fairly quickly.
In order for the server to initiate a request to the client, you will need to use WebSockets, and experimental HTML5 feature currently only supported by Chrome.
Or, to simulate this kind of interaction, you can use Comet (long-polling), made available in GWT by the rocket-gwt project.
You want server events for GWT? Have a look at GwtEventService (they couldn't have chosen a better name): http://code.google.com/p/gwteventservice/wiki/StartPage
Of course, it uses a Comet implementation, but you can't do any different when using HTTP, the client always initiates the communication. Request, response.