Understand() - All Comments

re: Serializing (Binding, Address) Pairs in WCF

Magnus — Mon, 10 Mar 2008 11:57:00 GMT

Hi.

I have a lot of clients who I don't want to update manually, so i'm writing code to automaticly genereate proxies contracts etc, so far so good. But is there any way to serialize the endpoints setting to disk, i.e. the ServiceEndpoint object, so I don't have to generate it each time? I can't see how your code will do that.

Thanx.

re: Facebook Redesign & New Job

arjun — Thu, 21 Feb 2008 22:19:00 GMT

blog more!

re: Serializing (Binding, Address) Pairs in WCF

Thomas Schissler — Fri, 23 Mar 2007 16:14:00 GMT

Great article!

I'm looking for a way to serialize a complete endpoint. I tried your code above, but found, thet with this onle the binding type (basicHTTP, NetTCP) is serialized. I didn't manage to serialize the parameters of the binding. For example if I want to set the AllowCookie Property of the basicHTTBinding to true, serialize the endpoint and deserialize it, this setting is lost and I have the default value which is false. Any suggestions how to solve this?

re: A Philosophical Argument for P != NP

mikedb — Sat, 09 Dec 2006 14:44:00 GMT

i don’t buy this argument.

if p=np is true, it may be only because the degree of the polynomial-time algorithm that solves the np-complete problems has an exponent of the order of magnitude 2**(2**m), where m = 1000! (say, just for the sake of argument).

then the polynomial time solution of any np-complete problem would be known to require no more than n**(2**(2**1000!)) steps, and so p=np would be true.

but I don’t know how much different the world would look to us if this were the case.

for example, i don’t think that if the above version of p=np were true, everyone would be a mozart or a gauss or a warren buffet, or that evolution would be much more expeditious than we’ve observed so far.

of course, once a sufficient amount of history has been accumulated, we might notice that we’d been solving np-complete problems significantly faster than we would have expected if p!=np were true.

even then, without a rigorous mathematical proof, we still wouldn’t know whether we were successful because p=np is true, or because, like warren buffet, we were just plain lucky.

re: Facebook Redesign & New Job

nor58 — Sat, 09 Sep 2006 05:15:00 GMT

Hello! I’ve just recently checked your blog. You seem to have very intersting and informative posts. Guess, I’d be hanging around and see more of your latest posts. It was only then I knew about Facebook. Still thinking if I wanna get myself registered on it.

re: Facebook Redesign & New Job

Steve — Wed, 06 Sep 2006 20:10:00 GMT

Here is a live counter of the number of people who have joined the "Students against Facebook News Feed" group on Facebook..... 300,000 and climbing

http://digg.com/tech_news/Facebook_Stalker_City_Includes_LIVE_Counter

re: Area Codes

Yoda — Wed, 05 Jul 2006 02:39:00 GMT

Don is absolutely correct. Also, when "direct distance dialing" was invented in 1951 (see http://www.att.com/attlabs/reputation/timeline/51trans.html), 212 was all of New York City, not just Manhattan, and it was still that way when I moved to NYC in 1972. 310 being split off from 213 in Los Angeles and 908 being split off from 201 in northern New Jersey came much later.

re: Area Codes

Don Box — Fri, 19 May 2006 07:01:00 GMT

I'm pretty sure that the original design required the 2nd digit of the area code to be a One or Zero.

Back in the 1960's (when I learned to dial a telephone), inter-areacode calls did not use today's "1-" prefix. I believe they relied on the 2nd digit being 0 or 1 to indicate whether you were calling out of your area code or not.

The addition of "1-" happened (I think) in the late 1960's or early 1970's to allow area codes to have an arbitrary 2nd digit.

DB

re: Area Codes

Brian A. Randell — Tue, 25 Apr 2006 13:34:00 GMT

Yes, the '909' came along much later (~1992 IIRC). Up until then it was part of 714--Orange County. 909 recently (~2004 IIRC) was overlayed with 951 also.

re: Fancy Addressing in WCF

Mike Vernal — Tue, 21 Mar 2006 13:01:00 GMT

Whoops, sorry. I had a typo in my code (I was creating a ChannelFactory parameterized by QueryContract, but I was then creating a QueryCallbackContract.

Looking at the thread, Michelle resolved the issue in the most common way (typically this pattern is used with [ServiceContract(CallbackContract ...))]. In this particular case, I was actually intentionally not using CallbackContract (there are two separate contracts, each linked in app-code and not in infrastructure-code).

Cheers,
-mike

re: Fancy Addressing in WCF

melack — Sun, 26 Feb 2006 16:37:00 GMT

Hey, Mike!

Have a question. I tryed your sample but I cannot get the service callback channel to work. Here is my code example:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=249131&SiteID=1

Can you tell me what am I doing wrong?
Thanks.

[melack]

re: Greetings

Alex — Mon, 06 Feb 2006 16:31:00 GMT

Be careful, Mike! you don't want this information to fall into our competitors' hands. imagine their resultant effectiveness!
-- Alex (Dej)

re: Fancy Addressing in WCF

Mike Vernal — Thu, 02 Feb 2006 15:54:00 GMT

Broadly, I think it's if either (a) you want greater decoupling between the request and the reply or (b) you're doing a multicast request-reply operation.

For (a), you can imagine "async" scenarios where I want to be able to send you a message with some work that might take 4 weeks to process. Instead of holding open an HTTP request during that time, I might just want to send the message and then have the recipient call a service of mine at some point in the future.

In WCF, we support doing this to a certain extent with Duplex channels, but it's probably not the case that you would leave your client-side channel open for 4 weeks.

Instead, you'd probably define a WebHosted-service that would spin-up when an incoming request comes in, process the message, and then spin back down.

For (b), one common pattern that I think you see in multi-party interactions is that the query will go out over some multicast channel (e.g., NetPeerTcpBinding, or a theoretical UdpMulticastBinding) and that the response should come back over a point-to-point binding (e.g., NetTcpBinding, or UdpBinding).

Technically, I don't think this pattern is strictly request-reply as it's really single-request, multiple-responses. That said, I think it's still useful to leverage the addressing mechanisms to implement this scenario.

Cheers,
-mike

re: Fancy Addressing in WCF

brad — Thu, 02 Feb 2006 12:40:00 GMT

cool, but I don't get why the implementation of the Query operation wouldn't use the QueryCallbackContract...

ChannelFactory<QueryContract> factory = new ChannelFactory<QueryContract>(binding, replyTo);

re: Greetings

rick — Tue, 31 Jan 2006 17:12:00 GMT

Excellent first rant. Makes one feel good to know that a company is successful enough to not only have middle managers with little more to do than plan successful meetings AND have clever poster people to draw cartoon meeting posters about them. Currently I have to draw my own cartoons and for some reason I always make myself look unhappy to be in my meetings...