all bits considered data to information to knowledge


Extensible Architecture

Q: How to prove to a client that the system is extensible? (an actual question...)

Nail down the client’s definition of extensibility first; it might be possible that her ideas are quite different from yours. Once you are on the same page, make sure she understands the limitations of extensibility and ramifications of thereof; for example, she might want a Cadillac but only has a Yugo budget.  

Designing an infinitely extensible system requires both time and budget of corresponding proportions…

 In a single sentence: an extensible architecture would have a modular structure as well as defined set of API(s) for integration; current paradigm leans towards loose coupling, usually via Web Services (latency, concurrency and other inherent limitations need to be carefully considered).


Who’s got Web Services right

Once in a while, Microsoft does the right thing, and the rest of the programming community ought to simply acknowledge the contribution, and move forward. Consider web services: creating a webservice in .Net is [almost] as easy as marking a function with WebMethod attribute .

Here're some well taken points emanating from Mark D. Hansen - a bona fide Java developer and architect (and the author of SOA Using Java Web Services book)

"Adding web services to Java applications should not require programming. There should be a simple ON/OFF switch. You should be able to select some business logic, flip the ON switch, and publish it as a web service.  Unfortunately, Java isn’t designed that way. Java requires you to write code, annotate classes, recompile, and redeploy. And it isn’t simple coding either[md]particularly when you run into problems with Java/XML serialization."

Mark goes on quoting in his book the blog of Dave Podnar - a hilarious summation of the problem!

Dave Podnar's Five Stages of Dealing with Web Services

1. Denial: It's Simple Object Access Protocol, right?
2. Over-Involvement: OK, I'll read the SOAP, WSDL, WS-I BP, JAX-WS, SAAJ, JAXB, … specs. Next, I'll check the wiki and finally follow an example showing service and client sides.
3. Anger: I can't believe those
#$%&*@s made it so difficult!

I could not find the remaining two stages on the Net, but would speculate that they either deal with either reaching nirvana or switching to COBOL programming...


SOA is dead, long live SOA!

A couple years ago I came across Joe McKendrick's article The Rise of the JBOWS Architecture. It was smack in the middle of the big SOA (Service Oriented Architecture) hype cycle, and right on target. Lots have changed since: SOA was buried (notably, in Gartner’s report on the subject and Burton’s group Anne Thomas Manes article), dug up (for instance, the very same Joe McKendrick ) , and resurrected (You’ll all be doing SOA in 18 months )  Strangely enough, all these events appear to happen in no particular order…

For me, SOA was not a new concept; it was yet another incarnation of distributed computing. Anyone who had struggled with DCOM and CORBA would appreciate elegancy of XML based communications over HTTP. So, there is no doubt in my mind that SOA is here to stay; it will bounce back, and will become the next real thing, albeit scarred and hardened by tech vendors attempts to make a quick buck.

Back to JBOWS architecture. I found myself explaining – times and again – to the managers on every level why web services do not equal SOA, and I came up with a metaphor that appears to be working for lots of folks: mail delivery system.

If you need to deliver a package from point A to point B, a courier service would be one option. It is fast, it is reasonably secure and it is reliable; you can even trace the way the parcel will be delivered to the recipient, All you need to know is the exact location (address) of the point B. Oh, and you need to pay the courier.

The second option would be USPS – United States Postal Services. It is a lot cheaper than private courier; it is reasonably fast, reasonably secure and reliable. It also could forward your mail should your intended recipient have moved without notifying you beforehand.

This is in nutshell the difference between JBOWS and SOA. The latter is all about economies of scale, creating infrastructure with built-in fault tolerance (what if your courier company had run out of couriers just when you need to send a package) and ability to orchestrate the deliveries according to some business rule. The former is brittle, non-scalable and has very low fault tolerance barrier;  and it is also by order of magnitude more expensive in the long run (admittedly, SOA requires more up-front costs).