Originally posted by Mohit Sinha:
What should only remain a component and should not be confused to be made as a service.
It has more to do with the design approaches that are taken. As a result a well designed service could be converted to a component and you would still have well-designed component - the reverse is not necessarily true. Best practices for service design tend to apply to components as well, but given the environment that components are deployed in, component-designers take liberties that service-designers just shouldn't take. Just like it is possible to build an object-oriented solution in Ada, it is also possible to build a service-oriented solution with components - as long as service-oriented principles are adhered to and as long as you accept the "hard limitations" that your component technology imposes.
At this point you should notice that you are building a service-oriented solution in an object-oriented language (Java) which creates an impedance mismatch right from the start - there is no such thing as a "service-oriented" language. There doesn't need to be. Service-orientation focuses on the environment that the services exist in and how those services (through messages) interact - it doesn't care how the service logic is implemented.
So the differences between services and components can be observed in two areas:
Components tend to be finer-grained than services. Component clients tend to be more tightly coupled to their components than (ideally) service consumers are coupled to their service provider. Granularity:
Lets look at a pseudo service contract definition for a purchase order service (normalized):
Sidenote: If you are wondering why you need PoDelIdDoc and PoUpdDoc then you have to remember that document-oriented services don't have operations - the document type determines the operation - so the above could just as easily be:
Now we can denormalize the Purchase Order service and end up with:
This denormalized version exposes the finer-grained operations getItem, getHeader, updateItem, and updateHeader which in effect duplicate functionality that can be covered by the "get" and "update" operation. While there are sometimes reasons to allow this type of denormalization in a service, exposure of finer-grained functionality is usually a characteristic of a component. The interface is more detailed and there is more for the consumer to get coupled to. So a technical contract like the one represented by PoDenorm is more typical for a component while PoNorm is more typical for a service.
PoNorm creates "more work" for the consumer as it has to retrieve and navigate the entire PO to access a single line item. PoNorm creates potentially "more work" for the provider because it may have to on "update" compare the update values in the update document to the current values of the PO to determine the necessary cascade actions to make a consistent update to the underlying PO. For example, the component-style PoDenorm contract makes it easy to detect changes to the headers or items because they would happen through the updateHeader and updateItem operations; the service-style PoNorm contract has to detect these changes through inspection of the contents of PoUpdDoc (and possibly the current state of the PO). So the coarser grain interface of PoNorm may require more logic but also reduces the consumer's dependencies on finer-grained functionality and therefore its coupling.
Coupling:
Obviously components like Java EJBs and .NET Enterprise Services (COM+) exhibit Contract-to-Technology coupling as their technical contract is based on proprietary communications technology. Ideally services should be decoupled from vendor-specific technology as supported by the use of, for example, open XML and web service standards.
Components tend to exhibit Contract-to-Implementation coupling (the coupling of the service contract to its implementation environment). For example, platform specific types, structures, and idioms are exposed in the service contract (other than just basic types or custom types that are composed of basic types).
Components often can exhibit Contract-to-Logic coupling if their logic is designed before their contract (interface) is defined. Services can exhibit the same kind of coupling but
contract first development is supposed to avoid that. For both components and services this is simply an issue of "separation of concerns" - in this case the separation of the interface from the implementation.
Component design is often guided by object-oriented design principles which have some commonalities with service-oriented design principles. However there are also important differences.
Service-Orientation does not support the notion of service inheritance as this would reduce service autonomy. Because of the lack of inheritance, generalization and specialization actually refer to a different characteristic under service-orientation. Coarser grained (more generalized) services can sometimes be decomposed into finer grained (more specialized) services. Because of the lack of inheritance, polymorphism isn't supported by services. There can't be an "Abstract" service. The closest parallel to polymorphism are identically named capabilities across numerous services, e.g. consistent use of standardized verb-based, CRUD-style operations within entity services. "Composition" in service-orientation doesn't imply an ownership structure between services like it would in object orientation. One service cannot own another. "Aggregation" ("has-a") doesn't even apply. One service can merely "use" another Services need to remain stateless and delegate management of state. So all of the above is supposed to build a case for "Services are (ideally) coarser-grained and more loosely-coupled than Components" and that their differences lie mainly in the differing manner in which components and services are (supposed to be) designed.
I believe you are referring to REST here. Is there anything that has caught your attention and provides a more efficient/easier way of doing things than in SOAP/WS* world.
Well, (POX) XML-over-HTTP and JSON-over-HTTP have their place too. What makes RESTful web services so interesting is that they are a better match for services on "the web". The majority of services are "entity services" anyway which tend to have a READ,UPDATE,DELETE interface which matches the HTTP verbs GET, PUT, and DELETE - this is the reason why RESTful web services have been seen as an ideal implementation for "data services" (though more can be done with them once you can wrap your head around it). In such a case RESTful web services can be more "effective" but that doesn't necessarily mean that they are an "easier or more efficient way of doing things" from the development perspective. It's often "easier" to use the code generators that are part of the WS-* based development environments - but that doesn't make it the "correct" approach.
And furthermore, just like there is an impedance mismatch between object-orientation and service-orientation, there is also an impedance mismatch between object-orientation and resource-orientation. You will still have to re-think how to approach the design of a resource-based web service.
Transitioning From Object-Oriented to Resource-Oriented Programming is a bit extreme, but it makes a point.
[ December 22, 2008: Message edited by: Peer Reynders ]