Service / Object Orientation
Object Orientation has been around for decades and has been used as the main standard in the software development industry. Service Orientation on the other hand, has been attracting a lot of attention lately, particularly along with popularity of the Internet as an integration platform.
Both terms are in the area of "Software Architecture", and imply an "Approach" to design and development. So understandably, many developers and IT managers consider them as "Competitor" methods, of which you should choose one or the other. Some think that SOA is a new approach that will replace, or is replacing Object Orientation. Although in certain scenarios they can be seen as alternative to each other, in majority of the scenarios there is only one [obvious] choice between the two.
The goal of SOA (Service Oriented Architecture) is to achieve loose coupling among interacting software agents. It defines the standards and contracts to allow different applications to exchange data and participate in business processes. It is intended for interoperability between different systems and its implementation is platform neutral. It is stateless, message based and usually not part of a physical transaction (at least actively). It is about minimizing change cascades between multiple companies and business partners. A service is a stand-alone unit with a [fixed] address. A service is the world-facing part of an application.
Object Orientation however, is all about the internals of a single application. Its implementation is platform-specific. It suggests encapsulation of data and procedures into more natural "objects". It defines a world of interacting active objects inside the same running application. It is about abstraction through modularity, contracts, states and messages. An object-oriented program is described by the interaction of objects, actively working together to do the "job".
Object Orientation is about internals of a system, while Service Orientation is about external communication. OO is concerned about flexibility and abstraction, while SOA's concern is compliance with standards, simplicity and protocols.
It is possible to use OO notions for designing for integration, where in fact SOA styles should be used. Technologies for remote state simulation such as DCOM and .NET Remoting enable that, and this can create a point of confusion. Apart from that, SOA is not a replacement for Object Orientation in general. OO still remains the best option for designing internals of applications and components.
Links: