Service-Oriented Architecture - Guide to Cloud Computing for Business and Technology Managers - page 161

7.4.1.1 Objects
Objects have both state and behavior. The state is maintained through the
internal data, and the behavior of the object is defined through the public
operations on that data. A primary issue in these systems is the manage-
ment of object identifiers, which are global pointers to instances of objects.
It has been argued that architectures based on global pointers lead to brittle
systems if they scale to Internet size because of the proliferation of refer-
ences and the need to maintain the integrity of the pointers. As a result, these
systems are considered to be best suited to medium-sized networks within
a single domain, with known latencies and static addressing and intimate
knowledge of the middleware models used.
7.4.1.2 Services
A service is a view of some resource, usually a software asset. Implementation
detail is hidden behind the service interface. The interface has well-defined
boundaries, providing encapsulation of the resource behind it. Services com-
municate using messages. The structure of the message and the schema, or
form, of its contents are defined by the interface. Services are stateless. This
means all the information needed by a service to perform its function is con-
tained in the messages used to communicate with it.
The service abstraction shares commonalities with the object abstraction
but displays crucial differences:
• Like an object, a service can have an arbitrary interface.
• Like distributed object systems that use an IDL, services usually
describe this interface in a description language.
• Unlike objects, services use a message-oriented model for com-
munication. This has quite different semantics and implications
to invoking a procedure on a remote object. In the latter, what the
remote entity is plays a part. In the case of objects, the class of an
object must be known. Once this class is known, behavior based
on the class can be inferred by the consumer. Services, however, do
not share class. Instead, they share contracts and schema. Therefore,
what an entity is has no bearing on communication, and nothing
is inferred. Furthermore, communication with an object involves
addressing an instance. This is not the case with services as is dis-
cussed in the next item.
• Unlike objects, services do not have state. Object orientation teaches
us that data and the logic that acts on that data should be combined,
while service orientation suggests that these two things should be
separate. Therefore, a service acts upon state but does not expose
its own state. Put another way, services do not have instances. You
cannot create and destroy a service in the way you can to an object.