# Wednesday, 08 February 2006

I'm doing some WCF (Indigo) training this week, and one of the hands on labs went through an example of a federated trust scenario, with two STS's involved in the process.  I've got to say, I'm really impressed with how easy it was.  Granted, the configuration is pretty hairy, but it's just that, configuration.  You can set up a whole federated trust system using config files.  And it worked.  Not too shabby.  I would never have contemplated attempting something like that in WSE 2, although I think in WSE 3 it's supposed to be a bit easier. 

One thing to note, if you want to do federated trust, is that the WCF team is not shipping an STS.  Presumably for liability reasons, but that's anyone's guess.  They are, however, providing some very complete samples, which could be fairly quickly adapted for use inside one's organization.  There's also a good example STS for WSE 3 up on gotdotnet as of a few weeks ago. 

Overall, my impression is that security in WCF is very thought out, and WAY easier to bend to your will than ever before.  Check it out.

Wednesday, 08 February 2006 09:15:28 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, 23 January 2006

I’ve been playing with the January CTP of WCF, and I’ve encountered what seems like a pretty major setback.  I’ve got an interface that takes a MessageContract and returns a MessageContract.  All well and good.  But then I want to use the AsyncPattern on the service side, so that my routine will get called on a different thread from the one that’s listening on the network.  So I decorate the interface like so:

    [ServiceContract()]

    public interface IThingy

    {

        [OperationContract(AsyncPattern=true,Action="Signon",IsInitiating=true)]

        IAsyncResult BeginSignon(ThingyRequestMessage<SignOnRequest> request, AsyncCallback cb, object state);

 

        [OperationContract]

        ThingyResponseMessage<SignOnResponse> EndSignon(IAsyncResult ar);

    }

 

Now I get an exception at runtime, which says that I can’t mix parameters and messages for the method “EndSignon”.  What it means is that if I return a MessageContract instead of a primitive type, my method has to take a MessageContract and not one or more primitive types.  OK, I get that.  But my EndSignon method is getting flagged because it takes an IAsyncResult (as it must according to the AsyncPattern) and returns a ThingyResponseMessage. 

Does this mean I can’t use MessageContracts with the AsnycPattern?  If so, LAME.  If not, then what am I missing?

SOAP | Web Services | XML | Indigo
Monday, 23 January 2006 15:05:23 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [2]  | 
# Monday, 06 December 2004
I’ll be teaching again next term at OIT (at CAPITAL Center in Beaverton), this time “Enterprise Web Services”.  We’ll be looking at what it takes to build a real-world enterprise application using web services, including such topics as asynchronous messaging, security, reliable messaging and a host of others. We’ll walk through all the stages of building an enterprise-level WS application, using .NET and WSE 2.0 to do the heavy lifting.  Required is a firm grasp of programming in C#, and a basic understanding of Web Services fundamentals such as XML, SOAP, and WSDL.
Monday, 06 December 2004 13:18:30 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
Check out the ever-well-informed-and-entertaining Stuart Celarier this Thursday at CAPITAL center in Beaverton.  Should be a good talk.  If you ask nicely he might even juggle.  :-)
Monday, 06 December 2004 10:38:27 (Pacific Standard Time, UTC-08:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 26 October 2004

Steve Maine is in the midst of the perennial debate between SOAP and REST, and I feel compelled to add my two cents...

At the XML DevCon last week I noticed that it continues to be fashionable to bash the existing Web Services standards as being too complex and unwieldy (which in several notable cases is true, but it's what we have to work with at this point) but that doesn't change the fact that they solve real problems.  I've always had a sneaking suspicion that people heavily into REST as a concept favored it mostly out of laziness, since it is undeniably a much simpler model than the SOAP/WS-* stack.  On the other hand, it fails to solve a bunch of real problems that SOAP/WS-* does.  WS-Addressing is a good example. 

I spent two years developing an application that involved hardware devices attached to large power transformers and industrial battery systems that needed to communicate back to a central data collection system.  We used SOAP to solve that particular problem, since it was easy to get the data where it needed to go, and we could use WS-Security to provide a high level of data encryption to our customers.  (Utility companies like that.)  However, we had one customer who would only allow us to get data from the monitors on their transformers through a store-and-forward mechanism, whereby the monitors would dump their data to a server inside their firewall, and we could pick up the data via FTP.  This is a great place for WS-Addressing, since all the addressing information staid inside the SOAP document, and it didn't matter if we stored it out to disk for a bit.  There is no way that REST could have solved this particular problem.  Or, at least, no way without coming up with some truly bizarre architecture that would never be anything but gross.

REST is great for solving very simple application scenarios, but that doesn't make it a replacement for SOAP.  I agree that many of the WS-* standards are getting a bit out of hand, but I also agree with Don Box's assessment (in his "WS-Why?" talk last week) that given the constraints, WS-Addressing and WS-Security are the simplest solutions that solve the problem.  There's a reason why these are non-trivial specs.  They solve non-trivial problems.

So rather than focusing on REST vs. SOAP, it's more interesting and appropriate to look at the application scenarios and talk about which is the simplest solution that addresses all the requirements.  I don't think they need to be mutually exclusive.

Tuesday, 26 October 2004 10:01:27 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Thursday, 15 July 2004

I finished up my Web Services Theory class at OIT last night.  Just the final to go on Monday (mwah ha ha).

We ended with some stuff on WS-* and all the various specs.  I tried to spend minimal time on the actual syntax of WS-*, since some of them are pretty hairy, and spent more time on the business cases for WS-*.  That seemed to go over pretty well.  I think it's easier to understand the business case for why we need WS-Security than it is to understand the spec itself.  Unfortunately, on of the underlying assumptions about all the GXA/WS-* specs is that eventually they will just fade into the background, and you'll never see the actual XML, since some framework piece (like WSE 2.0) will just "take care of it" for you.  What that means is that the actual XML can be pretty complex.  The unfortunate part is that we don't have all those framework bits yet, so we have to deal with all the complexity ourselves.  Thankfully more tools like WSE 2 are available to hide some of that from the average developer.  On the other hand, I'm a great believer in taking the red pill and understanding what really goes on underneath our framework implemenations. 

Thursday, 15 July 2004 16:40:53 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 09 July 2004

Dare Obasanjo posits that the usefulness of the W3C might be at an end, and I couldn't agree more.  Yes, the W3C was largely behind the standards that "made" the Web, but they've become so bloated and slow that they can't get anything done.

There's no reason why XQuery, XInclude, and any number of other standards that people could be using today aren't finished other than the fact that all the bureaucrats on the committee all want their pet feature in the spec, and the W3C process is all about consensus.  What that ends up meaning is that no one is willing to implement any of these specs seriously until they are full recommendations.  6 years now, and still no XQuery.  It's sufficiently complex that nobody is going to try to implement anything other than toy/test implementations until the spec is a full recommendation.

By contrast, the formally GXA now WS-* specs have been coming along very quickly, and we're seeing real implementation because of it.  The best thing that ever happened to Web Services was the day that IBM and Microsoft agreed to "agree on standards, compete on implementations".  That's all it took.  As soon as you get not one but two 800 lb. gorillas writing specs together, the reality is that the industry will fall behind them.  As a result, we have real implementations of WS-Security, WS-Addressing, etc.  When we in the business world are still working on "Internet time", we can't wait around 6-7 years for a real spec just so every academic in the world gets his favorite thing in the spec.  That's how you get XML Schema, and all the irrelevant junk that's in that spec. 

The specs that have really taken off and gotten wide acceptance have largely been defacto, non-W3C blessed specs, like SAX, RSS, SOAP, etc.  It's time for us to move on and start getting more work done with real standards based on the real world.

SOAP | Web Services | Work | XML
Friday, 09 July 2004 10:35:44 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 25 September 2003

Clemens Vasters posted a great article on what’s really behind a Service Oriented Architecture from the implementation standpoint.  He makes some very astute points about why schemas are important for expressing service contracts, and what the implications of SOA are on implementing scalable solutions.  Having wrestled a bit with this myself, I agree with his conclusion that old-school OOD is not the way to approach this particular problem.  Also, with regards to the stateful vs. stateless issue, I really like his take:

Ruling out that state is implicitly shared between services (in memory or on disk) is a direct consequence from this and also serves the scalability purpose, because it further eliminates co-location assumptions about services and enables clustering. Note that this isn’t about “stateless” or “stateful”. Everything is stateful while it runs.

Thursday, 25 September 2003 13:25:27 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Wednesday, 27 August 2003

Werner Vogels posted a great article on what Web Services are and aren’t, and why they represent Service Oriented Architecture, and not a Distributed Object Architecture.  Don’t let the name SOAP fool you.

Wednesday, 27 August 2003 16:01:35 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 18 July 2003

It’s hard to tell how much of this is an unfinished documentation issue, but in the WSE 2 Tech Preview, there doesn’t seem to be any easy way to do encryption using symmetric keys.  The sample code in the documentation is that same as in WSE1, and it doesn’t compile any more, since the version of the EncryptedData constructor that takes an EncryptionKey is obsoleted.  Now you have to pass a SecurityToken, but there isn’t one for symmetric keys.  This seems like a pretty straightforward thing to want to do, so I don’t really want to write a custom binary token to do it.  There are some hints in the documentation that there is a plan for a symmetric key token (or maybe I just haven’t figured it out yet).   Right now this is a total pain, since I have a bunch of existing WSE1 code that uses symmetric keys.  If nothing better happens by the time WSE 2 is released, I may have to write a custom binary token anyway.  It’s nice that they’ve put in so much work to make Kerberos and X509 easy, but since my client is an embedded device, those aren’t really viable choices. 

 

Friday, 18 July 2003 14:03:25 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, 15 July 2003

I know this is a bit after the fact, but I’ve had time to reflect.  Steve gave a very interesting talk on the feasibility of using SOAP/Web Services with embedded devices, which in his case was a printer.  I’m currently also working on an embedded Web Services project, so I was really interested in what Steve had to say.  His conclusion was that although there are some issues to be overcome, it is in fact feasible to use Web Services with an embedded device.  In the work I’ve done so far, I’d have to agree. 

The really interesting part for me what that the challenges Steve talked about with his printer were completely different ones from the challenges I’m facing talking to transformer monitors.   It sounded like the biggest hassle with using WS on the printer was dealing with large binary files as attachments (since it was actually a 3D printer, and 3D models can be very large).  There are several different ways of dealing with attachments to SOAP, and they all have their challenges. 

Our biggest challenge, on the other hand, is that since our monitors are meant to work over the WAN, we can’t assume connectivity to them all the time, which you probably can in a printer.  Also, it sounded like using Java on the printer wasn’t too big a problem, while we are working with straight C++ in a very constrained environment, for which there are many fewer tools available.

The short answer then to “is it feasible” is of course, “it depends”.  It worked for Steve.  So far it’s working for me.  I’ll keep my fingers crossed.

Tuesday, 15 July 2003 16:21:04 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
# Monday, 14 July 2003
A few hearty souls stuck it out until the bitter end to hear me ramble about XML on Large Power Transformers and Industrial Batteries. I got some good questions, and a couple of cool bits of feedback. I spent some time talking about the fact that one of the reasons we decided to go with XML Web Services in the embedded space was to take advantage of infrastructure implementations arising from GXA. For example, I don't have to wonder about how to deal with security of Web Services, because there's WS-Security, and better still in the future I'll be able to get a WS-Security appliance in the same way that I can get an SSL appliance today. Rich Salz, who gave the talk right before mine (Determining what Security your Web Services need) mentioned that his company makes such a thing today. Hooray! Very cool. With any luck, in the future I'll be able to get WS-Routing appliances also.
The other thing I talked about was the fact that our model is a little different from the usual Web Services models (Server to Server, or Smart Client) since we have to deal with the fact that our monitors aren't reachable (they have to call us) and that they can't maintain state about what data they've sent us. Given that fact that our monitors are meant to give utilities the information they need to keep their transformers from blowing up, Tim Ewald suggested that we call it the Exploding Client model. :)
Maybe it'll stick...
Monday, 14 July 2003 13:04:00 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [1]  | 
Aaron demonstrated some very cool techniques using XPath assertions to validate XML documents (specifically the contents of SOAP messages). He uses SOAP extensions and attributes that indicate which XPath assertions to apply to a given WebMethod. It apparently is much faster than doing full schema validation, and easier to set up, since most of the time you really only want to assert a few key requirements and don't need to validate the whole data structure exhaustively. I hadn't heard or Schematron before, but apparently is uses a similar technique using XPath assertions. There is a .NET implementation of Schematron here.
Monday, 14 July 2003 12:59:17 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, 11 July 2003
The sweet spot accoring to Tim:
Write schemas with global element declarations using anonymous types. To process them, wrap them in something that carries a DOM, exposes the Navigator interface, and give you type safe methods for modifying the documents.
This turns out to be very similar to some stuff I've been thinking about for processing/pipelining XML documents. More on this later...
Friday, 11 July 2003 17:48:39 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
I wanted to follow up on the last question that was asked at the speakers panel this evening. To my interpretation, the question was basically "I'm trying to sell some end users on the idea of using XML, should they care that it's XML?" That may not have been the actually question, but I think that's what I heard.
Unfortunately, that's a pretty interesting question, and the answer got totally lost in XML-RPC vs. SOAP / how badly does WSDL suck bickering and I don't think we really answered the guy's question.
My answer (speaking only for myself here) is that absolutely they SHOULDN'T care that it's XML. We as developers care because we have to write implemenations. End users shouldn't care in the slightest if it's XML. If I give my CFO a some data in CSV format, I'm pretty sure he doesn't care that the format is CSV, or that it has delimiters, or any other thing about it. What he cares about is that when he double clicks on the file, it comes up in Excel looking like a spreadsheet.
The problem is twofold: 1) we're not there yet with XML. You can't just double click on an XML file and have it come up in Excel looking like a spreadsheet (unless you're running Office 2003 Beta, which does actually manage to do just that through an amazingly clever combination of shell extensions and processing instructions, but that's an exception) 2) XML received so much hype 2-3 years ago that everyone thought (including end users) that they should care, since it's such a great buzzword.
Those are the things that we as developers have to fix, so that end users will be as blissfully ignorant of XML as the should be (are?) of CSV.
Friday, 11 July 2003 02:15:14 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
I have to hand it to Keith: it's pretty impressive to see a guy interactively build a tool during the course of his talk that lets the audience heckle him interactively while he's giving the rest of the presentation.
For those of you who weren't there, Keith used WSE 2 to set up a non-IIS based SOAP server that accepted HeckleData structures and printed them out, then build an ASPX page with a form on it that used the WSE2 SoapClient to send HeckleData messages to the server. Not only that, but he gave out the URL to the form on his first slide, thereby exposing himself to heckling from the wirelessly connected audience.
All that while wearing someone else's belt, and weathering some pretty intense non-SOAP issued heckling.
I saw Keith's presentations on WSE 2 at TechEd also, and I can't wait to get my hands on it.
Friday, 11 July 2003 02:05:02 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
As Scott Hanselman mentions I've had some experience with SVG UI's in my current project at Serveron.
While I think SVG is a really cool idea, and amazingly useful for interactive graphics (if done succinctly) we had nothing but trouble trying to craft SVG UI components, which was largely the focus of Don's talk. There were just too many problems with different scripting/DOM models (you can access Adobe's SVG DOM from IE, but you can't get to IE from Adobe, etc.) to make it a long term workable solution. In retrospect I would have suggested (not having written the SVG personally) moving all the UI controls into ASPX and keeping the SVG strictly for graphics display.
While I thought Don's approach to some of the individual controls was cool (I really liked the analog gages), I don't think that SVG, or mor importantly the infrastructure build around SVG at present, is in good enough shape to be building UI's on it.
Scott's correct in that we've essentially scrapped the SVG UI for a WinForms based "Smart Client". We orignally banked on SVG to give us cross platform interactive graphics, but as always, it's not that simple. Adobe's SVG control, which seems to be pretty much the only game in town, doesn't work in Netscape 6, which pretty much kills the whole cross-platform thing, even if we could get the scripting to work.
Friday, 11 July 2003 01:58:03 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, 10 July 2003
Brian Jepson did some very cool demos using Perl to convert RSS into WML so he can read blogs while standing in line at the DMV (although not while driving, he was quick to point out). He also used the same technique to wrap Amazon's Web Services so that he can check on how his books are selling on Amazon. Pretty groovy stuff. He also (bless his heart) rewrote the same applications in C# (using Rotor on OS X) so that people can actually read them. :)
You can check out his sources here.
Better still, he demoed RSS.NET, which is a C#/.NET library for reading and writing RSS. Now I can go and fix up my Draco.NET RSS feed, since I unknowingly coded all the RSS by hand.
Thursday, 10 July 2003 17:15:40 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [0]  | 
OK, I'm convinced. I need no further information on the ongoing debate about RSS.
Dave Winer just put forth a really great analogy on why RSS is the way to go. RSS is like a table (a physical one) in that we don't care how tables are made, we don't need a table standard, all we care about is that it holds up our coffee cup. So there it is in a nutshell: RSS holds up our coffee cups.
I must admit I have been from time to time in the strongly-typed, let's have a schema for everything camp but this and other arguments (such as loosely coupled SOAP services) are slowing winning me over to the idea that simple is better and there are good as useful reasons for not trying to specify the hell out of everything.
This makes me want to go back over some of my recent SOAP/Schema work and re-examine it in the light of this new maxim: Does it hold up my coffee cup?
Thursday, 10 July 2003 14:10:50 (Pacific Daylight Time, UTC-07:00)  #    Disclaimer  |  Comments [3]  |