Virtual Surreality
It’s too real to be true

Jim thought he’d wind me up this morning and told me to read his blog about SCA.

This is another attempt at letting you expose an object-oriented business model to those who may wish to interoperate with your application. In summary, it’s a way of declaring an object interface in SOAP.

Sounds great, doesn’t it? All I have to do is have my tool spit out some WSDL, some SOAP, and some XMLBeans and whatever else is needed, et voila! all of my very well designed business model objects are available for others to manipulate as if their application was a part of my application (it’s a composite application! Oooooo.)

Damn I feel good. I’ve done some great OO today. I’ve applied a bunch of fantastic patterns. I’ve smeared on some interfaces to my objects, yet I didn’t use EJB. And I did it with some XML, and that XML was SOAP, and that SOAP was bound in a WSDL contract, and it was all auto-generated by my J2EE Application Server vendor’s tools (I love those guys). The best thing is, it uses acronyms and phrases that will make the CIO be very successful in being responsive to the business. I can quote “agility”, “service oriented”, “object-oriented”, “component oriented”, “composite application”, “reusable services”, and “rapidly adapt to meet changing business requirements” all in the one breath.

Trouble is, my business model objects aren’t usually so well designed, really. I’ll definately be fixing some of them in the next release. And applying a significant change due to a new feature those business guys need. And I just read a couple of pages of Refactoring, so I’ll do some of that to them too.

Trouble is, my business model objects are usually very specific to the application I’ve written, and aren’t exactly useful or directly usable in another context.

Trouble is, whenever I decide to alter my business model objects, those fabulous tools make concrete changes to things that my consuming interoperators have bound to (a “contract” as defined by WSDL, etc) - and because my vendor has chosen for me, I neither know nor understand what the hell just happened when I hit the redeploy button.

Trouble is, it’s all about ME ME ME, and I’m letting YOU go through pain each and every time I alter my object interface.

Trouble is, I’m only thinking about my local changing business requirements. I’m not thinking about the changing requirements of those who are approaching this problem in the same way as I just have. And when they change their business model for their changing business requirements, I’m the one who goes through pain. Now I understand why Siebel, SAP, and Oracle are into this - because they each think they are the centre of my system universe and everyone should integrate to them.

Trouble is, I didn’t use a service model at all, I was just doing RPC through SOAP. Worse, I was doing it against a Java type system, so it was just RMI through SOAP. Worse, I was doing it to my business model objects that have a high propensity to change with business requirements, not some abstracted service layer objects that change rarely (only when the service contracts change).

Trouble is, I’ve now introduced tight coupling to a language type system, tight coupling to an API, and tight coupling to a business object model. And all under a pretty veil of service orientation which explicitly provides me with loose coupling. What the hell just happened? I need a beer.

Looks like I’ve got another pig with lipstick. I should have stuck to screen-scrapping those CICS applications.

Dropped into this seminar last night to hear four speakers discuss the “new” phenomenon of humans sharing information with each other. Of course, this conversation was set in the content of the Web and mobile devices, and although many of us have been doing it online for years, it’s at the maelstrom level of maturity and adoption now for the masses.

It was fantastic to hear the values and humanity underpinning Jonathan Nicholas‘ core tenents of trust, community-driven equilibrium, and “asking why, before how”. Although he was talking in the context of adolescent mental health it was very much like listening to an Agilist discuss the values inherent to our way of working.

Jennifer Wilson was authoritative on the part mobile devices have to play, not only as content creation and consumption tools, but as non-linear distribution channels, usage paradigm setters, and even subversive tools for those of us who are happy to contribute to an artist’s subsistence but don’t believe it’s the right of Disnewsonywarniacom to either pillage the author or take over our property when we want to enjoy the art. She also talked of the concepts around viral marketing and mentioned a book, which sounded much like the Idea Virus.

Mark Pesce was fascinating, for many reasons. His concise and well-articulated introductory evaluation rang true with me, and from the bobbing heads across the audience (I was at the front, so I merely felt the breeze caused by folicular kinetics), with many others too. In response to some of Mike’s (see below) comments on what News is doing in the myspaces arena, he said a much nicer version of my response which was going to be “if you put your crap on their craft, they’ll go somewhere else”.

Mike Walsh (not the 70’s TV host and cinema mogul) nearly had me snort in derision at his implications that professional journalists and editors clearly know more than the great unwashed and that most blogs circle around stories generated by the news media. I wonder who puts the food on his table at the moment? It’s also interesting as it was basically contradicting his own comments on the the film and music industries.

Anyway, I easily discounted his viewpoint by reflecting on my own experiences. For example, I first heard of the bombings in Baghdad during Desert Storm on IRC from a guy living there (before CNN put up pictures with their supercilious reporters’ supposititious concern for the welfare of the public and the actual concern for their ratings). The world heard of Sony’s DRM shennanigans from the blog of a respected technical practitioner, not from acuity-deficient “technology journalists”.

Update: Cam Reilly just touched on this very thing at another Slattery IT seminar today! Slam dunk.

The most important part of the evening was the chats had afterward. My brainwave (nothing of the sort, given the occassion), was that SlatteryIT ask for the attendees’ blogs and distribute them so we can carry on the conversations and create content of our own, and, as users of the seminar, take control of it’s format in its cyberspace extension. To wit.

To: The editor at Computer magazine (computer.org)
CC: Ken Birman at Cornell University

I enjoyed reading the October 2005 edition of Computer, and after the obligatory reading of “At Random”, I flipped with interest to the Web Technologies column: “Can Web Services Scale Up?” by Ken Birman.

In my simple take on it, Ken suggests the architectural solution to scaling Web services is in relying on the infrastructure (i.e. application servers) to sort it out, while the “user simply designs a data structure and employs multicast technology” for the magical but expensive fairies to sprinkle data dust everywhere. Of course, he points out, CORBA tried and failed, erring by embedding a powerful solution into a tool mismatched to developer needs. CORBA’s lack of wide adoption is due to arguably far more errors that just that (but that’s another topic). He then also sets the scene for even more infrastructure with the requirement for sophisticated monitoring and management tools for these behemoth clusters of RAPS of RACS.

I couldn’t find where Ken addresses the reason for why such complex clustering technologies would be “needed” for scale in the first place: stateful context in the middle tier. Get rid of that and you get rid of the need for sophisticated infrastructure, too-smart-for-their-packets network devices, and super-uber-monitoring-management-of-management-monitors that monitor and manage clusters of hosts of virtual machines. And then you can also buy this neat tool from Quest to tell you why all that stuff has broken too.

State lives in the data tier. Those boys know how to manage and scale state real well. Let’s keep it there, rather than multicasting megabytes of it in the app tier to handle failover (because that’s naught to do with load in a real man’s architecture).

Web services scale horizontally very well when they are provided their context by their consumers (and perhaps handlers along the way), their state is persisted in the nether tiers of database land, and have their load balanced by simple little devices in the switch fabric. They’re a lot cheaper like that too. It’s sort of like the difference between the Library of Congress and the World Wide Web. Are we getting it yet?

Regards,
Josh