SpeakingOctober 28 - 30 - Presenting two sessions on OSGi.
EventsMay 6 - 9 - Attending JavaOne in San Francisco.
The opinions expressed on this site are my own, and not necessarily those of my employer.
A class defines the variables and methods available to it’s specific instances. A class serves as the blueprint for an object. An object is an instance of a class with state. In Java, a class is a .class file
A component is a unit of deployment. A component contains classes. Components are invoked in-process (locally). Components are not instantiable. Components are stateless. Component interactions are synchronous. In Java, a component is a .jar file.
A service is a software system. Services are distributed, may execute in different processing environments, communicate over a network, and are invoked remotely. A service is not instantiable. Services are stateless. Service interactions are synchronous or asynchronous. A service contains components. In Java, a service is an .ear file with the appropriate deployment descriptor.
Agree or Disagree? I’m interested in your thoughts on this subject…
5 Responses to “Class, Component, Service”
Leave a Reply
Recently Written
Categories
Archives
Powered by WordPress.
What is the context for these definitions? Are they intended to be the building block for a larger system, or are they intended to be a universal set of categories?
What’s the rational for services being stateless? A “user service” would, then, always have the same collection of immutable users?
The context is strictly technical. When developers communicate, they often use these terms quite loosely. “I wrote a component that does that” and “That should be a service” are two general examples. But I wonder if the terms conjure similar images in the minds of different developers who hear the statements. I’m looking for something tangible, such that when the term “component” is used, developers form an immediate opinion on it’s general characteristics, such as those surrounding deployment.
The definition for “service” is of the SOA flavor (ie. web service, session bean, messaging, etc.). Should a service be stateful or stateless, and is it important to know when talking about “services” if the service in question is stateful or stateless? Or is knowing that unimportant?
Class, Component, Service…
From a post…
It is difficult for me to separate a ‘component’ from a ’service’ when pulling definitions from both SOA and component architecture.
Class and object seem straight forward but component and service seems to be changing. Instantiation differentiates what I consider a service or component. Now, granularity is another item that seems to seep in when comparing. Distribution would also be a big hint that it was a service, though not a guarantee.
Component seems to be the most difficult (for me anyway). It seems to blur and morph relative to the work I’m doing. With the component frameworks integrating with backed beans, my first thought triggered from “component” included stateful/stateless, which isn’t the statelessness I’d say if I was thinking only of java.
sauter’s blog…
sauter’s blog…