How to guarantee delivery of data in a Compact Framework Webservice call? - web-services

We have a mobile Application in a very unsteady WLan Environment. Sending Data to a webserver could result in a timeout or in a lost WLan connection.
How do we ensure, that our data is delivered correctly? Is there a possibility of having Web Services Reliable Messaging (WSRM) on the device?
MSMQ is no option at the moment.

WSRM isn't supported. A reliable mechanism is to ensure that either the Web Service responds to the upload with an ack after the data has been received (i.e. a synchronous call) or that when you start the upload you get back a transaction ID that you can then send back to the service at a later point to ensure that it has been delivered before local deletion.

Related

Choosing a Template for Communication between Client and Server on ZeroMQ

I am making an application in C++ for Windows, which consists of a Client and a Server. The Server manages the Device.
The Client sends to the Server commands like:
Start Device
Stop Device
Set Device Gain
Set Device bandwidth
Get Device status
Data must be transferred from the Device to the Client for display on the screen. Data is arrays of complex numbers. There will be a lot of data, since there can be several Devices.
I developed my own command format, which is converted to JSON and then to a string.
I'm having a hard time choosing a template for ZeroMQ sockets. For data transfer, I chose the PUB-SUB pattern: the Server is the Publisher, and the Client is the Subscriber.
For sending commands, I also chose the PUB-SUB pattern, but in this case the Client is the Publisher, and the Server is the Subscriber.
In both cases, all messages received by the Subscriber are queued and further parsed.
This approach is very primitive. Perhaps you can suggest me more advanced templates? It would be great with sample code for Client and Server.

Azure EventHub: offline event buffering/queueing possible?

I can't find any definitive answer here. My IoT service needs to tollerate flaky connections. Currently, I manage a local cache myself and retry a cloud-blob transfer as often as required. Could I replace this with an Azure EventHub service? i.e. will the EventHub client (on IoT-Core) buffer events until the connection is available? If so, where is the info on this?
It doesn't seem so according to:
https://azure.microsoft.com/en-us/documentation/articles/event-hubs-programming-guide/
You are resposible for sending and caching it seems:
Send asynchronously and send at scale
You can also send events to an Event Hub asynchronously. Sending
asynchronously can increase the rate at which a client is able to send
events. Both the Send and SendBatch methods are available in
asynchronous versions that return a Task object. While this technique
can increase throughput, it can also cause the client to continue to
send events even while it is being throttled by the Event Hubs service
and can result in the client experiencing failures or lost messages if
not properly implemented. In addition, you can use the RetryPolicy
property on the client to control client retry options.

Asyc API method

I'am working on a project that exposes a Web Api for Encrypting files and doing other tasks. What I want is to make the encryption task async, this is because files could be of size more than 1GB, and I donot want the client to keep waiting for the file to be encrypted. What I want is that once request for encryption is sent to the api the client is notified that your request is accepted and when it finishes a notification about success or failure is sent to the client again. Meanwhile client can do anything.
What are the best practices for this, moreover Iam working in asp.net mvc
You need to off load the encryption task to another thread in your serve. This will free up (complete) the request processing thread, and the client can continue with other stuff. You can wrap the encryption task such that after successful completion or failure, a callback is invoked. This callback must be responsible for notifying the client back.
To notify the client back, upon completion of the encryption task, you have several options, that you must code within your callback:
Email the client of the result.
If the client is a service and listens on a specific port, you can accept a callback URL in the initial encryption request, and can invoke this URL after encryption task. The assumption is that the client is running a http Service.
If there are any other integration points with the client (like filesystem, database, message oriented middleware), then use those to notify of task completion.

What kind of network protocol should be used in this scenario?

Well...
I am working with an mobile application and a web server.
A characteristic of my web server is that it generates different set of data randomly. In other words, I cannot predict when the server will have ready data to send to the mobile app.
On other hand, the mobile app need to receive all data that the server generates. An approach could be request multiple times to get all these data. Indeed, It isn't a good approach, because I don't know when request the data.
If the mobile app could listen the server, after one start request or keep on the connection, for example, the server could sent any set of data in any time.
The question is: What is protocol suitable to this situation? How could I use that? Examples?
Thank you!
You could create a persistent TCP/IP connection to the server and permanently listen for incoming data (using a custom protocol or propably something websocket based). However such a permanent connection might seriously affect your battery life if it's for a mobile device. You will also lose the connection if the operating system automatically shuts down your application because it's out of memory.
The default approach to this problem are Push notification / Push services, where your server sends a notification about new data to a server of the phone provider (e.g. Microsoft or Apple push server), and this server sends the notification (as well as notificaiton from other online services) to your phone.
Some info for Windows Phone:
http://msdn.microsoft.com/en-us/library/hh221549.aspx
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402558%28v=vs.105%29.aspx
Depending on how often you have new data both approaches can make sense.
WebSockets could be the answer: http://en.wikipedia.org/wiki/WebSocket
Specifically, for Windows Phone, there's a solution also: http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff402558(v=vs.105).aspx

Biztalk web service ports and what happens when the port/application is stopped

I have a question around biztalk and what happens when certain conditions around web service ports are met.
basically we have two applications - a main application (lets call it 'MainApplication') (containing the orchestration) and a web service application (lets call it 'MainApplicationWS'), where we expose a web service (created from biztalks web service tool) to take messages from wherever.
we have a testing tool which replays messages to the MainApplicationWS to simulate messages coming through from various external systems.
I have noticed that if we partial stop the MainApplicationWS application, and send messages through to the web service listed as a recieve location, nothing happens (obviously!) (also, the web service is still running, even though its been delisted as a recieve location). however, if i start up the MainApplicationWS again and bounce the host instances the messages are picked up from somewhere and played through to the orchestration and through to our application.
Im just a bit puzzled as to where its storing these messages while the MainApplicationWS is partially stopped. is the web service somehow hanging on to these? or does it still post through to the biztalk message box?
any clarification would be greatly appreciated :)
cheers,
adam
In short, I can't repeat your behaviour in Biztalk 2009. The closest to 'queueing' messages is if the orchestration is stopped but remains enlisted, such that messages are suspended resumable.
In long - I'm not quite sure what you mean by 'delisted as a receive location'. In Biztalk 2009:
Receive Locations can be enabled or disabled
Orchestrations can be stopped, and unenlisted
A Partial Stop on your BTS application disables receive ports and stops orchestrations (but doesn't unenlist them)
A full stop stops and unenlists orchestrations
The below is observed behaviour on BizTalk 2009 for a simple orchestration with a WCF Request/Response port, which receives a message, Maps the Send back to the same Port
The port is Direct Bound (MessageBox).
If the Isolated Host App Pool is disabled in IIS
A synchronous error is returned to the client - Standard IIS Error (503 Service Unavailable etc)
BizTalk receives no messages at all
If the BizTalk receive Location is disabled
WSDL: Syncrhonous error returned to the client - The Messaging Engine failed to register the adapter for "WCF-BasicHttp" for the receive location "xyz.svc". Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases
Service Call : The requested service, xyz.svc could not be activated. See the server's diagnostic trace logs for more information.
If the Orchestration is stopped, but not unenlisted
The received message is Suspended, resumable. The client times out (no response is issued).
If the orch is started and the message resumed, the message is then processed. The client will only get a successful reply if the orch start and the suspended message resume are done before the client's configured WS / WCF timeout.
If the Orchestration is unenlisted
The received message is Suspended, not resumable.
The client receives an error - The server was unable to process the request due to an internal error.
With the WCF CustomBinding it is also possible to listen directly on the relevant BizTalk ReceiveHost (i.e. no need for IIS at all to listen to BasicHTTP or WSHTTP, although we generally still use the Wizard generated svc in IIS solely for the hosting and publication of the WSDL. We then create a new WCF Custom receive location directly in BizTalk and point the client to this)
Hope this helps?