Firing events from within DataPortal_XXX methods

pfeds posted on Friday, May 19, 2006

I have a situation in which I need to fire events from within the DataPortal_XXX methods that will be received and displayed by the GUI on the client.

To be more specific, I have a User object that represents a user in Active Directory.  I need to call a pre-written service dll to retrieve the user information. During the process of creating a user this dll will fire update events.  I currently pick up these events within the User object but need to send these events back to the client.

Can anyone help?

 

ajj3085 replied on Friday, May 19, 2006

If you're using CSLA 2.0, you could use the ApplicationContext.GlobalContext to send data back to the client, but it won't be returned until after the data portal methods complete.

Would that be helpful?
Andy

pfeds replied on Friday, May 19, 2006

Unfortunately that won't be helpful in this instance as I need the events to be fired during the process.  This is because our "Create User" process does a number of tasks and *may* take up to thirty seconds.

The idea is to display a status dialog when the Create User button is pressed.  This dialog would then display the process stages and also a progress bar to show the user that the application is doing something.

Thanks.

RockfordLhotka replied on Friday, May 19, 2006

It is virtually impossible to do what you describe, and any workaround solution is dependant on the type of channel you are using with the data portal.

Remoting: Two conditions first. 1) The client must have an IP address that is reachable from the server (the server could ping the client). 2) The client must configure itself as a remoting listener before calling the data portal. If you can meet these conditions, then you can (in the client) create a MarshalByRef object and pass that object reference through to the server either in your object or in ApplicationContext. Then the server can use that object to do callbacks to the client. BE AWARE that these callbacks come in on a background thread, so you MUST move the call to the UI thread before updating the UI.

Another alternative with Remoting is to buy a 3rd party channel that does bi-directional TCP socket connections. There are a couple out there. This eliminates the need for requirement #1, which is usually the part that's hard to accomplish in many networks.

EnterpriseServices: I've never tried this, but DCOM events should flow back across to the client, given a reference to a client-side COM object. My guess is that you'd need to expose one of your client objects through COM, then pass a reference to that object to the server so it could do a callback. Again, I've never tried this, so I don't know if it would work.

Web Services: I don't know how to make this work in any meaningful way. I suppose you'd have to be running a web server on the client and pass a URL to the server so it could do the callbacks. But then you'd have to get that callback from IIS into your running client app, so you'd need to use Remoting or named pipes or something.

Bayu replied on Saturday, May 20, 2006

Hey,

Have you ever noticed how accurate the progress bars are in explorer when you are copying a significant amount of data or during the installation procedure of some piece of software?

They aren't. Far from it even. Sometimes the progressbar stays at 99% half of the time, remaining time indicators that only increase, a progress bar that reaches 100% but then there was another one underneath which is still at zero .....

My point being: Microsoft has done a considerable job in making our users slightly sceptic about progress bars. They have learned already that they are merely indicators of 'don't worry, I am still doing something, I haven't died on you (yet)'.

I may sound a little sour, but that is merely to convince you of my point. It is actually a great thing that Microsoft has done for us here, which I have (ab)used many times already, and the 'trick' I am to describe will significantly reduce the complexity of the solution to the issue you describe.

I propose the following:
- you fake a progressbar;
- you don't display the intermediate steps as returned to you by your pre-written dll, simply because it's too complex for what it will provide, agreed: it would be cool and more informative than a progressbar, but is it worth the pain?
- for your progressbar, you maintain the average duration times over the last 10 times a user account was created, you take this average as your best guess for the estimated duration it will take this time and simply loop the progressbar from zero to 90% in this time interval, the remaining 10% is only added when the account was actually created.
- it's a fake, maybe even a fraud, I know, but hey: it's simple and it works! A lot of tweaking is possible of course to improve the reliability of this progressbar, maybe not take the average but the average + 5 seconds to be safe, or you take the longest duration over the past 10 times as an estimate, you can do lots of stuff. In any case: you are informing the user in  a meaningful way, and that's what it is all about.

Are you disappointed by being advised to implement something fake?

Let me know what you think of this!

Bayu

pfeds replied on Monday, May 22, 2006

Rocky, thanks for the reply.  I had condsidered the remoting method but figured it was not an ideal solution.  I was hoping there would be a simpler solution, but I guess not!

Bayu - I know exactly what you mean ;o)  However I am very reluctant to use a fake progress bar - I would rather just display a "Please wait..." type of dialog.

I did consider a workaround using commands.  In this way the process could be broken up and I could call each command individually, updating the progress information after each one.

To be more specific, the process in hand involves creating a user in Active Directory, and then creating the user account in various tools.  If this were to be broken down I could have the following commands:

CreateUserInActiveDirectoryCommand();

CreateUserInToolsCommand(); .

..and so on.

Does this sound like a feasible solution to my problem?  Unfortunately for me, the developer who is creating the underlying service is *very* reluctant to break up his processes so I can call them seperately, and yet he is adamant that I display the progress information.  He is pushing for me to comprimise the architecture of the application so that it runs on a single machine and fires local events, despite a possible requirement for the application to be remoted.  Naturally I do not wish to agree to this nonsense, but unfortunately he has seniority :o|

Alternatively, can anyone comment on Petar Kozals ActiveObjects framework, and will this provide a solution to this problem?

Many thanks.

Bayu replied on Tuesday, May 23, 2006

Yes,

Breaking it up in commands is one solution. I guess it is another 'clean' (without my fake stuff at least ) way towards side-stepping those events which is actually quite easy to implement as well.

Regarding your co-worker .... what is the problem with breaking it up? To me it sounds like the process isn't atomic by itself anyway ...? Breaking up the process will surely break atomocity more than it was before, his/her service will become less self-contained. But on the other hand, breaking up the stuff may also yield some new flexibility that wasn't there in the past.

I can not answer your question about Active Objects, so I'll leave that one open for someone else. ;)

Anyways: I strongly recommend to stay at your current standpoint regarding remoting, you surely will not want to wipe this from your options list just for some UI-fanciness.

Good luck!
Bayu