To continue my earlier train of thought, perhaps an analogy from Marketing will help to illustrate the difference between Object-Orientation and Service-Orientation.
Rookie marketing folk are often admonished to "sell benefits, not features."
It's no use telling a potential customer that your product is orange in colour, is made of plastic and consumes 1.5 volts of electricity. The customer is just going to think, "How does that benefit me?" and walk away without making the purchase. To be effective, the marketing person needs to cast those features of the product into benefits for the customer.
"It's bright orange and easily spottable even in dim light, so you'll never lose it or leave it behind in the park by mistake."
"It's made of plastic, so it won't rust, it's lightweight and non-toxic, safe for kids."
"It runs on 1.5 V batteries which are readily available and convenient to use."
When features are reframed as benefits to the consumer, a sale is more likely to happen.
Object-Orientation is like talking about features. It's all about (State and) Behaviour, i.e., what the object can do.
Service-Orientation is like talking about benefits. It's about what the consumer can do (with the object, or preferably leave the object out of the discussion entirely).
I suppress a smile when non-IT Indian friends remark about how "service-oriented" India has become these days. No, they don't mean that India has started using SOAP and REST. It's just that the old arrogant sales attitude of "Here's our product. Take it or leave it" has gone, replaced by a much more consumer-friendly attitude. There's far greater willingness to customise and to offer value-added services. That's because the focus has shifted from what a product can do to what the consumer wants to do. The product becomes incidental to the discussion.
This difference in focus is subtle but very important.
I suspect the reason for the popularity of aggregation services today is primarily because aggregation is something that objects themselves cannot do, because it's a "meta" capability. An airline system built according to Object-Oriented principles may be able to tell you all the details of a flight from city A to city B, but it can't reflect on itself and others like itself to tell you which is the cheapest and most convenient flight from A to B. That requires Service-Orientation. Lots of Web-based services are like that, about finding the "best", the "cheapest", the "most optimal".
[Aside: REST is based on the Web, and since SOAP-RPC is nothing but Object-Orientation-made-remote (unsuccessfully at that), REST obviously works better than SOAP-RPC. But SOAP Messaging is as Service-Oriented as REST, because it also focuses on what the service consumer can do (with specially tailored verbs that imply the service consumer as the subject).]
To my mind, aggregation services are low-hanging fruit for service-orientation. It's an obvious area where OO systems can't play. The attitude needs to become more pervasive, even for non-aggregation services.
To recollect our discussion about EJB, that's why Entity Beans require Service Façades, i.e., Session Beans that sit in front of them and change the focus from what the Entities can do to what the service consumer wants to do. Aggregation is one of the things that Session Beans do. It's the most obvious benefit, because making an interaction coarse-grained is more performant than having a highly chatty interaction with hundreds of Entities directly. But that's not the only benefit.
As I said before, REST is a great Service-Oriented solution even though it appears to be focused on entities just like Entity EJBs. The difference between REST and Entity EJBs (or between REST and OO for that matter) is that the focus is not on what the Resources can do, but on what the service consumer can do with those Resources. The four HTTP verbs of REST have the service consumer as the subject, not the resource. They are transitive verbs that have the resource as their object. You GET a Resource. You DELETE a Resource. Etc. It's easy for "you" to GET or DELETE a set of resources using the same idiom.
By contrast, OO systems have the "object" as the subject of the verb (if that doesn't confuse you), and the verbs tend to be intransitive (e.g., someObject.changeState()). (Where the verbs are transitive, another object (the "object" of the verb) is usually a parameter to the method verb, e.g., someObject.modify( anotherObject ).) It's not possible to extend an object's method to deal with a set of similar objects instead. That's because the focus is wrong from the start.
It's getting clearer in my mind now, but I realise the concept can take some getting used to. For now, a simple mantra to distinguish Service-Orientation from Object-Orientation:
Benefits, not features.
(I hope this doesn't spark off a new TLA fad - Benefit-Oriented Programming (BOP)). It's still just SOA, guys.
Rookie marketing folk are often admonished to "sell benefits, not features."
It's no use telling a potential customer that your product is orange in colour, is made of plastic and consumes 1.5 volts of electricity. The customer is just going to think, "How does that benefit me?" and walk away without making the purchase. To be effective, the marketing person needs to cast those features of the product into benefits for the customer.
"It's bright orange and easily spottable even in dim light, so you'll never lose it or leave it behind in the park by mistake."
"It's made of plastic, so it won't rust, it's lightweight and non-toxic, safe for kids."
"It runs on 1.5 V batteries which are readily available and convenient to use."
When features are reframed as benefits to the consumer, a sale is more likely to happen.
Object-Orientation is like talking about features. It's all about (State and) Behaviour, i.e., what the object can do.
Service-Orientation is like talking about benefits. It's about what the consumer can do (with the object, or preferably leave the object out of the discussion entirely).
I suppress a smile when non-IT Indian friends remark about how "service-oriented" India has become these days. No, they don't mean that India has started using SOAP and REST. It's just that the old arrogant sales attitude of "Here's our product. Take it or leave it" has gone, replaced by a much more consumer-friendly attitude. There's far greater willingness to customise and to offer value-added services. That's because the focus has shifted from what a product can do to what the consumer wants to do. The product becomes incidental to the discussion.
This difference in focus is subtle but very important.
I suspect the reason for the popularity of aggregation services today is primarily because aggregation is something that objects themselves cannot do, because it's a "meta" capability. An airline system built according to Object-Oriented principles may be able to tell you all the details of a flight from city A to city B, but it can't reflect on itself and others like itself to tell you which is the cheapest and most convenient flight from A to B. That requires Service-Orientation. Lots of Web-based services are like that, about finding the "best", the "cheapest", the "most optimal".
[Aside: REST is based on the Web, and since SOAP-RPC is nothing but Object-Orientation-made-remote (unsuccessfully at that), REST obviously works better than SOAP-RPC. But SOAP Messaging is as Service-Oriented as REST, because it also focuses on what the service consumer can do (with specially tailored verbs that imply the service consumer as the subject).]
To my mind, aggregation services are low-hanging fruit for service-orientation. It's an obvious area where OO systems can't play. The attitude needs to become more pervasive, even for non-aggregation services.
To recollect our discussion about EJB, that's why Entity Beans require Service Façades, i.e., Session Beans that sit in front of them and change the focus from what the Entities can do to what the service consumer wants to do. Aggregation is one of the things that Session Beans do. It's the most obvious benefit, because making an interaction coarse-grained is more performant than having a highly chatty interaction with hundreds of Entities directly. But that's not the only benefit.
As I said before, REST is a great Service-Oriented solution even though it appears to be focused on entities just like Entity EJBs. The difference between REST and Entity EJBs (or between REST and OO for that matter) is that the focus is not on what the Resources can do, but on what the service consumer can do with those Resources. The four HTTP verbs of REST have the service consumer as the subject, not the resource. They are transitive verbs that have the resource as their object. You GET a Resource. You DELETE a Resource. Etc. It's easy for "you" to GET or DELETE a set of resources using the same idiom.
By contrast, OO systems have the "object" as the subject of the verb (if that doesn't confuse you), and the verbs tend to be intransitive (e.g., someObject.changeState()). (Where the verbs are transitive, another object (the "object" of the verb) is usually a parameter to the method verb, e.g., someObject.modify( anotherObject ).) It's not possible to extend an object's method to deal with a set of similar objects instead. That's because the focus is wrong from the start.
It's getting clearer in my mind now, but I realise the concept can take some getting used to. For now, a simple mantra to distinguish Service-Orientation from Object-Orientation:
Benefits, not features.
(I hope this doesn't spark off a new TLA fad - Benefit-Oriented Programming (BOP)). It's still just SOA, guys.
No comments:
Post a Comment