Service Orientation vs Object Orientation

Well, this debate may sound like an old debate but as Service Oriented Architecture starts spreading its wing, it might be important to underline some of the differences. There is going to be a lot of tool based service development kits, but one day someone will likely realize how cool it would be to develop services like we write objects today.

We all know the fundamentals and benefits of OO: encapsulation, inheritance, polymorphism, containment... overtime we had to tweak OO a bit and add concepts like "interfaces", but at the end of the day, OO is still about encapsulating a data structure and associating to it a bunch of code that, in general, is about changing its content/state. A typical OO run-time is in charge of managing the lifecycle of object instances. I know this is a bit trivial, but where are the differences with services?

Of course in services, the data structure(s) are not internal to the service but simply the arguments of the service operations. Note that Service Orientation has not yet recognized officially the need to carve "entities" within these schema. Services are not about explicit data encapsulation but rather "process" encapsulation (ok, most of us have also encapsulated processes within objects). The operations of a service are the interaction points with that particular process.

The most fundamental difference I see is that in OO what is explicit is the methods you can call on the object. The "callbacks" (though I hate this term forcefully) are not explicit. A typical class has no way to express that it requires an (UML) aggregate to work and that it needs this aggregate to implement a specific interface. There are of course more than a few other differences (like the fact that a service has invocation instances but not multiple instances of a service...), but let's push the reasoning on this last argument:

There has been several attempts to extend existing OO languages in the SO world but most of the attempts have focused on working with the concepts of class or interface rather than create a new kind of run-time entities: services.

Here is what a service description could look like:

using org.oag.*;

public service MyOrderEntryService : extends thisOAGService

//could also have something like private[myDomain.com] service ...

{

     friends:  //Roles that interact with service, including their inbound

               //service interfaces

               //This is a way to define the MyOrderEntryService outbound operations

           anonymous buyer;                                          //can be anyone calling

           public dynamic ShippingService shipper[${order}//Shipper] //specified by the buyer

           {                                                         //in the order document

               tellShippingWhatToDo(schema_uri_3 shipping_order) receives cannotShipFault();

           }

           public static BillingService billing                      //Specified by policy

           {

               tellBillingWhatToDo(schema_uri_4 order) receives badCreditFault();

           }

     operations:  //Inbound operations

           buyer>processOrder(schema_uri_1 order) throws OrderRejectedFault();

           billing>synchInvoice(schema_uri_2 invoice) throws InvalidOrderFault();

 

     

     process: //A service run-time could validate the sequence of operation invocation

              //with this information

           + start;

           + buyer.processOrder();

           + gateway(And-fork);

             > this.tellShipperWhatToDo(); <

             > this.tellBillingWhatToDo(); <

           + gateway(And-join);

           + billing.synchInvoice();

           + end;

      

}

Could be just the symptoms of XML fatigue, but after 5 years of evolution countless standards committees, I find quite staggering that Web Services are still where they are today:

• cornered to be inbound "mostly",
• no "behavior" description despite all the BPEL in the world (maybe this is too abstract for this committee),
• no complex units of work involving multiple cooperating web services,
• no real attempt to bring OO and SO programming models and run-time together except a few stitches at a time.

If I can create processes with OO programming languages, I don't see why I could not have a unified programming and run-time environment.