4 Types of SOA
Boink!
That's the sound of me understanding why my SOA-guru collegues don't seem to be making sense, they keep talking about SOA, but I'm not getting any signal.
It turns out that there are at least 4 types of SOA here that Martin has kindly described. Here is my very shoddy summary of his much nicer article:
- Type 1 - XML over HTTP
- Type 2 - Application builders consuming enterprise services
- Type 3 - "CORBA with angle brackets"
- Type 4 - Asynchronous message based enterprise integration
Now all we need are snazzy names for each type, so we don't end up having to use these names like what happened with IoC.
posted by Ben Hogan at 5:29 pm
2 Comments:
Ben,
There's only one type of SOA - the others are (I think) integration approaches.
SOA is, in my current state of mind, categorised as message-oriented and implementing IoC. I think the last bit is the killer tho, IoC means that services are externally coordinatable and thus you can actually use them to create composite applications where application boundaries are defined by porcesses rather than as a point to point mechanism (or the glue in a client-server application).
Jim
Hey, I think this is what I have been trying to achieve. I just never had a name for it..
http://atomic.catchpole.net/
XML over HTTP? Why do people go for the biggest, most heavy weight solutions possible? The solutions will be found at a lot lower level than that. Basically, it will be inversion of control at an Object level - and if done properly, could change the world. Sync or Async can be managed at that level, as can clustering, serialization and just about everything else.
MDA generating reams of source code is another bad idea. That is all about pushing the model back into a platform that can't represent it dynamically. Models should be more agile than that.
It does though require a shift in your object design. They have to be simpler and cleaner - and invertible.
Java had me very excited about the future of software, and "applications" and data representation. But with J2EE, DB persistence, MVCs and about 7 thousand other tiers, apps are becoming the big lumping behemoths they used to be in C++ days. They deliver a lot more functionality for your development dollar, but think of all the things you see people doing with computers in the movies. "Movie computers" are easy because they don’t have reality and disconnected architectures and "reality" to deal with.
I don’t know if my project will ever fulfil the dream, but I will get it a red hot try. Developing any other kind of application or framework just seems like a waste of time.
Post a Comment
<< Home