Where Are Aspects When You Need Them?

I had a brief encounter with aspects at the Colorado Software Summit a couple years back. I was glad to finally get a bit oriented to AOP, to which I had been blissfully ignorant, and decided that I had incredibly limited interest in the topic. Of all things, I kept wondering why AOP did not appear to be widely applied to the presentation layer, which was the first place I would think it to be.

Along comes Matt talking about extensionless URLs (a pet interest of mine) and dropping lines like this:

In an ideal world, it’d be possible to modify the <a> tag at the very core of the view framework you’re using to automatically encode the URL of any “href” attributes.

There you go – a cross-cutting concern if there ever was one. Where is our AOP for the presentation layer?

Technorati tags: coloradosoftwaresummit, aop, aspects, crosscuttingconcerns, URLs, presentation

Book Review: Web 2.0 Design Patterns – Must Read

I had the pleasure of reading the soon-to-be-published Web 2.0 Design Patterns, but am seriously late getting my thoughts out (sorry guys!). In short, this book is well worth the read.

Duane, James, and Dion captured a high-speed drive by of all things 2.0, carefully deconstructing all of the cool tools we’ve been having so much fun with recently. They setup the book with a dissection of some flagship Web 2.0 properties, and contextualization of key memes. Next they define applicable models for capturing Web 2.0 in a pattern language. One my favorite aspects of this chapter was the use of “low end” modeling techniques – such as concept maps, and HTML <meta> tags as a form of WSDL for simple HTTP services. Being an Agilist and a practicalist, I like to see less well refined techniques legitimized. In true 2.0 style, the authors use what works, not just what is academically proscribed.

But the core of the book is a pattern reference. As they state in the intro to that section, it’s not likely something you will read straight through – though it’s certainly well written enough to do so. Each pattern is appropriately brief, but still hangs meat off the bone enough to be useful. The landscape of defined patterns is broad, and oddly shaped. SOA and Mashup are patterns, as are Semantic Web and Microformats. This struck me oddly at first – maybe I was hoping for something more homogenous from a developer’s point of view. But the authors make it work. I have to admit it was amusing to see memes like SOA and SaaS reduced to a pattern template. (Though where is the missing reference to Salesforce.com in the Known Uses for the SaaS pattern?) The authors also extract new patterns native to the Web 2.0 landscape that are very insightful: Participation-Collaboration and Asynchronous Particle Update are very well done.

This book has a definite place on my bookshelf. Useful reference to be sure, but I can also imagine using this as a tool for evangelizing inside a large enterprise. To convert some minds, a pattern-based description might give some of these approaches more legitimacy. But the simple descriptions, useful models, and thoughtful examples in any context will provide the basis for a common understanding of Web 2.0 techniques.

Technorati tags: books, oreilly, web2.0, patterns

REST API for Java – But Will It Be Simple Enough to Actually Be RESTful?

Following Cote’s del.icio.us links, I found that there is a JSR proposed for a RESTful Web Services API. It would be ludicrous for this JSR to not be voted in, so let’s assume it will go forward and become a massively committee-driven document someday, perhaps even accompanied by a reference implementation. The burning question on my mind is: will it actually be simple enough to use?

Hopefully, the JCP learned it’s lesson from the community fallout on WS-* Java APIs. And hopefully it has learned from the RoR community that developer productivity rather than infinite pluggability is actually a key requirement. Think Spring and DI, not commercial black box components and SPIs.

So let’s see if they can actually pull off an API that lacks the following:

• Factory classes for roundabout instantiation
• Manager classes for implementation abstraction
• Engine classes for what should be behind the scenes servicing
• Interface/Implementation pairing ad nauseum (I’m so done with the Bridge pattern)
• Pluggable runtime providers – how about just provide a good one OOTB and be done with it?

Can they possibly do it without the same old, tired patterns?

Technorati tags: java, jcp, jsr, REST, webservices, simplicity, econo, patterns

Ajax Widget Interop, Micropayment Economics, and Our Collective Grim Future

Anne Zelenka caught my attention with her recent posts about Ajax start pages – be sure to check these out.

Tim Peter’s right that ad-supported widgets are micropayments on a couple of levels – content providers are paying distributors micropayments for impressions and clickthroughs, and then I’m paying as a consumer with a drain on my attention. I guess what I am fearing is a world where each widget provider offers free and paid versions, so as a consumer I’m not signed up for a paid version of a single start page (a la NetVibes) that’s ad free, but rather I’m stuck making micropayments to multiple widgeteers if I want ad-free versions of their widgets on whatever start page. Yikes!

Until there are standards or semi-standards for how to produce Ajax widgets that will work on a variety of start pages, this could be the grim future.

Rich Campoamor is right on about the JSR 168 portlet spec. In the original spec (I don’t know where it ended up), all of the meaty UI specs (such as standard CSS style names that would let you add a measure of coherence to an aggregated portlet start page) were an appendix and an afterthought to the spec. I’m not optimistic about Ajax widget interop… but like I said I’m too cynical.

Technorati tags: ajax, startpages, micropayments

The Best Mashups Mix Cultures

Not just applications and data… so said Jon Udell to wrap up his announcement about his new gig. Jon couldn’t have phrased that better, and I couldn’t agree more. Jon was making a larger point about language and platform dogmatism versus solution-oriented pragmatism. Being well-known for his transparency and openness, he is turning heads for going somewhere that most people have associated with being opaque and closed. But he gets the fact that Ozzie is changing the direction of that ship, and perhaps he will do so too.

I myself have been down various roads of being a technology dogmatist. At various times I have ruthlessly and arrogantly defended technologies that I was comfortable with. But more and more I see them as just so many mineral deposits that all clog the same faucet. Sometimes there is a right tool for a job. More often there are various tools that could adequately do the job, but always there is contextualization of tools. I want my value to be as a conduit for delivering, and less of being a lofty wonk or a one-size-fits-all punisher.

Sidenote: I want a job with a title of Evangelist someday! I currently work for an extremely cool employer and believe in the work that I do, but who doesn’t think ahead to their next move. I have long thought that my next stop would be as an industry analyst, but maybe evangelist is a better fit. I’m an evangelist today here, but no one is paying me and the focus is nebulous. And too many evangelists come off as being gilded sales reps. Maybe Jon will change that persona, and recast the coolness surrounding tech evangelism… we’ll see and I’ll be watching.

Technorati tags: jonudell, evangelist, industry analysts, mashup

XSLT Is The Skeleton Key for Roach Motels

That phrase dawned on me at some point yesterday during CSS presentations – it seems like the entire world is being configured in XML. Just about any enterprise software and many development frameworks have their configs in XML, I have even started to see benchmarks on apps that included lines of code together with lines of XML – it’s been elevated to a first class citizen in code metrics! But the fact is that it’s becoming less and less runtime config and more and more business logic codification.

So I think that any enterprise developer worth their salt will build and maintain skills in XSLT, XPath, and XQuery. These are not the hot technical skills that will raise your bill rate or necessarily float your resume to the top of the pile. But I think they are going to be seen as core skills before too long. And you just might be the superhero who rescues your team someday when migrating away from a mountain of proprietary XML configs.

Technorati tags: xslt, xpath, xquery, xml, roachmotel, coloradosoftwaresummit, css2006

More of the Same: You Still Need -ility Management for Saas and Mashups

I have been wanting to follow up on various very good blogs posts I’ve been reading lately around architecture concerns with Saas/mashups. A lot of people bring up concerns on security, etc. when talking about Ajax and the new mashup technology – but old schoolers will say the song remains the same. Sure, there are some new exposure points and those need to be protected, but you primarily need to practice the same good core architecture when dealing in this area.

I fully agree with Robert’s comments on reliability and other -ility management for SaaS/mashups as core architecture principles. I think his experience is an interesting case study from a couple of standpoints – one is that presentation tier/mashup developers obviously need to think about graceful error handling in the UI layer in a new way (not sure if that’s being done generally), as well as logging and outage reporting (highly doubt that’s being done fromt clients as it’s not as easy as server-side). What is the common Saas model for this? Does a mashup developer need to setup his/her own monitors for consumed services? Subscribe to an announcement list? Somehow report from the affected clients?

SOA turns web developers into mashup developers

Like many architects, I have been following the evolution of SOA for awhile now. One thing that has been sticking in my mind is what does SOA really mean for web development teams? The emerging answer is mashups.

There are a lot of very cool mashup apps, and the ground is still fertile. If you haven’t already, check out these sites:

• Chicago crime
• HousingMaps
• Netvibes
• NYC Interactive Transit Map

GoogleMaps (or rather it’s API) is obviously the first major mashup player… there are links to more mashups and mashable APIs at Mashup Feed and some at Programmable Web.

Stephen O’Grady and James Governor have been talking up mashups for awhile now on their respective blogs, and they helped with invites to a very cool mashup event. I think the outcomes of this event will be interesting to digest, and will hopefully fertilize mashup ground even more (you have to have high hopes for an event that has Lessig on the waiting list.)

As enterprises convert more of their backend and middleware to services, and expose those services through REST and SOAP, this creates a great opportunity for a new direction on the front end. Web development teams used to building silo sites now have a fine collection of mashup material, and can extend service re-use into the presentation tier.

I think a lot of web developers are not sure what to make of SOA hype – trying to determine if they should just replace their rusting EJB middle tier with web services and consider themselves SOA-certified (the answer is no). Rather, web developers should start thinking about their own service-oriented presentation-tier needs and ensure those services are available (as in exposed) in both a server- and client-consumable fashion.

Web developers from the traditional server-oriented J2EE and .NET environments should also start boning up on rich internet application (RIA) technologies and architectures. Out of the gates it’s probably not the best idea to go wholesale into RIA with applications, but rather to augment existing sites and applications with asynchronous pagelets that mash in backend services – perhaps tagging would be a good place to start. But it might not be too long before developers inside enterprises can start to act like true mashers, using Agile methods to more quickly deliver working software that leverages services.

BPEL and service orchestration are the mash up tools for the integration tier, but Ajax and other RIA technologies are the mash up tools for the presentation tier. I think there will be a lot of additional demand on enterprise developers to become more client-savvy than they have had to be for the last several years.

I am interested to hear from any enterprise developers who have already started mashing…

Refactorings Beat Patterns

Patterns get a lot of headlines as a best practice for ensuring quality systems, but I’m a much bigger believer in refactorings. I have spent a lot of time on patterns and there is no doubt that they have their place, but I think enterprises that practice Agile will have much greater success if they emphasize good refactorings over good patterns.

The fact is that patterns set the wrong tone – they get you thinking too much about what is perfect, and not enough about what works and is practical. Talking patterns awakens the purist, and before you know it the sun has gone down and you are still at an impasse whether what are you doing should really be an Adapter or not.

Pattern purists will argue, but I contend that patterns are often out of reach for starting developers. Pattern culture is an extension of academic culture, where you are taught that there are experts and non-experts, and you know where you stand. Patterns emphasize that there is a right way, and you might get it wrong if you don’t know what you are doing.

A refactoring-oriented approach, on the other hand, is steeped in Agile practices and encourages you to get something testable in place – delivering value instead of well-argued drawings. A culture built on refactoring also presupposes automated testing which is an essential practice for building quality systems. A refactoring culture encourages experimentation and innovation, and is much more easily accessible to entry-level developers.

Most importantly, a refactoring culture encourages you to deliver and gets you out of the head game of patterns…

Open Source within the Enterprise

We recently brought Burton Group analyst Richard Monson-Haefel in-house for a discussion on what Burton is calling the “Rebel Frameworks”. For us, this was a discussion on best practices and principles for evaluating more lightweight open source tools and frameworks so that we can be more architecturally Agile.

Richard has some interesting perspectives on this issue… he founded the MockEJB project, and authored 2 best-selling O’Reilly books on EJB and Java Web Services – you would think he is a big standards wonk, but guess again. Like many pundits who spent years under the mind cloak that EJB was a Good Thing, he is now extolling the virues of Ruby (along with people like David Geary, who wrote previously sang praises of JSF and JSP). It should give all enterprise architects pause when some seriously bright people are willing to walk away from what they have been saying for years, and admit they were wrong. Are standards so great when tons of doorstop-quality books are required to explain them, and their apologists even stop apologizing?

Being a fan of simplicity, I propose a very simple litmus test that can help with extremely quick assessment of API and frameworks. This simple test involves asking yourself honestly, if this approach seems ridiculously complex or whether it genuinely helps you get there faster. Think about your first Tomcat download and startup – definitely simple and quick. Now try it with JSF – ridiculously complex. Think about where portal technology was a couple years ago when it just hit the hype list – ridiculously complex (arguably only slightly better today, but getting there – smart enterprises are second-guessing vendors who sell it as a chainsaw that can cut butter, but that’s another post). How about insert the name of the last large commercial offering your company procured here: ____ is ridiculously complex. Did that sound natural? Did that purchase really jettison your team down the delivery path? Or did you spend time negotiating it into your physical architecture, and trying to get high-paid professional services teams back in town to help you decipher log messages?

Large enterprises are usually skittish about open source – there is a PowerPoint-style comfort level to have a contract filed away somewhere. Some folks with 3 letters after their names think it’s nice to be able to assign responsibility to people on the other end of the phone, even if they are in India and you need to work through 3 levels to get to the person who now maintains the code (the one who wrote it was outsourced). But what about maintaining control and ownership? What about the fact that many open source projects have as good or better customer service models than commercial vendors? I think every enterprise, especially large enterprises, have an obligation to explore and support these offerings. It might not get you a free lunch, but then again might make sure you have time for lunch…