Tools have enabled us to take our objects, and automatically build code to wrap them as components and services. But "how do we know which is right for the job?". Roger Sessions the topic, giving us fair warning about the issues.
He warns: "The compiler vendors have given us the power of transformation, but no instruction as to when and how to use this power."
He goes on to provide the classic recipe for when each of these three forms of encapsulation should and shouldn't be used:
"When we are not constrained by needing multiple environments, components are more efficient than Web services. When we are not constrained by needing multiple processes, objects are more efficient than either components or Web services. Web services are the least efficient of all of these systems, unless we are working under constraints that prohibit the use of either objects or components."
Read more: Fuzzy Boundaries: Objects, Components, and Web Services
- Fuzzy Boundaries: Objects, Components, and Web Services by Dilip Ranganathan on February 02 2005 11:41 EST
- Fuzzy Boundaries: Objects, Components, and Web Services by han theman on February 02 2005 12:53 EST
- Additional Information would be nice by M J on February 02 2005 13:18 EST
- it is not "how", it is "what" by Max Shuleman on February 02 2005 13:28 EST
- Fuzzy Boundaries: Objects, Components, and Web Services by hacking bear on February 03 2005 01:44 EST
- These purely technical distinctions are not the point by Alexander Jerusalem on February 03 2005 05:38 EST
- Good Article, Even Oversimplified by Mike Dunbar on February 03 2005 13:23 EST
- Fuzzy Boundaries: Objects, Components, and Web Services by javier castanon on February 03 2005 22:52 EST
Making a distinction between object, component, service based on run-time environment doesn't make much sense. I agree, it's hard to define what exactly makes up a component. However, one can at most say that such definition makes it more _probable_ for a certain entity to be run-time deployed in a certain way.
So, the article, at most, describes a likely run-time consequence of the actual definition (which is lacking).
Proposal: ban the words Component and Web Service altogether. No wait, marketing wouldn't like that.
Making a distinction between object, component, service based on run-time environment doesn't make much sense. I agree, it's hard to define what exactly makes up a component.
Each emerged in a different decade, so it's an evolutionary ladder.
The boundary is a bit blurry. A stateless session EJB can be deployed as both a component and a web service.
Stranger still with Apache Axis, all of the hosted web services share a single component instance, the multi-threaded Axis servlet. This suggests a service is a logic concept, relying on a shared component instance.
I pretty much dropped the word "component" out of my vocabulary five years ago and have never looked back.
It'd be nice to see measurements on just how much faster objects are than components and components are than web services.
Also no discussion was made of alternatives, such as sending data over TCP, UDP , or a messaging system such as MQ.
I don't think it is appropriate to simply differentiate objects, components and Web Services by their location and environment.
Not every object would make a good Service. Two characteristics come to mind: it must be coarsely-grained because you do not want to incure network penalty just to bring a simple "woof" across, the entire dog house should go ;-). Secondly, the arguments of a service call must be as simple as possible, preferrably just the simple types, to minimize compatability and complexity issues related to packing and unpacking of the whole object graph.
it is also interesting how he says: "WebShere" where other people would have said: "J2EE".
Not every object would make a good Service.
Perhaps the most desirable service feature is shareability, hopefully as a singleton. Eg, java.lang.Math is a class that would make an excellent service since its just a bunch of static methods, effectively a singleton. A value class (eg, java.awt.Point) can't be a web service. There's too great an impedance mismatch between WSDL and instance state. Unlike a component (such as an EJB), a web service can't be instatiated on demand. The obscure WS-Resource has a methodology for mapping transient service instances to WSDL locations. Perhaps another WS-* standard supports service instancing? Maybe WS-Addressing or WS-Discovery does?
The primary task of this industry is to create more and more fuzzy, unclear, confusing terminolgies that sound great!
Can you count how many words are there for "data structure" and "function"?
Our living depends on creating these words that look new and better, rather than telling people why the terminologies are not much different from the old one.
This author certainly did disservice to all of us, but luckily we can be sure he wouldn't do much damage anyway.
I think he misses the point because he focuses exclusively on technical matters. The question that should be asked is an organisational one: Do I have central coordination between the teams that build various parts of the systems involved? If I don't have very close coordination, it doesn't matter if the two sides of a communication channel happen to run in the same environment (Java, .NET, etc) or not. Because my main problem in such a situation will always be versioning.
How can I independently evolve the service interfaces on either side? How can I make a more recent receiver understand requests from an older sender and vice versa? That is, how do I achieve backward and forward compatibility? In Java (or .NET for that matter), versioning the wire representation of objects is hard. Sending Java objects back and forth between systems that are not built on the exact same class versions is a recipe for disaster. XML messages, on the other hand, are versionable (if you know how to do it right). So my view is that webservices are a good choice for uncoupling development processes, no matter what the technical environment may be.
True enough, it doesn't discuss every issue involved, and I feel that "component" got blurred with "distributed component". Nonetheless, I agree with the main points/suggested architectural layering.
I like to see components as deployment artifacts, implemented by object oriented or procedural languages, and some of them providing a service. Also, I don't think the classification holds on some scenarios, like when using a component in the form of a JAR in a Java application, where no always will be interprocess communication.