Just finished reviewing Thomas Erl's upcoming book SOA with REST

Hi all,

I just finished reviewing the upcoming book SOA with REST, written by Thomas Erl et al.

For more information about this no-nonsense book, see the SOA with REST infopages.

- Roger

Now official trainer for the Service technology Symposium

Now I am also official trainer for the Service Technology Symposium, for training partner Rhea Solutions Ltd.

For the training program see the training web site.

I am conducting the pre-symposium Certified SOA Architect Workshop. Also see the Symposium's Workshops Guide.

Now official speaker at the Service Technology Symposium

Hi all, now I am

For more details see: the official Service Technology Symposium web site, and the presentation abstract and speaker profile for "Conway's Law and Service Orientation".

- Roger

Published the Centralized Event Consumer candidate pattern

Hi all,

I just published the Centralized Event Consumer SOA Pattern. The pattern increases autonomy of underlying resources in large event architectures, thereby increasing the event consumer autonomy.

You can view the pattern by following the link.

I would like to ask everyone to review & give feedback on the soapatterns.org website. Also in case you have used the pattern yourself successfully, please testify this at soapatterns.org using the feedback form, so the pattern candidate might be qualified as a real pattern.

- Roger

Published an article in Service Technology Magazine

Hi all,

I just published an article in Service Technology Magazine - the January 2012 edition.

For those of you who read my blog it might be familiar text as I took one of my posts as basis for the published article. For those of you who want to check it out you can see it here.

- Roger

Coupling processes loose - a mess if not done right

Another great example how processes can sometimes be coupled in such a way that you can create a mess for the people in the process (tight coupling):

As posted in my previous post, I am using a chip-card for the Dutch Public Transport. This card acts as a travel pass and allows loading products onto it which act as tickets for public transport. More information can be found here.

One of the ways for travelling with the card is by loading credit products onto the card which act as a virtual wallet. You can do this manually, or you can load a product onto it which behaves in such a way that if your credit on the card drops below a certain threshold, it automatically does a debit transaction on your bank account and recharges the travel card. For this to work you need to purchase the product online and link it to the bank account of your choice.

I had almost activated the product on my card until I noticed the following phrase in the description of the product: "Always make sure sufficient money is in your bank account. If we cannot obtain the money from your account the card will be blocked. Unblocking the card can be done at a service desk."

Now here's the problem: two processes exist which are mixed incorrectly here:
- travel authorization
- debit transactions

Specifically the scenario when travelling with insufficient credit on the card and a low bank account balance causes issues: why would anyone want to block the entire travel card if I had insufficient balance?

There are a number of reasons why this is wrong and additionally there is one specific reason why this is fundamentally wrong:

- Travelling is registered/credit is consumed by checking in and out of the travel registration system by keeping the card close to a registration point (the card uses near-field-communication to communicate with the travel management system

- Insufficient credit for this travel does not mean that there is insufficient credit for all travel. It should be sufficient to deny check-in for this travel only.
- Insufficient bank balance still allows me to recharge the card from another bank account - so why block the entire card?

Fundamentally wrong:
- Many train stations and most bus stations do not have a service desk. To get to one I would need to travel!? Blocking the card does effectively restrict me from getting to a service desk.

What is documented here is an unnecessarily tight coupling between two distinctly different processes with distinctly different purposes. A better solution would have been to check at every check-in time anew whether or not I had to recharge the card. If the bank account balance was insufficient I would be denied that particular check-in.

Needless to say I did not activate that auto-recharge-card-credit-product on my card. You never know what happens and I do not intend to get stuck in the middle of nowhere just because an architect made a mistake (imho) by tightly coupling two disparate processes and by doing so shuts me down completely (travel-wise).

Wonder how long this situation will exist now that the government and the transportation companies are trying to get rid of the paper travel tickets...

- Roger

Transportation service compared to SOA service (over)specialization

Sometimes service over-specialization can truly hinder reuse in a sense that multiple implementations of similar logic are necessary to achieve the same functional goal for another purpose (agnostic).

I live in the Netherlands where recently an electronic public transportation ticket system was introduced to manage travel tickets electronically. A chip card with NFC is used to 'carry' digital tickets while travelling. You could see the travel pass as a digital purse in which you can keep single/return trips, monthly and yearly subscriptions as well as some money to use while travelling.

Now I'm new to this system and finally I decided to try the 'ticket recharged' way of travelling: the public transportation chip card instead of a paper ticket.

In order to be able to travel, I need to meet a number of preconditions:

1. I need a (personalized) travel card - this is the actual chip card with NFC communications

2. I need to put money on it

3. I need to activate "travel" on it with the appropriate transportation company.

Ad 1): I already had the card a little while, so I did not need to worry about it: precondition 1 is met.

Ad 2): For charging the card with money intended for travelling, a two-step approach must be followed:

a. Purchase travel credit - this would perform a direct debit on my bank account

b. Load the credit product onto the card

Ad 3): Similar two-step approach:

a. Order the "travel by virtual travel money" product with the dutch railway company

b. Load the product onto the card that allows using the credit on the card if available

Step 2a can be done via the public transportation chip card web site

Step 3a can be done via the dutch railways web site

So now I needed to find an NFC charging point so I found one of the terminals for public transportation at the train station.

Now here's the problem:

The machine to load products onto the card would only allow me to find the pending product for step 3a. This  means I can load the product to spend the virtual money with, but I cannot find the product that represents the virtual money I had ordered to spend in the first place.........?

So the "Load product" service on the terminal was only able to load travel products but no credit products. What was wrong with building a load "product"???

I ended up finding another machine outside the railway station to load the money product onto the chip card...

So I had to load products in two physically separate (and distant!) places...

Typical example of a non-agnostic service... :(

Published the Context Normalization Standardization pattern candidate

Hi all,

I just posted the pattern candidate for (Process) context normalization standardization.

If you have done this before and agree this is a good approach to solve cross-company process and technology alignment, please testify on the soapatterns.org web site using the candidate pattern feedback form.

Thanks,

Roger

Agnostic/non-agnostic revisited

I got the feedback that the previous article I wrote on what agnostic/non-agnostic is was too complex. So I am revisiting the subject to make sure that I explain a lot simpler than in the post I described last year.

To explain as easily as possible what agnostic/non-agnostic is:

• agnostic services are not aware of the context in which they are being called, nor are they aware of how the service is implemented, which platform, technology etc.
• non-agnostic services can have one or more forms of coupling or context (ie. process functional context).

Result of these two statements is that agnostic services have more reuse potential than non-agnostic services.

An example of the difference can be identified by discussing a "PrintInvoice" service capability.

This is a service capability which can be described as the logic exposed to print an invoice. When trying to classify the service it is pretty obvious that this is a non-agnostic service, as it has capabilities to print invoices and nothing else.

When applying the principles of service design, we should give a service a defined logical (functional) boundary, which defines the context in which the service operates.

When redesigning the implementation of this service, we could split the service into two services:

• Print
• Invoice

These are two agnostic services: print service capabilities are bothered with the capability to print "stuff" and Invoice service capabilities deal with invoice related "stuff".

Having made this separation, I just lost my capability to print invoices. To resolve this problem I can create a third service which combines the two services in one service capability which can deal with the mechanics of printing invoices, which results in the following service-inventory:

As you can see the agnostic services are being composed by the non-agnostic PrintInvoice service. This allows for the invoice and the print service to be used for other purposes, of which I have depicted a few potential examples below:

As we can see, it's the agnostic services which are being reused, not the non-agnostic services.

If this separation of concerns would not have been applied, instead of ie. reusing the print functionality, for the printletter functionality, the printing part would have been redeveloped and tailored for the printing of letters. This would have created some unnecessary/redundant/duplicate logic.

The current PrintService would take any range of different document types that it would support. This would greatly enhance the reusability of the agnostic print service.

Published Rule Layers candidate pattern

Hi all,

I just published the Rule Layers candidate pattern. I'm looking for people to testify that they have applied this pattern to get it promoted from the candidate to the pattern status. Check it out here at soapatterns.org.

- Roger