In our application we have a back-to-back-connection between an operator (client) and a caller, via an ucma-application we built. Now we want to transfer the caller to another operator or number.
This transfer is attended, so we want to keep the call in the client at least until the transfer is completed.
The client application tells the ucma-application to do the transfer. As such, the server makes a transfer on the leg from ucma -> caller. In this scenario, the leg from ucma to the client application remains intact, but we want to receive information about this transfer so that we can show the transfer status in the client application. If the transfer fails, it should also be clear to the operator (it should also be on hold during the time of the transfer, and continue to be on hold even after transfer failed).
Which is the correct way to do this in UCMA?
It's hard to give you advice as there are multiple ways to do what you want depending on what you need to achieve.
I think the main problem is that you are doing the transfer in the middle, you can't tell the Lync Client to go on "hold". Because of this, you can only put the call on hold from the point of view of UMCA application. This means that if you will have to provide your own UI to unhold the call if it fails, maybe from your own Client Application GUI.
What you could do is write a Lync Client SDK controlled Lync Client application. If you have a Lync Client SDK controlled Lync Client, you could remote control the Lync Client to do the transfer, that way you get the standard Lync Client failed transfer UI. If you do this, what is the point of the UCMA application?
If you have to do it from the UCMA point of view, you could:
Provide the UI in your only Client Application (I would think no nice) including controlling the hold status on a failure
Lync Client SDK controlled Lync Client to put the call on Hold that way it's the standard Lync Client way to unhold on failure, then the only need to worry about the display of a failed transfer. Maybe display something in your client application, maybe a send a in call IM from the UCMA application?
See if the Lync Client support BoardWork Extensions (specifically the Remote Control Hold Event Package). If it does then you can remotely put the call on hold, most likely though that it doesn't :(
Related
I am experimenting with using Reactive Extensions to create a Windows Service.
Essentially what I want is for the Observer to sit on the server, the clients able to create observables and have them pushed to the server, the server informing the client of the progress of the job (not sure how to do this or what mechanism to use to do it), and then when it's done, having the server send the client the return code and output of the program it called. Can this be done? Is it the best way to do what I'm trying to do? If you need any more information, what would you need to know to help me?
This seems back to front. Generally clients know about servers (how to find then and connect). In contrast the Observer pattern (and therefore Rx) is about allowing something to callback to another observer that is does not know about.
In your case I think you simply want to have clients call methods on a server. Potentially these are bound to a single connection/session. The client however maybe an observer of the progress from the server and the final result.
See the Reactive Trader project by the team at Adaptive to see a .NET client server app using Rx.
I am working on a hardware/software application where, connected via usb, is a device that does some off board processing on some data. The application is meant to be open multiple times and which device needs which data is identified by an in-stream parameter. My question is, can more than one application claim an interface? my first implementation used WinUSB but I quickly realized that that limits me to only one instance. The libusb documentation claims that this limitation is removed in their driver.
My concern is, because I intend to have far more than 8 instances running, having only the 8 interfaces allotted will not be sufficient. If I cannot, in fact, claim an interface more than once, is there a method where I could have the applications call a shared library that claims the interface and manages and routes traffic between the applications?
As far as I know you can only have one handle open to a device in either implementation.
I think you are on track in terms of how to handle this problem. The way I have done something like this in the past is to create a service that is to run in the background. This service should be launched by the first instance of the application, and can keep a reference count of it's clients. On your next instance of the application increment your reference count, and whenever a client application closes decrement the reference count. When the last application closes the service can close too.
The service would have the job of opening the device and reading all data in to a buffer. From there you can either put smarts in to the service to process the data and load it in to different shared buffers that are each individually accessible by your other client application instances, or you could simply make one huge buffer available to everyone (but this is a riskier solution).
I am novice in WCF and I have a project that needs to be migrated into WCF communication base with the client/server and server to server architecture.
My question is what is the right messaging function that I need for this project that insure the security of data across the network ,reliable connection and speed exchange of data.
I was able to find out the WCF has numerous messaging function.
Below is the architecture of my project:
Note: The clients should be simultaneously updated by both data processing and feed source servers. And clients also sends simultaneous requests to the servers while feeds are still being supplied by the feed source server.
I would be appreciate any suggestion or comments.
My first question is why are you putting the Connection Manager (CM) component in-between your clients and the services which they want to use? What is the job it does which means it needs to be right in the middle of everything?
This ultimately means that your CM component will have to handle potentially high volumes of bi-directional traffic across potentially different transport bindings and introduces a single failure point.
What if client A wants only to receive messages from the Feed Source (FS) component? Why should client A have to deal with an intermediary when it just wants to send a subscription notification to receive updates from the FS?
Equally, what if client B wants to send a message to the Data Processing (DP) component? Surely it should just be able to fire off a message to DP?
I think the majority of what you want to do with this architecture can be achieved with one-way messaging, in which case you should use netMsmqBinding (assuming you are in a pure wcf environment).
I'm building an application, it's easy and what I want to do is the following. I want a brainless client and all the work should be done on the server. So I want a way to change windows forms in my server application and not on the client itself.
So when I have an application like blackjack the user presses hit then the hit function on the server get called, he will calculate everything, send the result back to the client and then the client updates it buttons and GUI (like displaying cards, and so on).
Now how do you do this in WCF? I know how to call remote function but I can't get the windows forms part to work (can I add this in the contract, and how?)
Thanks!
Your client should handle all of its own UI. Your service shouldn't have anything to do with the UI.
Instead of having the service handle the UI, just have it send messages back to the client and let the client figure out which UI elements to show or not based on the messages.
So, when the server calculates some result, like BLACKJACK!, it'll send a message indicating that back to the client which will then show the proper UI elements.
Make sense?
I have asp.net site where I call my WCF service using jQuery.
Sometimes the WCF service must have an ability to ask user with confirmation smth and depend on user choice either continue or cancel working
does callback help me here?
or any other idea appreciated!
Callback contracts won't work in this scenario, since they're mostly for duplex communication, and there's no duplex on WebHttpBinding (there's a solution for a polling duplex scenario in Silverlight, and I've seen one implementation in javascript which uses it, but that's likely way too complex for your scenario).
What you can do is to split the operation in two. The first one would "start" the operation and return an identifier and some additional information to tell the client whether the operation will be just completed, or whether additional information is needed. In the former case, the client can then call the second operation, passing the identifier to get the result. In the second one, the client would again make the call, but passing the additional information required for the operation to complete (or to be cancelled).
Your architecture is wrong. Why:
Service cannot callback client's browser. Real callback over HTTP works like reverse communication - client is hosting service called by the client. Client in your case is browser - how do you want to host service in the browser? How do you want to open port for incoming communication from the browser? Solutions using "callback like" functionality are based on pooling the service. You can use JavaScript timer and implement your own pooling mechanism.
Client browser cannot initiate distributed transaction so you cannot start transaction on the client. You cannot also use server side transaction over multiple operations because it requires per-session instancing which in turn requires sessinoful channel.
WCF JSON/REST services don't support HTTP callback (duplex communication).
WCF JSON/REST services don't build pooling solution for you - you must do it yourselves
WCF JSON/REST services don't support distributed transactions
WCF JSON/REST services don't support sessionful channels / server side sessions
That was technical aspect of your solution.
Your solution looks more like scenario for the Workflow service where you start the workflow and it runs till some point where it waits for the user input. Until the input is provided the workflow can be persisted to the database so generally user can provide the input several days later. When the input is provided the service can continue. Starting the service and providing each needed input is modelled as separate operation called from the client. This is not usual scenario for something called from JavaScript but it should be possible because you can write custom WebHttpContextBinding to support workflows. It will still not achieve the situation where user will be automatically asked for something - that is your responsibility to find when the popup should appear and handle it.
If you leave standard WCF world you can check solutions like COMET which provides AJAX push/callback.