|
|
Thursday, May 10, 2007 - Posts
-
I just love this stuff and maybe its my particular humor? This is a valley like thing to do, but it is from a cork/irish based company? What is the cork/Irish response? see here Oh lord!!! Sorry my humor is out of control?!?! Do we need a Irish Valleywag? or a GreenWag? Who knows, just thought I would share the moment :) /P For more information, go to http://www.paulfallon.com . Read More...
|
-
My good friend Peter Van Dijck has a excellent post ( even if I want to make fun of it ) that covers his research on how others have talked about scalability. The blog entry can be found at this link . I would highly recommend you bookmark the link(s). /Paul ps <Thought of the day> For all of the good that MS does in the community , I do wonder sometimes why they(/MS) leave themselves so open to the question that their stack cannot work on an internet scale? MySpace.com presentations aside ( see Mix07 presentation ) , where is the MS community love for those that want to build at infinite scale? Why leave the questions so open and those that want to push the boundaries so exposed/uncertain? R ye guys listening? ;) </Thought of the day> For more information, go to http://www.paulfallon.com . Read More...
|
-
Mea Culpa and a big sorry, but I had to have a go!! My good friend PeterV is going tabloid with the titles for his posts , so I just have to have a go at him? Peter?? ;) /Paul For more information, go to http://www.paulfallon.com . Read More...
|
-
WCF is surely a big step forward for having a unified communication runtime, API and hosting model. And with all these super-exciting specifications and standards supported WCF must be a killer when it comes to interoperability with other platforms, technologies, stacks. And now the communication gurus from Redmond even announced that they will support everything to imagine (OK, except CORBA, ICE and Remoting wire interop ;)) under the big communication umbrella - including popular rockstars like REST -style architectures, RSS - and Atom -driven feeds and JSON for the AJAXians. Oh, and of course they still love SOAP . You know: love is the message and the message is love. So life is good, right? Well, yeah... in theory. Back to real life. I was approached by customers recently. Each of them had to interop with some issues when trying to point there 'other' technologies to a WCF service. And yes, this service was a plain old 'Web Service' - i.e. basicHttpBinding , no security ;), using the default DataContractSerializer with no fancy versioning or even extensibility stuff. Well, something pretty straight-forward at the end of the day. But these other technologies - namely Flex and PHP - could just not get their code generated (statically or dynamically) from the metadata exposed by the basic and simple WCF service. Hm... it is actually neither's fault, maybe we could blame Microsoft that they are ahead of the rest of the world - maybe we could blame the others that they have no time to invest in improving supporting WSDL and XSD on their platforms. But in the end, nobody is to blame, nobody has to complain: we simply need a solution. Period. It turned out that both technologies struggled with the way WCF is exposing the WSDL and XSD metadata by default. IMHO, WCF does a good job in factoring the XSD and WSDLs into multiple parts and not pumping everything into one big WSDL document. But the others just do not like it. Take a look at the following WSDL from our popular RestaurantService sample , just ported over to WCF (parts removed for clarity): - < wsdl:definitions name =" RestaurantService " targetNamespace =" http://www.thinktecture.com/services/restaurant/2006/12 " ... > - < wsdl:types > - < xsd:schema targetNamespace =" http://www.thinktecture.com/services/restaurant/2006/12/Imports "> < xsd:import schemaLocation =" http://localhost:7777/WSCF?xsd=xsd0 " namespace =" http://www.thinktecture.com/services/restaurant/2006/12 " /> < Read More...
|
-
My recent posts are my attempt to describe how I think about the Web and how it can be leveraged to integrate systems independent of the browser. I got a ton of feedback in comments and email, which was all great. I’ve been away for a bit, so I thought it would be good to come back and summarize, and to ask a question about what to call the model I’ve adopted. Specifically, some worry that the term REST means too many things to too many people to have any real meaning at all. But before I get to that, let me summarize and respond to some of the key points people made. Most of the feedback I got can be divided into a couple of bins... First, that it’s just RPC. That’s wrong for all the reasons I listed in my last 4 posts. Second, it’s not RPC, so it isn’t appropriate beyond browsing a hypertext graph of multimedia content. The first half is right. I strongly believe the second half is wrong, but we don’t have enough experience applying the model in other systems to say concretely. We need to get that experience. Third, and most interesting, what you describe isn’t REST, for a range of reasons. Some of this was because I wasn’t crisp in defining the difference between managing system state, session state, and transitions between nodes in a protocol state machine. Clients make HTTP requests to move through a protocol state machine. This is completely unrelated to changing system state or to maintaining session state. Specifically, a GET is a move between nodes (or states) in the protocol, but does not (or should not) affect system state. I adopted the term “node” here to describe moving between states in the protocol state machine. Is that clearer? Some felt I didn’t conform to REST because I didn’t include the notion of changes over time. Specifically, I said that each state in a protocol state machine has a URI, which I think is true. Each time the client enters this state, they get a representation of it. That representation may change over time. That doesn’t mean that each state in the protocol doesn’t have a unique URI, it means that each representation does not (unless you mix perma-links into the protocol). The most important feedback worried about the fact that the Web isn’t really RESTian or that my model doesn’t align very well with the HTTP spec, which focuses on CRUD operations on entities. Let me address those concerns. The Web does not fully conform Read More...
|
-
In my last post , I complained about the Token class not exposing the public key claim directly. Here's some code that will help you if you simply want to track the public key for a personal card in a user profile. Add this to the Token class and party on. Here's the code: // If this code works, Keith wrote it! string issuerPublicKeyHash; public string IssuerPublicKeyHash { get { if (null == issuerPublicKeyHash) { issuerPublicKeyHash = computeIssuerPublicKeyHash(); } return issuerPublicKeyHash; } } string computeIssuerPublicKeyHash() { RSA issuerPublicKey = null; foreach (ClaimSet cs in m_authorizationContext.ClaimSets) { // find the ClaimSet whose issuer is identified by an Rsa key. foreach (Claim rsaClaim in cs.Issuer.FindClaims(ClaimTypes.Rsa, Rights.Identity)) { issuerPublicKey = (RSA)rsaClaim.Resource; break; } if (null == issuerPublicKey) break; } if (null == issuerPublicKey) throw new Exception("Couldn't find issuer's RSA claim"); // hash exponent and modulus, and return base64 encoded string RSAParameters keyParams = issuerPublicKey.ExportParameters(false); SHA256Managed hashAlg = new SHA256Managed(); hashAlg.TransformBlock(keyParams.Exponent, 0, keyParams.Exponent.Length, null, 0); byte[] hash = hashAlg.TransformFinalBlock(keyParams.Modulus, 0, keyParams.Modulus.Length); return Convert.ToBase64String(hash); } Read More...
|
-
Dominick discusses the problem of determining how to uniquely identify users who present information cards to your application. If you keep a profile for those users, you need a way of linking the incoming claims to the user's profile. When I was first learning about CardSpace and the metasystem, it seemed as though PPIDs were a good answer. But once I learned that PPIDs weren't necessarily stable, I became wary of recommending their use. One fact remains true no matter how you define the primary key for users. You need to pay attention to the public key claim when you are accepting personal cards. If you haven't heard about this before, read why here . So my suggestion is this: just store the public key in your user profile. I disagree with the approach the Token sample class takes - they don't expose the public key directly; instead they have you pick a claim URI that represents your primary key (I guess you're screwed if you wanted a multi-part primary key). Then they hash the value of that “identity“ claim with the public key. Why don't they just expose the public key directly, like WCF with it's System.IdentityModel does? That would allow ME to decide how I'm going to pay attention to it. I'd personally rather just store the public key (or more likely a SHA-256 hash of it) in the user profile. To me, this is clearer than mixing it up with some other claim. Too bad the Token class refuses to give it up directly, and instead insists on hashing it with some other claim. Read More...
|
|
|
|