Archive for October, 2009

Musings on Flex

October 20, 2009

I’ve recently been doing some hard-core Flex coding – refreshing some latent recent exposure and leveraging my other UI (namely Swing and Web) knowledge. Having just implemented several web services (REST and SOAP) for Flex/Flash front-ends, and having dabbled in some Flex, I decided to “bite the bullet” and implement an end-to-end Flex application. A particular emphasis was on exploring different Flex server-side technologies – HTTPService, WebService (SOAP) and BlazeDS options. I based the application on my existing canonical Playlist/Video web services application implemented with a SOAP (CXF JAX-WS) and REST (CXF JAX-RS) interface.The goal was to create a simple canonical CRUD application that could alernatively talk to different back-end providers, HTTP/REST, SOAP or LiveCycle/BlazeDS channels.

The first pass consisted in creating a tab panel of list views of the key domain objects – playlists, videos, genres, media and users. The goal was to have the data for each list view obtained from any number of back-end services. I started out with direct data provider binding, but soon moved over to an “adapter” middle layer model since each service was not guaranteed to send back the exact same format.

Having worked with a number of different technologies, I was curious to see how the Flex environment addresses some basic issues:

  • Distributed programming
  • Binary Protocols
  • UI programming
  • Declarative vs. Procedural
  • Type-safe programming
  • Frameworks

Sample Screens

Playlists

Genres

Remote Programming

I’ve worked with many a distributed computing framework (RPC, CORBA, RMI, WS*, REST, HTTP/POX/*, etc.) over the last few years, and although as an insdustry we do seem to be making progress, its always surprising at how slow it is – sort of like two steps forward, one step backward. The Flex approach is especially unique in that it uses a dual declarative/procedural model – MXML and ActionScript. The former is great to get started, but as soon as you need to invoke rich services, the latter becomes move appealing.

For instance, I needed to talk to my existing REST service which I treat as a “whole” – all the different URIs comprise one service. The Flex HttpService seemed to be forcing me treat each URI as a separate “service”. No prob, I just created an AS component that wrapped this all up in one adapter service. 🙂 As usual, one starts out with a “simple” declarative approach but as soon as the beast of complexity rears its head, a procedural approach becomes more appropriate.

Binary Protocols

Yes to binary! XML is OK for some stuff, but any heavy duty system with performant SLA has to entertain binary. From the performance perspective, XML has been a big step backwards especially with its hyper-verbose begin-tag and end-tag duo. My question regarding the solution is: does Adobe have intentions to fully leverage the rich protocol capabilities and allow different client languages to bind to services? Any reason Java clients shouldn’t be able to consume AMF or RTMP? I haven’t researched this completely, but I’ve heard that AMF has recently been open-sourced.

Wild card question: what about GWT’s remoting protocol? How does it compare to AMF? Any reason that the two couldn’t be made more generalizable? I’m sure there are plenty of open source programmers more than willing to whip out language-specific client binding.

For more on the topic see:

UI Programming

I’ve got a lot to say on this after suffering through the hell of Swing GridBags. Flex layouts rock! But its not nirvana, and as soon as you want to fully control rendering, you’ve got to attend the gory details. C’est la vie, I suppose. Nice, nice integration with Eclipse – the Design and Source mode work without a hitch. More to be said later…

Type-safe programming

Although much of my recent experience has been with type-safe languages such as Java, the appeal of scripting languages is undeniable. Its not an “either-or” proposition – rather its the right tool for the right occasion. Unix scripting and lately Python have been a key components of my toolbox. AS is an interesting hybrid creature – it definitely has evolved more type-safe (less surprises at run-time) constructs than JavaScript, but there are still some apparent logical “inconsistencies” that need to be taken on faith. For example, what a hoops the underlying parser has to jump through to understand a binding of raw XML stanza to a variable without even quotes. I’d love to see the unit test for this! Cool! But…

Of more concern is the ability to “seamlessly” bind a “data provider” to a UI component such as a data grid. When the hoped-for happy path is executed all is fine, but when an unexpected data element is passed, Flex seems to silently swallow the error and displays nothing. The user then wonders: was there no data, or what? Perhaps I’m missing something here?

Furthermore, some of the error messages are positively impossible to figure out! For example, all of a sudden I started getting the following:

Error #2070: Security sandbox violation: caller cannot access Stage owned by

Not a hint, not a clue what the problem was. Thanks goodness to good ol’ Google, I was able to resolve the issue rather quickly (simply bad XML). But I really had hoped for more intelligence from the framework.

One of my “pet peeves” is making sure a system will report intelligible messages to the client when errors are encountered. Users expect that minimal politeness of the system: if the system know an error happened, please be so kind to tell us what it was! Of course, full “intelligence” can be surprisingly costly and complex. Of course, this a the topic for an a separate blog.

Components

Having worked with Swing for quite a while, I know how hard it is to truly develop pluggable declarative components. Its not the technical aspect, its more the lack of a consistent approach in the Swing community. Lately there’s been movement in this space, but now that Swing has been officially deprecated by Sun (Oracle?), is this all moot?

This is where Flex definitely shines. The ability to mix D & P – declarative/MXML and procedural/AS is truly cool. Reuse is predicated on being able to modularize common functionality – be it Flex components or OSGI modules. Of course “the devil is in the details” – the right mix of D or P in a component has to be decided on a case-by-case basis. Ill definitely be spending more time delving into this topic.

Declarative vs. Procedural and Frameworks

At first, the dissonance between “angly” MXML and “curly” AS is a bit jarring, but I suppose one gets used to it. Two different ways to do the same thing. With so many choices, comes responsibility. I’m looking forward to exploring some of the up and coming Flex frameworks such as Cairngorn, Spring ActionScript, Swiz, Mate, etc. to see how they can streamline the effort.

For more, see Christophe Coenraets’ articles:

Advertisements

Review of “Web Services – Contract – Design and Versioning” Book

October 19, 2009

The renowned SOA author Thomas Erl has just released a new book Web Services – Contract – Design and Versioning. It is quite a lengthy book totaling more than 700 pages! It would be nice to have a more digestible primer for those who can’t afford the time to read that many pages. I haven’t read the whole book yet, but I have been reading some quite interesting chapters at my local Border’s bookstore.

Sidebar: Though a small branch, it surprisingly has two copies of the book and yet nothing else by Erl. Go figure! I’d bet that I’m the only one who has touched the book so far (the bookstore is in a non-geek part of town).

Reading books like this sort of bum me out a bit. They sound so common-sensical and self-evident that one wonders why doesn’t everyone just follow these precepts. The style of writing is cogent and idealistic. There is truly little one can disagree with. We’re all against nuclear war, right?

One problem with the book is a lack of pragmatics – rarely does one encounter such ideal circumstances in the the real world. The SOA/WS trenches “out there” are very messy and it would have been nice to address the discrepancy between what ought to be and what is. Rarely are managers well-versed in such SOA good practices to be able to understand the need (cost) to spend some up-front time thinking about schema reuse (e.g. decouple XSD from WSDL) and the various approaches and implications of contract versioning and service evolution.

Come to think of it, Erl’s next book should be devoted to the topic of effectively applying SOA/WS best practices in a less-than-ideal world where non-technical office politics most often rule! Something along the lines of Yourdon’s Death March – how about the “Implementing SOA ideals in a Death March-like project”.

I did like the discussion of the trade-offs between an XSD separate from WSDL and a combined WSDL/XSD. There is a brief mention that although desirable, this and other “best practices” are often constrained by subpar tool implememtations. I wish this topic would have been explored further – in fact a whole chapter should have been devoted to the problem how tools (i.e. stubs) limit service providers’ and clients’ abilities to truly take full advantage of WS*. Dealing with raw WSDL is a difficult chore, and tools that automate much of the mundane chores of WSDL/code mapping also introduce non-trivial complexities. Not much new here, but in my experience tools have often given “lazy” (either time-constrained or non-curious) developers a false sense of security when dealing with SOAP. Again, a dash of pragmatics would have been helpful.

The book is definitely geared toward “big-enterprise” SOA/WS, in fact “huge-enterprise” where there are well-thought out plans and strategies regarding contracts and services. It would have been good to touch upon smaller-scale WS roll-outs – be they public or internal departmental. In my experience there is a significant difference between external-facing web services on the public internet and intranet-based services. This difference can lead to quite different strategies and tactics in design and deployment.

For a public service, you would definitely want to opt for contract-first design (WSDL to stubs) for inter-op reasons and have more of an awareness of contract versioning since you have little control over your clients. For an internal service, you can get away with a code-first approach since it is so much faster to develop, and you most probably have less inter-op concerns since you control both the server and client . New incompatible versions can be rolled out with much less pain. These days in the Java world JAX-WS annotations reduce (but do not eliminate) the impedance mismatch between code-first and contract-first strategies.

One complaint is that a chapter’s authors are not identified! With so many eminent authors, it is a pity that the interested reader cannot follow up. For example, in chapter 22.1 (p. 659) there is a pretty theoretical section on compatibility which I just happened to recognize from David Orchard’s (an author) 2006 article A Theory of Compatible Versions. It would have been helpful to those who enjoy this stuff to be able to delve into the topic more. Furthermore there are no footnotes nor references! For a “serious” book this size, this is rather shocking.

Another issue I had with the book was its lack of discussion of REST and REST-ian approaches to contract versioning. Considering how widespread REST services are today, this is rather puzzling. I would have enjoyed hearing a serious “non-religious” discussion as to when a SOAP or REST approach is more appropriate. For example, REST better suits public consumer-oriented APIs (flickr, AWS) whereas WS* might be more appropriate for a complex B2B integration scenario with functionality that cannot be easily shoe-horned into a resource model with only four HTTP verbs.

There seemed to be an implicit equating of SOA with WS-* and no shedding of light on more general problems of contract versioning. REST services whose data payloads are defined by an XSD face the same problems that SOAP XSD data formats. And what about popular data formats that do not use XSD such as Atom? The Atom and AtomPub approach, with built-in extensibility, is certainly something that should be on the radar screen of service designers. Google is using Atom as the basis for many of their web APIs – see Google Data. However, the service operation layer – WSDL and resource model – face quite different versioning problems. I would have loved to hear what some of the Ă©minence grise authors had to say about that!

For more information, see two good preview excerpts by the authors:

There is also an excellent article that talks about real-life trade-offs and issues in contract versioning: