Tuesday, May 01, 2007 - Posts

• OASIS and the WS-Federation Specifications

  Finally, OASIS announced last week that it is calling for participation for Web Services Federation . The formation of the WS-Federation Technical Committee is announced here . WS-Fed is an important addition to the WS-* protocol suite that enables users to sign-in seamlessly to systems outside of their own organization without requiring (more) new usernames and passwords using Single-Sign-On (SSO) between separate organizations with an established trust relationship. WS-Fed builds upon and composes with other WS-* protocols: WS-Fed extends WS-Trust WS-Fed composes with WS-Security and WS-SecureConversation to ensure data integrity and privacy WS-Fed composes with WS-MetadataExchange and WS-Policy to enable simple provisioning and trust relationship configuration Does WS-Fed compete with Liberty SAML? Both SAML and WS-Fed enable browser-based identity federation ( Passive-Mode ) However, WS-Fed enables a superset of scenarios, including: Seamless federation with Web Services and/or Rick-Client applications Separation of identities, token types, protocols and encodings Multi-purpose Security Token Service (STS) that can return tokens stating different assertions based upon the scenario WS-Fed adds identity federation capabilities to the existing WS-* suite of protocols resulting in: A single protocol stack that supports the majority of your needs and scenarios Simplified development, deployment, management and control The formation of the Technical Committee to drive the standardization of the WS-Fed is an important step in evolution of the industry-wide effort to create a single, comprehensive communication protocol suite that enables many current and new scenarios most effectively. (c) William Tay 2000-2006 | Solution Architect Consultant http://www.softwaremaker.net/blog Read More... Posted Tuesday, May 01, 2007 11:39 PM from Softwaremaker | 0 Comments Filed under: Interoperability;WS-Splat Specs;XML Services

• Silverlight and CSLA

  This week Microsoft fully disclosed their plans for Silverlight . It is not only a way to build rich internet applications (RIAs), but it is a way to build them with .NET! This is very exciting news, and I hope that Microsoft follows through on their vision for Silverlight!! With the support of Magenic , I've been researching the possibility of creating a CSLA Light which would run in an Internet zone sandbox, and in the even more restrictive Silverlight environment. The Silverlight 1.1 alpha available today doesn't have enough functionality to even come close to hosting something like CSLA, but Microsoft's plan for Silverlight should provide enough functionality to create a stripped down, client only version of CSLA. That means no data portal, no Clone() method, and the requirement to implement GetState() and SetState() methods to support n-level undo (thanks to no private reflection). But it does mean that I should be able to provide the full validation, authorization, data binding and n-level undo capabilities of CSLA .NET in the CSLA Light version. I also plan to provide the data portal interface so factory methods can remain consistent, but the back-end implementation will be quite different. (I can't do mobile objects due to no serialization, and I can't do the strongly-typed DP_XYZ calls due to no private reflection). The lack of a real data portal is pretty hard to take, but I haven't figured out a way to do it, so it is probably unavoidable... I anticipate that around 80% of the code you'd write in a business object today will be the same in CSLA Light, perhaps even more. Thanks to the compatibility between Silverlight and WPF/.NET itself, there are some other interesting possiblities for CSLA Light. Code written for Silverlight should always run in a less restrictive environment like WPF on Windows, or even XBAP/WPF in a browser. Due to this, CSLA Light will almost certainly work in those settings as well. In any case, this will be a somewhat slow moving initiative, because I have to wait until Microsoft comes out with a release of Silverlight that supports key WPF features like data binding before I can get too far with the project... For more information go to www.lhotka.net . Read More... Posted Tuesday, May 01, 2007 6:25 PM from Rockford Lhotka | 0 Comments Filed under: CSLA .NET

• How Silverlight supports dynamic languages

  I am not at this conference , but anyway... What I was wondering is how Silverlight does support these super-cool dynamic languages 'on-the-fly'. After some fiddling, this is what I think how it works: 'Non-real' CLR languages like IronPython or IronRuby have a parser which converts the source code to a language-specific abstract syntax tree (AST). The language specific AST is transformed to a language-independent dynamic language runtime ( DLR ) AST. DLR's code generation converts the DLR AST to IL code using Reflection.Emit (and Light-Weight Code Generation [ LCG ]). A delegate is created pointing to the new DynamicMethod . The delegate is finally invoked. Can anybody confirm this? Read More... Posted Tuesday, May 01, 2007 4:12 PM from Christian Weyer: Smells like service spirit | 0 Comments

• Multi-threading and WCF's OperationContext

  In WCF, the powerful OperationContext.Current static property lives in thread-local storage. It gets pinned to the current thread before WCF dispatches to the user code. If code for a service operation - for whatever reasons - is spawning new threads to do its work the current OperationContext object will have to be captured and needs to be passed to the other threads. Just to let you know. Read More... Posted Tuesday, May 01, 2007 3:13 PM from Christian Weyer: Smells like service spirit | 0 Comments