The Reincarnation of SOA - Sort of!

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
Wouldn't it be nice if a comment on Service Oriented Architecture (SOA) would attract a lot of attention (for my blog, I'm thinking)? Thousands of people googling 'SOA' come right to my site and find out more about HLL. I can't expect that, because I'm provoked on this occasion to comment in response to a discussion that started in January of last year.

VP and Research Director of The Burton Group, Anne Thomas Manes wrote an article entitled, SOA is Dead; Long Live Services. Burton Group surveys IT R&D and provides business consulting services. They have a particular interest in SOA related development. Ms. Manes' noted a high percent of failure in efforts to use SOA and warned that the change-over is disruptive; requiring a full commitment to succeed. Then she added:

The small select group of organizations that has seen spectacular gains from SOA did so by treating it as an agent of transformation. In each of these success stories, SOA was just one aspect of the transformation effort. And here’s the secret to success: SOA needs to be part of something bigger. If it isn’t, then you need to ask yourself why you’ve been doing it.

One of the many respondents was Kurt Cagle, editor at O'Reilly Media. In SOA is Dead? It's About Time!, he says he is philosophically quite close to Manes with regard to SOA, and adds “that it seemed to be less technology and more marketing term for a number of fairly distinct things, to the fact that distributed technologies are, by their very nature, distributed.”

I particularly enjoyed this comment:

RESTful services - are beginning to gain real traction even as the big-box SOA projects are falling to the accountant's axe. The publish/subscribe model in which what you're publishing are not blogs but data documents (think XBRL or HL7) performs the same type of decoupling that message-oriented SOA did, but completely abstracts the intent from the process of communication.

Now what about HLL? First off, I have to say that I tend to use the dictionary. Not some specialized up to date listing of technical terms – you know, the plain old English language dictionary. I helps to keep me from getting confused by marketing hype. To me, the term “Service Oriented Architecture” refers to an architecture that is oriented to providing services. It's a general term. If you are going to use HLL in support of providing services, that's fine. It can do that (and I think you should). Just don't say something like HLL is an implementation of SOA. SOA isn't a specific thing, so it's grammatically confusing at the very least. SOA isn't itself a technology, even though there seems to be a set of rather basic requirements to do a good job of it.

In the light version of HLL, sockets are used in support of loosely coupled communication. What's generically called the "Java EE" version will probably use JMS. In core processing, HLL will use FIPA to “abstract the intent from the process” in a way that facilitates communication with other systems. Traditional XML (and even SOAP) processing is also supported … and ... HLL actually allows message passing through a variety of structures using the generic 'Object' with object type recognition on the receiving end. The choice for application happens out in the application software, unencumbered by HLL's core architecture.

As for the difficulty of implementing SOA systems – remembering that HLL is HLL and isn't marketed this way at all (although by all means, if SOA is what you want, I'd be pleased if you'd take an interest in HLL) – HLL provides the structure. I don't see it as having the problems the other author's describe. It's flexible. You can centralize to the extent that centralization makes sense, and you can also put copies of HLL on many machines, specializing each set of applications they support, give them access to remote applications and services, either directly or through another copy of HLL.

They seem like old problems. Too boot, HLL is very resource oriented, so much so that I'm almost tempted to refer to its architecture as an ROA - well, maybe I should. If services is what you want, how are you going to do that? (The question how is so very fundamental to engineering.) Well, depending on how you define "resources" (check the dictionary again) - using an ROA might be the answer. Rather trivial once you say it. How are you going to provide services? Is there even any way to do that without using resources?

Well, that's all for now. This entry was just meant to be a quick comment; and it really is - nothing more.