Yes this now makes sense :)
In my opinion if you want to make your API easy and natural I would stick to
the asynchronous design pattern used in the .NET Framework (BeginXXX, EndXXXX)
because this is what users are used to.
Here is what I'm thinking (no idea if this is possible or it would work!):
public class MyClient{
private IAsyncProxy<IMyWcfService> asyncProxy;
public MyClient(IAsyncProxy<IMyWcfService> asyncProxy){ //IoC would do its
job here
this.asyncProxy = asyncProxy;
}
public void DoIt(){
AsyncCallback callback = new AsyncCallback(
ar => asyncProxy.EndGetSize(ar)
);
IAsyncResult result = asyncProxy.BeginGetSize(line, callback);
}
}
The IAsyncProxy wrapper proxy would have to generate BeginXXX and EndXXX for
the IService. I'm not sure if this is possible to do with DP2 ?
Anyway this is just my opinion, and there is possible other factors that I'm
not seeing.
Cheers
John
________________________________
From: Krzysztof Kozmic <[email protected]>
To: [email protected]
Sent: Thursday, 7 May, 2009 5:53:12 PM
Subject: Re: WCF Facility - Client proxy async calls
Oh now I see.
Well, there is nothing that stops you from doing that with WCF now.
However, that's not what i'm trying to achieve.
If you do it that way here's simplified model of what happens under the covers:
- you fire up the request on a thread pool thread.
- on that thread wcf serializes the messsage packs it up queues it its to-send
queue
- then WCF blocks that thread waiting for the response
- on its own worker thread WCF then pushes the request to the server
- when the response comes back (or on timeout). WCF unblocks the thread and
let's it chew up the response message (or timeout exception)
As you see this is not the most efficient. Basically what's wrong about this
approach is that network request is an IO bound operation, not CPU bound
operation, and doing it this way, is very inefficient.
the whole point of my code is to use WCF built in facility to perform network
calls asyncronousely, which works basically like this:
- you fire up a request on BeginFoo method
- on your thread wcf serializes the messsage packs it up queues it its to-send
queue and returns
- on its own worker thread WCF then pushes the request to the server
- when the response comes back (or on timeout) WCF runs on yet another thread
the AsyncCallback method you provided as second to last parameter of BeginFoo
method and let's it chew up the response message (or timeout exception)
As you hopefully can see this second model is much more efficient, but
unfortunatelly you need the BeginFoo EndFoo methods to use it.
Ok, as I prooved you don't need them phisically, but WCF must think you have
them. Now the whole point of this syntax debate is to try to find easy and
natural syntax to change the following set of inputs and outputs:
[string] - [int]
into
[string, AsyncCallback, System.Object] - [nothing]
plus
[IAsyncResult] - [int]
I hope that's clearer now.
Krzysztof
>>> [email protected] 2009-05-07 09:32 >>>
Sorry Krzystof, maybe this example explains my thinking:
public static void ExecuteWcfAsync<TChannel>(Action<TChannel> proxy) where
TChannel : class
{
TChannel generatedProxy = container.Resolve<TChannel>(); //Need to use IoC
here to get the TChannel from container
ThreadPool.QueueUserWorkItem(state => proxy.Invoke(generatedProxy));
}
The idea is to actually do the async bits inside the ExecuteWcfAsync method.
And if you don't want to use the .Net Thread Pool you can write your own
threading.
________________________________
From: Krzysztof Ko mic <[email protected]>
To: [email protected]
Sent: Thursday, 7 May, 2009 4:02:20 PM
Subject: Re: WCF Facility - Client proxy async calls
John,
Are you familiar with how async pattern works?
What you suggested looks great except that it won't work.
The GetSize syncronous method can't be used to return a value, because to do
that it'd have to execute syncronousely, rendering the whole effort useless.
Since it can't return IAsyncResult as it should, because it would cause a
runtime error, it retuns null (or 0 for value types).
The point is to somehow make up for the absence of actual methods:
IAsyncResult BeginGetSize(string line, AsyncCallback callback, object someData);
int EndResult(IAsyncResult);
Code similar to your could work if you used Expression classes, but I'm
resisting using them unless I have to.
I appreciate your help, if you want ping me and I'll send you the actual code.
I'm not going to publish it yet, since it's lacking a lot a the moment, but it
is working and if anyone else wants to play with it, just drop me a line.
Krzysztof
John Simons pisze:
I'm not very keen on all those casts.
And it doesn't seem natural to call proxy.GetSize(line); and not assign the
result to anything!
Have a look at http://paste2.org/p/199716
Cheers
John
________________________________
From: Krzysztof Ko mic <[email protected]>
To: [email protected]; [email protected]
Sent: Thursday, 7 May, 2009 5:47:22 AM
Subject: WCF Facility - Client proxy async calls
I'm working on adding to WCF Facility support for async calls from
client side (similar to what can be done with SvcUtil-generated
proxies), when using channelfactory and intereface contract only.
Something like What Ayende wrote about here:
http://ayende.com/Blog/archive/2008/03/29/WCF-Async-without-proxies.aspx
but without having to write IAsyncBus
I have very rough (but working) implementation.
But...
given we don't have an actual async methods to call, we have to have an
alternative syntax (well, at least until C# 4.0 and IDynamicObject, but
that's another story)
http://paste2.org/p/198506 here's what I came up with.
I encourage you to discussion about it. If you have alternative, better
ideas, you can show it here: http://paste2.org/followup/198506
Thanks,
Krzysztof
________________________________
Enjoy a safer web experience. Upgrade to the new Internet Explorer 8 optimised
for Yahoo!7. Get it now..
________________________________
Yahoo!7 recommends that you update your browser to the new Internet Explorer
8. Get it now..
CONFIDENTIALITY NOTICE
This message is intended exclusively for the individual or entity to which it
is addressed. This communication may contain information that is proprietary,
privileged, confidential or otherwise legally exempt from disclosure. If you
are not the named addressee, you are not authorized to read, print, retain,
copy or disseminate this message or any part of it. If you have received this
message in error, please delete all copies of this message and notify the
sender immediately by return mail or fax ATSI S.A.(+4812) 285 36 04.
Any email attachment may contain software viruses which could damage your own
computer system. Whilst reasonable precaution has been taken to minimise this
risk, we cannot accept liability for any damage which you sustain as a result
of software viruses. You should therefore carry out your own virus checks
before opening any attachments.
Enjoy a safer web experience. Upgrade to the new Internet Explorer 8
optimised for Yahoo!7. Get it now.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
