Using ExtJS you can create a screen programmatic-ally using classes and method calls but one of the neat features is that a screen can be entirely described declaratively in JSON notation. Declarative UI is nice, but a meta-data driven UI is nicer. I’ve created such systems in the past but always had to spend so much time maintaining the thing that interpreted the metadata (Sapient Powerbuilder Framework anyone???).

With ExtJS this could be avoided by just serializing the JSON into a database and back again. Eureka! I had a pretty nice metadata driven declarative UI with MINIMAL investment in “framework” code. Minimal investment in this type of “framework wrapper stuff” corresponds to a good upgrade path, quick time to market and very low likelihood that my “metadata wrapper” would break anything in the underlying ExtJS library.

Intrigued and not wanting to practice “architecture space exploration” [LINK] I wrote a proof of concept and built some screens out of metadata.

There was just one snag; ExtJS could paint the screen but in order to wire it to data it needed a bit of Javascript code to be written. With a complex screen this JS might grow to as much as 200-300 lines. Debugging JS with Firebug, Dynatrace etc. doesn’t scare me but it doesn’t sound good to an architecture review board either.

No good deed goes unpunished. It was mentioned that GWT could be used to write the same thing except instead of Javascript, developers could wire up their screens with Java code. The promise of Eclipse, PMD, FindBug and all that java-y goodness was just too much to argue against so I’ve spent the last few weeks in GWT hell and finally come full circle.

<rant>Just a second, hey, why did I do this? Well I like to know what I’m talking about. If I’m going to be responsible for something I want to know it’s going to work BEFORE we start. I don’t want to be an architecture astronaut who just reads the brochure. Everyone can read the brochure. I wouldn’t follow someone like that and I don’t expect my team to. </rant>

GWT (Google Web Toolkit) is essentially a compiler that takes your Java code and instead of byte code produces JavaScript. It does a nice job, traversing code paths so that only the bare minimum Javascript is sent down to the browser. It looks like a dogs dinner though.

Enter Ext GWT, Smart GWT (formerly GWT Ext) and MyGWT. Seems everyone has a GWT library, never a good sign imho.

GWT needs to know every execution path at compile time and hence it doesn’t support reflection. First problem was how to paint the screens from metadata. This can be achieved with GWT.create() but wiring the widgets to Java code with string literals is not possible.

In my use case, the developer should configure the metadata, the framework should paint the screen, the developer should write some Java code for screen logic, then wire the two together. There’ll be 300+ developers worldwide of varying experience levels so it’s gotta be simple to use.

I looked at Deferred Binding; “Deferred Binding is Google Web Toolkit’s answer to Java reflection.” BINGO!!! that’s got to be exactly what I’m looking for, it even says “reflection” on the box.

From http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html

One way to think of this is as “dynamic class-loading that occurs at compile time instead of execution time.” When the GWT Compiler compiles your Java application, it determines all the different “idiosyncrasies” that it must support, and generates a separate, tightly streamlined version of the application for that specific configuration. For example, it generates a different version of the application file for Firefox than it does for Opera.

reading on…

It’s probably pretty clear by now that Deferred Binding works a little differently than standard dynamic binding. Conceptually, though, the two concepts are fairly similar, and in practice all you usually need to do is just substitute a GWT method for a Java Reflection method. Instead of Class.forName(“MyClass”) you use GWT.create(MyClass).

So although Deferred Binding is the GWT’s answer to reflection, you cannot invoke a method using a string literal, you cannot create a class unless it’s known at compile time and you cannot hook up to an event without compile-time knowledge of the handler.

This makes metadata a pretty tough proposition. To add to the frustration, examples for Deferred Binding were so thin on the ground that it took me 2 evenings to get something working. I’ll post an example in the coming days to “pay it forward”.

Not to be outdone I looked at Generators. Again, no examples to be found anywhere, I’ll post one in a day or two. Generators basically let you generate java code at compile time, this code you never see but is then turned into Javascript. Honestly the GWT compiler must make 10 passes.

Generators could work. Using Generators would possibly allow the creation of a metadata UI framework however, it would take an enormous amount of fairly skilled coding to make this happen. They’d also be very brittle and tough to build; e.g. you have to write out java code using the GWT equivalent of a printf. You’ve no way of knowing if the code will run or not until it’s too late. Certainly very little chance of testing it. Rocket [LINK] claims to fix this problem but frankly this project is far too immature to be of any use.

Gwittir [LINK] is another option that claims to support Reflection. That’s dependent on GWTx and Google Gears. One of my pet-peeves about the open source world is all the dependencies. Don’t make me download 10 other things/frameworks just to draw HelloWorld. GGears is not an option for me so Gwittir is out.

Lastly, all these frameworks claim to optimize the Javascript, and they are true to that claim, HOWEVER, the third party libraries like SmartGWT, ExtGWT, etc. don’t optimize the widget Javascript. If you’re using SmartGWT’s grid, guess what, you’re downloading 500KB of widget JS.

So I’ve come full circle. For me, ExtJS seems like a good fit, easy to use, easy to drive off metadata and sure I have to write some Javascript but I’ll take a few lines of Javascript/Firebug over the mess that is Deferred Binding and Printf-style Code Generation anyday. Don’t knock it OR recommend it until you’ve tried it and fly safe.

"A logical fallacy is a false or incorrect logical principle. An argument that is based upon a logical fallacy is therefore not valid."

1) Argument from authority: Stating that a claim is true because a person or group of perceived authority says it is true. E.g. "this thing scales, the vendor said so".

2) Looks Good on Paper: A particular design looks elegant and can be easily explained on paper. However is non-performant and entirely unmaintainable in real-life. Example of this is the "enterprise service bus".

3) Design from Best of Breed: Identify the functional areas covered by your architecture, then pick best of breed in each area. You end up with a master of all trades, Jack of none. Your system needs to hang together, you can’t take each area in isolation.  These days with software acquisitions you can’t even be guaranteed that choices from a single vendor will hang together as they might have been developed by different smaller companies.

More on this later…

Here is a blurb about the panel:

Beyond Web 2.0…What Enterprise 2.0 Is…And What It Means For Wall Street

Beyond Web 2.0, Enterprise 2.0 is about deploying these new technologies and social practices in a corporate business context.

This session will explore the drivers pushing Enterprise 2.0 adoption, survey relevant technologies, and discuss how Wall Street and the financial markets are benefiting.

Tom Steinthal, Managing Director, Financial Services, BSG Alliance (Moderator)
Marc Adler, Senior Vice President, Equities and Head of Complex Event Processing, Citigroup
Michael Ogrinz, Principal Architect for Global Markets, Bank of America
Jonathan Rochelle, Senior Product Manager, Google

Should be an interesting discussion.

1. Self-Issued Cards in which essentially you act as your own security token service and
2. Managed cards – in which a trusted third party acts as Identity Provider making assertions around your identity.

I have seen many examples leveraging self-issued cards but relatively few incorporating managed cards. There is a sample STS available on the http://cardspace.netfx3.com website but due to the complex nature of it I’ve found it challenging to set up and leverage. If you look at the message boards they are full of issues and questions involving managed cards.

To mitigate this I’ve put together a managed STS and will be hosting it here from my own website in the coming days. It’ll allow you to setup a relying party, setup claims and test values for same and even download a managed card.

I’ll also provide a generic test harness that’ll simulate your relying party and allow you to test the end to end interactions. Last thing it’ll do is provide you with the RST and RSTR structures passed around in XML as we go.

I hope this’ll be a useful service and a useful learning tool and there’ll be more to come on that in a few days. (as a side note I’m surprised Serrack or Microsoft hasn’t set this up themselves by now).

But of course there is a selfish agenda to all my work and the main reason I did this is because I wanted to understand the inner workings of a security token service. This (painful) process has shown me…

1. how it processes the Request for a Security Token
2. how it generates the Request for a Security Token Response
3. how the Cardspace Identity Selector will process that and lastly
4. how to consume the token on the Relying Party side.

When an RP indicates it needs a claim, let’s say
http://schemas.francisshanahan.com/sts/superclaim

Cardspace includes that as a required (or optional) claim in an RST. The Security Token Service reads this, (presumably) locates the value for this claim and then includes that value in an RSTR.

One thing I was surprised to learn is that Cardspace Identity Selector doesn’t actually display this value! The ID selector actually displays a value from what’s called a "Display token". Here’s where things begin to break down (for me)…

The values in the Display Token are actually what get displayed to the user.

So tying back to the Laws of Identity: The user should have knowledge and control over what gets sent to any Relying Party.

This Displaytoken seems to violate this as follows…

1. There is nothing that prevents the STS from including claims in the RSTR that were not requested in the RST.  Thus an STS could
   • ignore the "isOptional" attribute of each claim and include that information regardless.
   • Or worse still, an STS could include claim values that WERE NEVER requested. I’ve tried this with my own STS and Cardspace happily forwards these on to the RP for decryption.
2. There is nothing that prevents the STS from including Values in the Display Token that are DIFFERENT from the values in the actual claims token. So for example, it may be shown to the user that they are passing an email address of "foo@bar.com" but in reality the value being sent to the RP is actually "mypersonal@emailAddress.com". The user wouldn’t know at best until the RP processed the RSTR token.
3. Whilst the Security token is encrypted and bundled up nicely to protect its information, the DisplayToken is sent in clear (to allow the Cardspace selector to display it). Now what’s the point of protecting your claims in a security token if you go ahead and put those same claims in a Display token? How can we have user control and consent (Law #1) without violating the security of the data itself?

So it seems once again I have confounded myself with Identity by delving into the details. Perhaps it would be better to just go along with the whiteboard conversations and ws-trust what I’m being ws-told rather than ws-implement it?

It would appear based on my rudimentary investigations that there’s a potential for the first Law to be broken either through
a) Unwittingly implementing an STS that pumps in claims into an RSTR without looking at the RST.
b) A malicious STS mis-representing claims to a end user and secretly passing different information to an RP.

This for me was the kind of "Ahaah" moment that would typically not be uncovered until knee deep in an implementation and could potentially derail a project. I’m not saying this is the fault of  Cardspace, or even the Identity Meta-System. Rather I think this is a problem that’s just inherent with Law #1. As with anything I tend to find there is a lot of buzz around the high-level solution but sometimes when you dive a level deeper, you come to find out there may actually be a problem [LINK].

That’s why it’s always better to be an "I-know-it-works-because-I-tried-it,-look-my-hands-are-dirty" architect than an "I-don’t-know-what-the-problem-could-be,-it-compiled-on-the-whiteboard" architect.

I will talk to Kim[LINK] about this…

A while ago someone made the claim that there was only one way to implement a pattern. This struck me as a remarkable statement as the very word "pattern" implies no specific implementation. A pattern is an abstract notion that has potentially many implementations, that’s what makes it so useful. Most people start with the GoF Blue Book on patterns but you may prefer the "Non Software Examples of Patterns" [LINK].

Talk to any java person for more than 5 minutes and they’ll throw up the MVC all over you. This is a nice pattern but many folks don’t understand it. For example just this morning I heard an "architect" refer to the MVC as Model, View, Controls. They described implementing the View using CSS and the "Controls" using tag libraries. Ho-hum.  Even more common is that folks don’t realize there are two MVC patterns, model 1 and 2.

A lot of Patterns turn into Anti-Patterns because folks blindly follow the pattern without understanding the pattern. For example someone recently told me you shouldn’t implement the Abstract Factory using reflection. Riiiigghhht.

So maybe a new description of patterns is needed. I’ll offer this one up using something that’s easy to understand: Vegetables.

1. The Onion Design Pattern; This is a "layered architecture". Instead of 2 or 3 layers, you actually have 20 or 30. Opening it up usually makes you cry.
2. The Asparagus Design Pattern; This pattern is generally tasteless. You’ll think all is fine until hours later when you visit the bathroom.
3.   The Artichoke; Another layered design; In this case almost 90% of the code-base can be cut out and discarded.
4. The Mushroom; Not a true vegetable design pattern. This one grows up overnight. All is usually fine until you cut into it and millions of spores are released into the air.
5.   The Sprout; A malleable design pattern, usually implemented in a "new & fresh" technology like "Ruby on Rails" or "Grails". Sometimes referred to as "Agile" but unable to support any load.

I’m sure there are more…