Is Service Oriented Programming (SOP) Just Another Name of Object Oriented Programming (OOP) ?

6:12 PM Unknown 1 Comments

Object-oriented programming (OOP) is a programming paradigm that represents concepts as "objects" that have data fields (attributes that describe the object) and associated procedures known as methods. Objects, which are usually instances of classes, are used to interact with one another to design applications and computer programs.

An object-oriented program may be viewed as a collection of interacting objects, as opposed to the conventional model, in which a program is seen as a list of tasks (subroutines) to perform. In OOP, each object is capable of receiving messages, processing data, and sending messages to other objects. Each object can be viewed as an independent "machine" with a distinct role or responsibility. Actions (or "methods") on these objects are closely associated with the object. For example, OOP data structures tend to "carry their own operators around with them" (or at least "inherit" them from a similar object or class)—except when they must be serialized.

Objects can be thought of as encapsulating their data within a set of functions designed to ensure that the data are used appropriately, and to assist in that use. The object's methods typically include checks and safeguards specific to the data types the object contains. An object can also offer simple-to-use, standardized methods for performing particular operations on its data, while concealing the specifics of how those tasks are accomplished. In this way alterations can be made to the internal structure or methods of an object without requiring that the rest of the program be modified. This approach can also be used to offer standardized methods across different types of objects. As an example, several different types of objects might offer print methods. Each type of object might implement that print method in a different way, reflecting the different kinds of data each contains, but all the different print methods might be called in the same standardized manner from elsewhere in the program. These features become especially useful when more than one programmer is contributing code to a project or when the goal is to reuse code between projects.

Service-oriented programming (SOP) is a programming paradigm that uses "services" as the unit of computer work, to design and implement integrated business applications and mission critical software programs. Services can represent steps of business processes and thus one of the main applications of this paradigm is the cost-effective delivery of standalone or composite business applications that can "integrate from the inside-out"

SOP concepts provide a robust base for a semantic approach to programming integration and application logic. There are three significant benefits to this approach:

• Semantically, it can raise the level of abstraction for creating composite business applications and thus significantly increase responsiveness to change (i.e. business agility)
• Gives rise to the unification of integration and software component development techniques under a single concept and thus significantly reduces the complexity of integration. This unified approach enables "inside-out integration" without the need to replicate data, therefore, significantly reducing the cost and complexity of the overall solution
• Automate multi-threading and virtualization of applications at the granular (unit-of-work) level.

Having said all this, let us compare the two approaches now:

OOP is a fine way to create applications that perform specific tasks. However, it is a terrible architecture for creating robust network applications. Every OOP-based architecture for distributed applications (using CORBA, DCOM, or EJB) has failed to deliver on its promises... and made network programming vastly more difficult than it needed to be.

A service-oriented approach, on the other hand, gives the developers and architects an easy way to integrate systems. They are far less complex, faster, more robust, more scalable, more easily maintained, and they are much easier to for designers to conceptualize.

Does this mean an end to OOP? No. We still need OOP -- or at least significant chunks of it -- to create these systems. However, we should stay as far away from OOP as possible when creating interfaces to distributed applications.

May be providing a simple illustration on how service-oriented programming appaoach works is best here: in simple terms service-oriented programming is like the following two points.

write programs that are designed to run as services. 

1. For example, most databases run as a service on a server. It listens for connections, and then listens for requests and provides responses to those requests
2. Design those programs to establish connections with each other, and use message passing as the key to performing work. For example, you might have the MySQL service running, and the Apache service running. A request is sent to the Apache service from over the internet. It, in turn, connects to the MySQL service (via a PHP script) and sends a sequence of messages. The result of processing those messages is then sent back to the requestor as an HTML page. 

Source:

http://en.wikipedia.org/wiki/Object-oriented_programming

http://en.wikipedia.org/wiki/Service-oriented_programming

http://bexhuff.com/so-vs-oop and some pdf books I have.

If you want to read more about it, I am happy to share my books. Till the next topic, later!