I love watching a knowledgeable and patient person get pushed beyond reasonable limits by the imbecilic hordes and consequently have to lay the smack down. Yes, I’d like extra butter on my popcorn, please.
I love watching a knowledgeable and patient person get pushed beyond reasonable limits by the imbecilic hordes and consequently have to lay the smack down. Yes, I’d like extra butter on my popcorn, please.
I suppose it is time for me to speak up about SOA. First let me say that I have not read any of the “media buzz” articles about SOA. If you take any of those frothing technology journalists seriously, you will come to believe that every new technology is the second coming, that every old technology failed to deliver on the hype (and forget who over-hyped it), and that everything you know about application development will be obsolete tomorrow — each and every tomorrow. I try to get my information from the technology’s documentation and form my own conclusions.
Somewhere between the press releases and the technology specifications are some good resources to quickly understand a given technology. For SOA, these resources include: the definition of SOA, this article introducing SOA to technologists, and this article introducing SOA to business people. What you find from these sources is that SOA does not introduce anything new to our technological toolkit. So why does anybody care? Well, I’m not really sure.
A key idea seems to be that services are different than the remote components provided by EJB, CORBA, and DCOM because services are loosely coupled. It is all about loose coupling. And reusability.
Isn’t loose coupling a best practice of design? And wasn’t reusability the holy grail of that old buzzword: components? Hey, while I’m thinking about it, isn’t this whole “service” approach to development one of the underpinnings of JINI and JavaSpaces? (JINI — that technology looking for a problem — seems to be suffering the same fate as too many other great technologies: it was ahead of its time.)
Some proponents of SOA proclaim it to be the next great paradigm shift in the software development industry — the successor to object-oriented practices. And indeed, SOA does promote a healthy separation between business process logic and business data. This is not in conflict with OO (as it usually practiced today). Anyone who can find a hole in the ground with two hands, a map, and a flashlight should be able to recognize when process logic is going to be the heavily reused portion of an application and provide an entry point to that process for the use of external or future agents.
This approach was adopted years ago (nearly decades ago) for computer based training (CBT). Organizations wanted integration of their training resources, so learning management systems (LMS’s) were developed that implemented certain interfaces (AICC, SCORM, and so on) and defined interfaces for training modules to implement. The “services” of training management were loosely coupled in an extensible manner with the “services” of training content providers.
Martin Fowler has pointed out that a lot of IT infrastructure is already “service-oriented”, but that the “service providers” are databases.
So, I guess I have this to say about SOA: duh! You shouldn’t need a pundit to tell you that it is a good idea to make critical IT infrastructure prone to reuse accessible within your enterprise.
I just stumbled across the blog of Rick Hightower, author of Java Tools for eXtreme Programming. I haven’t read back very far, but in this posting Rick states “Models are artifacts that aid in communicating with the customer”.
Blink, blink. Rub eyes. Reread. Scratch head.
Who are his customers? I have never known a customer of a business product to care about “geeky tech pictures”, much less want to hold a conversation around them. Generally, UML is less intelligible to the consumers of business applications than Egyptian hieroglyphics.[1] So how do models aid communication with customers?[2]
For the time spent on creating models to “aid in communicating with the customer”, couldn’t a prototype — even a paper prototype — have been constructed? How are models superior to prototypes for enabling customers to evaluate the expected business value of the solution being envisioned? The problem is that modeling is about design, which is inherently a technical concern, not a business concern. Modeling helps developers make technical decisions. How are models supposed to help customers make business decisions?
I should mention that I think modeling can be a very productive activity and an efficient use of resources. I just do not believe that models are a good mechanism for communicating with customers. Also, sub-contracting or developing for a technical firm is clearly a different matter. Maybe Rick frequently consults for technology firms, so those are his customers and that is why his perspective is skewed…
[1] As well it should be. Why should they be made to learn something so far out of their business domain — what value is it to them?
[2] I’ll concede that use case diagrams may be an exception, but I would not call those “models”.
