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.

Apache Axis2/C version 0.93 is released. This should please the REST camp and highlights the momentum of how REST can be implemented in Web Services. If you are in KL next week, I will be briefly touching base on the REST-vs-SOAP style of implementing Web Services.

Key Features

1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 Messages.
   This has complete XML infoset support.
2. Support for one-way messaging (In-Only) and request response
   messaging (In-Out)
3. Description hierarchy (configuration, service groups, services,
   operations and messages)
4. Directory based deployment model
5. Archive based deployment model
6. Context hierarchy (corresponding contexts to map to each level of
   description hierarchy)
7. Raw XML message receiver
8. Module architecture, mechanism to extend the SOAP processing model
9. Module version support
10. Transports supports: HTTP\
    1. Both simple axis server and Apache2 httpd module for server side
    2. Client transport with ability to enable SSL support
11. Service client and operation client APIs
12. REST support (HTTP POST case)
13. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
14. MTOM/XOP support
15. Code generation tool for stub and skeleton generation for a given
    WSDL (based on Java tool)
    1. Axis Data Binding (ADB) support
16. Security module with UsernameToken support
17. REST support (HTTP GET case) - New
18. Dynamic invocation support (based on XML schema and WSDL
    implementations) - New

Major Changes Since Last Release

1. REST support for HTTP GET case
2. XML Schema implementation
3. Woden/C implementation that supports both WSDL 1.1 and WSDL 2.0
4. Dynamic client invocation (given a WSDL, consume services dynamically)
5. Numerous improvements to API and API documentation
6. Many bug fixes, especially, many paths of execution previously untouched were tested along with Sandesha2/C implementation

Download the above release here.

Blasphemy ...

It is finally published. After many, many, and I mean, many months of paying the process tax for this piece, it is finally LIVE !

I started this piece with the first ever March 2005 CTP of Windows Communication Foundation (WCF, previously - Indigo) and I went through so many port demos and edit document cycles its so unbelievably painful ...

But it is really good to see this in online form and shape.

I started with this idea even though MSFT Corp has explicity stated that it will not support any form of interoperability between WSE 2.0 and WCF, even though it is "theoretically possible to develop Web services using WSE 2.0 in such a way that they can interoperate with WSE 3.0 (and WCF) by using only a reduced set of specifications"

More importantly, the main reason for the motivation to write such a piece is written in the article itself and I quote:

[BEGIN QUOTE]

Depending on timing, budget, complexity and a whole host of other requirements, some of these applications will need to be moved and migrated to WSE3.0 and some to WCF. Aaron Skonnard has provided a great resource in his “Service Station” column on MSDN on a brief overview on the migration of WSE 2.0 applications to WSE 3.0 ones. However, as stated in his article, there are some major changes in the programming model and architecture in WSE 3.0 and migrating them from WSE 2.0 may not be trivial.

Another very important factor to take note is while WinFX, and therefore WCF, is available downstream from Windows Vista to Windows 2003 and Windows XP. That is as far down as it goes. There still exists a huge installed base of Windows 2000 Servers out there running on server and data farms and if you need to implement the advanced Web Services stacks on those servers, WSE is still a very important strategy you cannot ignore.

As noted in the above guidelines, even though Microsoft will not guarantee interoperability between WSE 2.0 and WCF, the good news is that there are a few WSE 2.0 common scenarios, which can allow wire-interoperability with WCF. I will illustrate them in the next section...

So, this article will outlined WHAT that reduced set of specifications are and HOW to go about using them.

Many Special Thanks go to Kirill, the Interop PM on WCF, who gave me a couple of tips to get over the port-over humps I had thoughout this piece since last year. And of course, I cannot forget Clemens, who is the catalyst to making this publication happen when he came onboard.

I hope this helps at least someone out there. Enjoy !

During my webcast on "Why we need Reliablility in SOAP: Web Services", there were a couple of hiccups which hindered a better listening experience.

1. I cannot see the animation on the slides I am presenting, even though I am assured by the producer that the floor is seeing it. Therefore, I am "guessing" what the audience is actually seeing in my click-animation and gauging my content from there. It was neither easy nor pleasant.
2. There was a disconnect incident in my demos that also marred the listener's experience. I had to re-login again. Not Good.

Isnt it ironic? My network connection showed lack of reliability when I am talking about Reliability as a topic. . Now the least I can do is to answer a couple of questions that popped up after the session:

Q: Is RM available for all the bindings in Windows Communication Foundation (WCF, previously - Indigo) ? 
A: Yes, it is available for MOST of the standard bindings in WCF. In some bindings such as the netTcpBinding I showed, it is On-by-Default. In bindings such as wsDualHttpBinding where you need correlation of different channels and such, it is Always-On. It doesnt make sense to stick <reliableSession /> in a netMsmqBinding, for example.

Q: Is this the same WS-RM spec that is authored by IBM, Microsoft and TIBCO ? 
A: Yes. In my slide, I mentioned - I.B.M and TIBCO. I.B.M is actually the acronym I used for IBM, BEA and Microsoft.

Q: Can I get the demo you showed? 
A: No, I am sorry. In any case, my demos will not work with the lastest WinFX B2 bits today. I will need time to port them over. I recommend you go bug Shy when you see him and ask him for his WS-RM demo which consists of a WPF stack in there and a "awesomely" cool Rubik's Cube demo and is 100x better than mine.

All in all, it is quite a different experience than doing an on-stage presentation, especially when you spent an hour talking to yourself and you cannot see the audience faces and cannot manipulate your content and presentation based on their moods.

But then again, no one can see that I am wearing my Mickey-Mouse boxers while I am presenting, so I guess that is a good trade-off.

Here I am - proud to announce that I will be doing a MSDN Redmond-hosted Webcast right from the other side of the hemisphere in Singapore.

I will be speaking on concepts of Reliability in Soap:Web Services, why its needed, as well as the context of it in Windows Communication Foundation (WCF, previously - Indigo).

More importantly, a 40GB Creative (another homegrown Singaporean product) ZEN MP3 player is at stake here waiting to be won. So, do sign up quickly for a chance to win this. Rules here.

If you are one of those insomniacs in Asia-Pacific, do try to tune-in. I hope this blazes a trail for the other community leaders in Asia-Pacific to follow suit and show that we are right on par there with the best in technology.

Click here for more details on this webcast.

Apache Axis2/C version 0.91 has been released via here:
http://ws.apache.org/axis2/c/download.cgi

Key Features

1. AXIOM, an XML object model optimized for SOAP 1.1/1.2 messages with complete XML Infoset support
2. Support for One-Way Messaging (In-Only) and Request Response Messaging (In-Out)
3. Module architecture, mechanism to extend the SOAP processing model
4. Context hierarchy
5. Directory based deployment model
6. Raw XML providers
7. WS-Addressing, both the submission (2004/08) and final (2005/08) versions
8. Transports: HTTP * Both simple axis server and Apache2 httpd module and * SSL client transport - New
9. Service Groups - New
10. Service client and operation client APIs - New
11. REST support (POST case) - New
12. Module version support - New
13. MTOM support - New

Other notes

1. Interoperability tested with Axis2/Java for XML in/out client and services
2. Addressing 1.0 interoperability

Major changes since last release

1. Full Addressing 1.0 support
2. Improved fault handling model
3. SSL client transport
4. MTOM implementation
5. Implementation of easy to use service client and operation client APIs for client side programming
6. REST support (POST case)
7. Module version support
8. Service groups
9. Numerous bug fixes since last release

Un-Implemented Architecture Features (TBD in 1.0)

1. Sessions scoping for application, SOAP, transport and request levels
2. Different character encoding support
3. Dynamic invocation
4. Archive based deployment Model

Un-Implemented Architecture Features (TBD post 1.0)

1. WSDL code generation tool for stub and skeletons (based on Java tool)
2. Security module
3. REST (REpresentational State Transfer) support (GET case)
4. Web Services policy support
5. Axis2 Web application (Web App)

Fellow