Archive for the ‘Separation of Concerns’ Category

RESTifying Procurement – Sourcing Part 1

Thursday, February 4th, 2010

Sourcing refers to the procurement process where one party role (the provider) provides another party role (the receiver) with a catalogue. A catalogue is a document that describes items and prices.

The first thing to do is to differentiate server side role and client side role to achieve clean separation of concerns. A good hint for identifying the server side role is where the application data is located. In the case of sourcing, the party that plays the provider role owns the item data that is used to create the catalogues. Therefore it is straight-forward to implement the provider role as a service and make the receiver role a client.

As I learned today, UBL does not specify the actual procurement processes but merely provides the set of business documents to choose from when designing your own processes. This is nice, because it mens that UBL can be suitably applied even in the context of this little experiment.

As a first step, the provider role service will just provide a public catalogue, let’s say at http://labs.nordsc.com/procurement/roles/provider/common-catalogue.

Assuming the receiver role client discovered that URL from the service document describing the provider service the following HTTP interaction could take place for catalogue provisioning:

GET /procurement/roles/provider/common-catalogue
Host: labs.nordsc.com
Accept: application/vnd.nordsc.procurement+xml
 
200 Ok
Content-Type: application/vnd.nordsc.procurement+xml
Cache-Control: public,must-revalidate
ETag: 1
 
<?xml version="1.0"?>
<Catalogue xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
    xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
    xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2"
 ">
    <cbc:ID>public-001</cbc:ID>
    <cbc:IssueDate>2010-02-02</cbc:IssueDate>
    <cac:CatalogueLine>
        <cbc:ID>ID0</cbc:ID>
        <cac:Item/>
    </cac:CatalogueLine>
</Catalogue>

The catalogue representation is only a stub at the moment, we’ll get to the media type issues later. Of particular interest is the caching policy for catalogues because the intention is for clients to use the latest catalogue data when placing an order. Catalogues can be potentially very large and we want them to be cached by public and private caches (Cache-Control: public) . However, since the freshness of the catalogue is very important, caches are instructed to never return a cached copy without prior revalidation (Cache-Control: must-revalidate).

Apart from the issue of the media type for the catalogue, we have now designed the most simple version of catalogue provisioning. It will be interesting to explore how other sourcing interactions (for example customer initiated sourcing) can later on be added.

Posted in RESTifying Procurement, Separation of Concerns | No Comments »

Separation of Concerns and Replication

Friday, November 27th, 2009

In an integration scenario that involves the replication of items from one system (the master) to another (the slave) the direction of the communication is an interesting issue.

First, there is the question, whether the initial creation of a replicated item in the slave should be performed by a request from the master to the slave or by a request from the slave to the master. The former will often be chosen when there is a business rule involved that should trigger the replication (e.g. replicate all employees in the slave system whose contract ends in 6 months). The latter is more likely to be used in a scenario where the slave replicates all new items in the master, in other words, where the slave keeps the overall set of items in sync.

Second there is the question how updates of the items in the master are made available in the slave. This is the classic distinction between polling and publish/subscribe: Should the master notify the client of updates or should the slave poll for updates?

In addition, there is sometimes a desire to notify the master about changes the slave makes to the replicated items. The intention of this scenario is not the bidirectional synchronization of master and slave but reflects the master’s interest in any changes the slave makes.

What is the guiding principle to make an informed design decision regarding the direction of communication in such a replication scenario? The answer is separation of concerns with the goal of simplicity and avoiding unnecessary coupling. This leads to the question which of the systems should for which communication play the server role and which one should play the client role?

Every communication is initiated to achieve some goal and the correct separation of concerns puts the component that acts to achieve the goal into the client role and the other component into the server role.

Applied to the above scenarios this means that for initial replication and subsequent updates the slave system should act as a client and the master should act as a server. All the necessary resources to be provided by the sever (e.g. providing list of all items that match a business rule) can be derived.

Applied to the scenario where the master is interested in updates from the slave it means that the master should act as the client because it is the master that has the goal (the slave does not care at all). This leads to certain resources that need to be exposed by the slave.

I have seen at least three production systems that had this issue and all of them did it wrong and would have greatly benefited in terms of simplicity and loose coupling from following the above principled design path.

Related is Roy’s post Paper tigers and hidden dragons.

Posted in Separation of Concerns | No Comments »