Saturday, February 10, 2007
Terminology Hell
I am sometimes really angry about the way our community makes life hard for themselves. We seem unable to agree on a common terminology. Take SOA for example. I think everybody knows that it is really hard to give a concrete definition of SOA. But I think the community agrees that SOA has to do with things such as- large systems
- enterprise
- integration
- processes
- loose coupling
- reuse
- contracts (i.e. more than interface signatures)
- organization of enterprises
- etc.
If I then hear a talk about OSGi where the presenter suggests that OSGi an SOA platform than I really feel fooled! Yes, in OSGi there's the concept of a service. It's basically a Java interface, with pluggable implementations. But none of the SOA characteristics mentioned above fits in, except maybe for the loose coupling.
Although I understand that everybody wants a share of the SOA hype, I think it would be useful to agree on some terms, at least on the level of the characteristics above, and then not explicitly mess everything up by calling everything an SOA.
Our community and profession is really far away from anything "engineering", if we can't even agree on certain fundamental terms and then stick to it! permalink
Comments:
<< Home
Sorry, I think your definition of SOA is off the mark. OSGi certainly is an SOA platform: services are defined by contracts (their interfaces); they are published in a registry which can be queried at runtime; and, the services have a lifecycle, i.e. they can come and go.
It is the WS-DeathStar crowd who have perverted the term SOA to mean something heavyweight, slow, complicated and intrinsically "enterprisey". SOA doesn't necessarily mean SOAP, WSDL, UDDL etc. SOA is a generic pattern, whereas Web Services is just one implementation of it. The OSGi service platform is an alternative implementation.
It is the WS-DeathStar crowd who have perverted the term SOA to mean something heavyweight, slow, complicated and intrinsically "enterprisey". SOA doesn't necessarily mean SOAP, WSDL, UDDL etc. SOA is a generic pattern, whereas Web Services is just one implementation of it. The OSGi service platform is an alternative implementation.
First of all, thanks for this comment. This proofs that somebody is actually reading my blog :-)
Your point with the lifecycle of OSGi services and the dynamic nature is well taken. That is what I meant by "except maybe for the loose coupling".
However, I really disagree with the rest of what you say. First of all, a POJI (plain old Java interface :-)) is not a contract. Contracts contain way more (semantic) information than just methods and their signature (such as pre- and postconditions, protocol state machines, QoS information, etc.)
Second, I am certainly not trying to say SOA == WS-*. Actually, nothing could be further from what I want to convey. SOA is an architectural style that is completely unrelated so Web Services. But it is an architectural style for large systems (as I described it in my characteristics).
I agree that it is good practice to build also small systems in ways that have *some* of the same properties - and that is what OSGi does (actually, that's just good software engineering practice!). However, in order to keep the terminology straight, I really don't want to call them SOA. Yes, maybe they should be called SOA, and the "large" stuff should be called "enterprise SOA" or whatever. But that's not what's happening.
I like to call stuff like OSGi or similar things "component oriented".
Your point with the lifecycle of OSGi services and the dynamic nature is well taken. That is what I meant by "except maybe for the loose coupling".
However, I really disagree with the rest of what you say. First of all, a POJI (plain old Java interface :-)) is not a contract. Contracts contain way more (semantic) information than just methods and their signature (such as pre- and postconditions, protocol state machines, QoS information, etc.)
Second, I am certainly not trying to say SOA == WS-*. Actually, nothing could be further from what I want to convey. SOA is an architectural style that is completely unrelated so Web Services. But it is an architectural style for large systems (as I described it in my characteristics).
I agree that it is good practice to build also small systems in ways that have *some* of the same properties - and that is what OSGi does (actually, that's just good software engineering practice!). However, in order to keep the terminology straight, I really don't want to call them SOA. Yes, maybe they should be called SOA, and the "large" stuff should be called "enterprise SOA" or whatever. But that's not what's happening.
I like to call stuff like OSGi or similar things "component oriented".
A think to note: SOA means to separate data from logic. Services are logic, data is transfered using data structures. That is very much different from object oriented techniques. Therefore applying SOA-like ideas on a finer grained level (as in the example of OSGi) basically means sacrifizing object orientation. I wonder whether that was was the presenter was trying to suggest (apart from the blurriness of the term you already mentioned).
I might have been the presenter that caused this discussion? :-)
I usually try to explain the OSGi characteristics using SOA (the heavy stuff, but I make it very clear we do not have the heavy weight transport, we directly talk to the object.
I still believe that OSGi falls under the term SOA, especially because it turns out that the service registry is very useful to interact with web services and other SOA systems.
Key for me is the find/bind model to the service as well as the separation of contract and implementation. All these elements are cornerstones of the OSGi architectures.
So I agree with Neil, if you want SOA to mean heavyweight webservices, OSGi is not what comes to mind. If you look for a service oriented architecture for software, I think it is.
Kind regards,
Peter Kriens
I usually try to explain the OSGi characteristics using SOA (the heavy stuff, but I make it very clear we do not have the heavy weight transport, we directly talk to the object.
I still believe that OSGi falls under the term SOA, especially because it turns out that the service registry is very useful to interact with web services and other SOA systems.
Key for me is the find/bind model to the service as well as the separation of contract and implementation. All these elements are cornerstones of the OSGi architectures.
So I agree with Neil, if you want SOA to mean heavyweight webservices, OSGi is not what comes to mind. If you look for a service oriented architecture for software, I think it is.
Kind regards,
Peter Kriens
No Peter, it wasn't you :-)
I agree that an OSGi-based system can play the role of one participant (a component implementation technology, just as EJB, SCA, CCM or a Web Server).
But SOA refers (in my view, anyway) to the overall architecture. It's not about heavyweight transport, it's about architecting the overall IT landscape of an enterprise.
And OSGi doesn't help me there.
> Key for me is the find/bind
> model to the service as well as
> the separation of contract and
> implementation.
> All these elements are
> cornerstones of the OSGi
> architectures.
as I said in a previous reply, I agree that the find/bind thing is useful and in line with SOA characteristics. But then, the Lookup patterns is quite old and implemented by many many systems. Every CORBA Naming/Trader service has done this for ages. So I am not willing to call all those systems to be an SOA.
As I said: a single system, in my view, cannot be an SOA, because the term refers to the collection of systems that make up an enterprise infrastructure.
And by the way: all of this is not saying anything about the usefulness of OSGi and/or it's programming model. I like it quite a bit. But it's not SOA. And there's no reason to call all kinds of things SOA. Makes things incredibly more complicated.
I agree that an OSGi-based system can play the role of one participant (a component implementation technology, just as EJB, SCA, CCM or a Web Server).
But SOA refers (in my view, anyway) to the overall architecture. It's not about heavyweight transport, it's about architecting the overall IT landscape of an enterprise.
And OSGi doesn't help me there.
> Key for me is the find/bind
> model to the service as well as
> the separation of contract and
> implementation.
> All these elements are
> cornerstones of the OSGi
> architectures.
as I said in a previous reply, I agree that the find/bind thing is useful and in line with SOA characteristics. But then, the Lookup patterns is quite old and implemented by many many systems. Every CORBA Naming/Trader service has done this for ages. So I am not willing to call all those systems to be an SOA.
As I said: a single system, in my view, cannot be an SOA, because the term refers to the collection of systems that make up an enterprise infrastructure.
And by the way: all of this is not saying anything about the usefulness of OSGi and/or it's programming model. I like it quite a bit. But it's not SOA. And there's no reason to call all kinds of things SOA. Makes things incredibly more complicated.
Well, what definition of SOA do you adhere to?
* Open Group SOA Definition (SOA-Definition)[3]
* OASIS SOA Reference Model (SOA-RM)[4]
* What Is Service-Oriented Architecture? (XML.com)
* What is Service-Oriented Architecture? (Javaworld.com)
* Webopedia definition
* TechEncyclopedia definition
* Object Management Group (OMG ) SOA Special Interest Group definition
* WhatIs.com definition
* SearchWebServices.com Numerous SOA definitions by industry experts
If you look at all of the you will see that key for a service oriented architecture is separation from implementation and contract/interface and the possibility to find/bind. Notice also that the OSGi service contracts have well defined semantics in our specifications.
Also notice that we have used the word "service" and service oriented programming since 1998, it is not that we jumped on the bandwagon when it became a hype.
When I explain how OSGi works I usually make the comparison but make it clear that we do not mandate the heavyweight protocols.
However, if the OSGi architecture is used distributed (as we start working on now in the Enterprise group), would you allow it to be called an example of an SOA?
I assume you would, how would you explain that the way you would program it would not differ?
Kind regards,
Peter Kriens
* Open Group SOA Definition (SOA-Definition)[3]
* OASIS SOA Reference Model (SOA-RM)[4]
* What Is Service-Oriented Architecture? (XML.com)
* What is Service-Oriented Architecture? (Javaworld.com)
* Webopedia definition
* TechEncyclopedia definition
* Object Management Group (OMG ) SOA Special Interest Group definition
* WhatIs.com definition
* SearchWebServices.com Numerous SOA definitions by industry experts
If you look at all of the you will see that key for a service oriented architecture is separation from implementation and contract/interface and the possibility to find/bind. Notice also that the OSGi service contracts have well defined semantics in our specifications.
Also notice that we have used the word "service" and service oriented programming since 1998, it is not that we jumped on the bandwagon when it became a hype.
When I explain how OSGi works I usually make the comparison but make it clear that we do not mandate the heavyweight protocols.
However, if the OSGi architecture is used distributed (as we start working on now in the Enterprise group), would you allow it to be called an example of an SOA?
I assume you would, how would you explain that the way you would program it would not differ?
Kind regards,
Peter Kriens
indeed. Adding "distributed" makes a lot of sense. I took it for granted, so I didn't even think of it :-)
> Well, what definition of SOA do > you adhere to?
as I said, I don't there's an agreed definition. That's why I gave the characteristics.
> If you look at all of the you
> will see that key for a service
> oriented architecture is
> separation from implementation
> and contract/interface and the
> possibility to find/bind.
yes. I think I had these in my characteristics, right? As I said,
I agree that OSGi satisfies some of the requirements, but by no means all.
> Notice also that the OSGi
> service contracts have well
> defined semantics in our
> specifications.
I am not arguing whether the concept of a service is semantically well-defined or not. I suggest that you should be able to specify semantics of a specific service. In OSGi you can't do that. A service is simply a Java interface. And that's just a signature.
> Also notice that we have used
> the word "service" and service
> oriented programming since 1998,
> it is not that we jumped on the > bandwagon when it became a hype.
I am not suggesting that the OSGi alliance did. I thought that the specific presenter wanted a share of the hype. Based on his formulations, this was pretty obvious.
Also, service orientation or service oriented programming, is not the same as SOA! There *is* a difference, at the very least, scale!
> When I explain how OSGi works I > usually make the comparison but > make it clear that we do not
> mandate the heavyweight
> protocols.
as I pointed out, this has nothing to do with protocols. But as Glyn pointed out, a non-distributed SOA (e.g within an OSGi runtime) is kinda pointless.
> However, if the OSGi
> architecture is used distributed
> (as we start working on now in
> the Enterprise group), would you
> allow it to be called an example
> of an SOA?
I would have to take a look at it first.
> I assume you would,
I am not so sure ...
> how would you explain that the
> way you would program it would
> not differ?
that is the whole point: a programming model is not the same as an *architecture*. The programming model might well stay the same, although the underlying architecture changes.
By the way, I doubt that the programming model will stay unchanged, because of the additional latency and failure modes.
as I said, I don't there's an agreed definition. That's why I gave the characteristics.
> If you look at all of the you
> will see that key for a service
> oriented architecture is
> separation from implementation
> and contract/interface and the
> possibility to find/bind.
yes. I think I had these in my characteristics, right? As I said,
I agree that OSGi satisfies some of the requirements, but by no means all.
> Notice also that the OSGi
> service contracts have well
> defined semantics in our
> specifications.
I am not arguing whether the concept of a service is semantically well-defined or not. I suggest that you should be able to specify semantics of a specific service. In OSGi you can't do that. A service is simply a Java interface. And that's just a signature.
> Also notice that we have used
> the word "service" and service
> oriented programming since 1998,
> it is not that we jumped on the > bandwagon when it became a hype.
I am not suggesting that the OSGi alliance did. I thought that the specific presenter wanted a share of the hype. Based on his formulations, this was pretty obvious.
Also, service orientation or service oriented programming, is not the same as SOA! There *is* a difference, at the very least, scale!
> When I explain how OSGi works I > usually make the comparison but > make it clear that we do not
> mandate the heavyweight
> protocols.
as I pointed out, this has nothing to do with protocols. But as Glyn pointed out, a non-distributed SOA (e.g within an OSGi runtime) is kinda pointless.
> However, if the OSGi
> architecture is used distributed
> (as we start working on now in
> the Enterprise group), would you
> allow it to be called an example
> of an SOA?
I would have to take a look at it first.
> I assume you would,
I am not so sure ...
> how would you explain that the
> way you would program it would
> not differ?
that is the whole point: a programming model is not the same as an *architecture*. The programming model might well stay the same, although the underlying architecture changes.
By the way, I doubt that the programming model will stay unchanged, because of the additional latency and failure modes.
I think what you're looking at here is... yes, I'm going to do it, I'm going to coin another term - Micro SOA.
OSGi conforms to most of the ideas you'd expect from SOA. Service based. Reusable. Loosely coupled. And so on. But the difference here is that as opposed to working across a highly distributed landscape, it operates in a much smaller environment, but the ideals still hold the same.
SOA as you say is very hard to define, and consequently it can be applied at a lot of different levels with different meanings. I see no reason why it can't also be applied to OSGI at the absolute smallest level.
Post a Comment
OSGi conforms to most of the ideas you'd expect from SOA. Service based. Reusable. Loosely coupled. And so on. But the difference here is that as opposed to working across a highly distributed landscape, it operates in a much smaller environment, but the ideals still hold the same.
SOA as you say is very hard to define, and consequently it can be applied at a lot of different levels with different meanings. I see no reason why it can't also be applied to OSGI at the absolute smallest level.
<< Home