Back to Article List

Originally published February 2007 [ Publisher Link ]

SCA and SDO for PHP

Led by the Open Service Oriented Architecture collaboration group ( OSOA ), Service Component Architecture (SCA) and Service Data Objects (SDO) have become the newest approaches for enabling service-oriented architectures. Initially conceived to operate in the most widely used programming environments for the enterprise -- Java and C++ -- both SCA and SDO have grown to accommodate additional platforms, in the following article we will explore how the popular scripting language PHP has embraced these same SOA techniques.

Lets start by taking a look at what SDO can offer you. In a typical PHP application, data will more than likely come from a relational database, but what happens if this same application later requires accessing information not only from this source, but also from a flat file or Web service? Well, it will be a long process at best or a convoluted task at worst, the reason being is that each data source comes with its own set of quirks for retrieving appropriately.

In this sense, SDO for PHP achieves the touted transparency inherent to SOA when dealing with application data sources. Instead of working with each type of data source individually, SDO offers a unified manner in which to access data objects. The way this process is achieved is through Data Access Service's (DAS), a level of indirection built into the SDO architecture. Take a look at the following listing which illustrates an SDO query in PHP:

<?php
  $providers = $company->shippingByGround;
  foreach ($providers as $name => $value) {
     echo "$name: $value\n";
  }
?>

Notice how this last query has the characteristic of being data source agnostic. That is to say, you can't tell were the underlying data is being extracted from, you simply make a search using PHP's SDO syntax and the intricate details are dealt with in the DAS, of which PHP currently supports both XML and relational database sources.

While SDO is focused on data, SCA's intent is on achieving this same transparency, but with more general purpose classes or components. In what would be another typical PHP scenario, accessing existing business logic from any PHP class forces a developer to wrap a design around a particular series of assumptions: Is the logic in another local PHP class? Or is it located across the network? Is it even written in PHP?

While each of the aforementioned scenarios is resolvable in its own right, each one requires different coding techniques.

Using SCA's approach, the location in which such logic is located -- across the network or locally -- should be a moot point, not to mention the implementing language -- PHP, Java or C++ -- would also be irrelevant. This last statement may lead you to ask "Hey, this sounds a lot like a run-of-the-mill Web service, what's the difference ?" Well take a look at listing 1.2 which contains a PHP SCA component.

<?php

include "SCA/SCA.php";

/**
 * Calculate a shipment price for a given customer 
 *  using a specific provider
 *
 * @service
 */
class ShipmentQuote {

    /**
     * The customer discount fee service to use.
     *
     * @reference
     * @binding.php ../DiscountFeeRate/DiscountFeeRate.php
     */
    public $discountFee;

    /**
     * The shipping service to use.
     *
     * @reference
     * @binding.wsdl ../Shipper/ShipperQuote.wsdl
     */
    public $shipper;

    /**
     * Get a quote for a given customer using a specific 
     * provider
     *
     * @param string $shipping The shipping company 
     * @param string $customer The customer requiring 
     * shipment, in order to obtain discount rate
     * @return float The quote for a given customer using 
     * a certain shipping provider. 
     */
    function getQuote($shippingCo, $customer)
    {

$rateShip  = $this->shipper->getShippingPrice($shippingCo);
$rate   = $this->discountFee->getDiscountRate($customer);
        return  $rate * $rateShip;
    }
}
?>

The most important declarations in the previous listing are those made in @ statements, since each one provides specific SCA behaviors. Topping things off is the @service tag, which is charged with exposing the class in question as a service. In this particular case, the last function by the name of getQuote will be the only operation exposed through the service, something which is achieved using the @param and @return annotations.

The actual execution or deployment of this last service -- which is delegated to a PHP SCA runtime -- will net us an access point capable of producing a WSDL contract, just like you would expect of any Web service. Besides the simplicity in deploying a service in this manner , the real advantage to SCA's model becomes more evident when you inspect the getQuote function code.

Notice the two statements $this-<shipper->getShippingPrice($shippingCo) and $this->discountFee->getDiscountRate($customer), which are based on the earlier references in the class. Each of these references are backed by other underlying services -- thanks to SCA's @reference and @binding annotations -- in the case of $discountFee this would a PHP class and in shipper's case this would be a standard WSDL backed service.

As you can realize, much of the power behind SCA's programming model is the ease with which you can create chained calling sequences of services without tainting the actual business logic, a conclusion you can also probably arrive at by simply removing all the SCA annotations we just described. If you do so, you will be left with plain business logic with no other type of dependencies, a characteristic which is highly beneficial to not only developing services for SOA, but also software in general.

Though PHP's simplicity and ample user community have made it a favorite for building Web applications, until recently, its usage in the enterprise was limited to a handful of scenarios, but with SCA and SDO now supported in PHP and the former technologies appearing on the radar of organizations trying to implement a SOA, honing your PHP skill set may prove to be wise choice, especially now that it will be able to participate on the same service-oriented playing field as the other major enterprise languages.

Originally published February 2007 [ Publisher Link ]

Back to Article List