Overview about the 5th SOA, Cloud and Service Technology Symposium

26Sep

Last 2 days I’ve visited the 5th international SOA, Cloud & Service Technology Symposium in London. It’s a yearly event that features experts and authors from all around the globe. I just landed back in the Netherlands and since I can’t claim a jetlag I forced myself to make this blogpost before the next event is already starting (yeah I know, my life sucks).

Big disappointment for this years conference was the fact that well known SOA & Cloud author Thomas Erl could not make it due to family illness. It was my 1st symposium so I was really hoping to finally meet the big man himself. The days where packed with sessions in multiple tracks so it was impossible to see al interesting ones. Some sessions where even so popular that you couldn’t enter the room properly (example: Your Security Guy Knows Nothing by Paco Hope, but what would you expect which such an epic title ?)

To much to tell, but a small overview I made below of the 3 sessions I found the most interesting during this event. I think the presentations will be made available very soon as well.

Rob(ert) has 20 years’ experience designing and implementing IT solutions and this was noticable due to his great amount of experience. He is also author of the Service Design Patterns book (by now on my wishlist) as he admitted himself was a shameless plug to sell more books ;-)

Anyway. Robert session explained the attemps to design the perfect API, one that would never change. However this will never happen since both clients and servers evolve in different rates. So in the end, developers must always accommodate new requirements and coordinate deployments to prevent breaking stuff. This is not freedom he mentions.

The common cause for breaking changes:

data types (string becomes integer)

renaming

optional vs required

hierarchial relationship

sequencing (xml), of which Robert is not a big fan.

If you look at the bulletpoints only 1 conclusion: A lot of data modeling issues.

Robert takes 1 API (RPC) and explains coupling by an example (SOAP/WSDL). Client used procedure name (operation) and arguments (xsd) to contact server. This is “crazy high coupling”. When change needed: change service, create new wsdl, generate new client proxy, etc. As Robert states: fun fun fun! ;-)

So 2 options there:

Backward compatibility: this is most often used to serve older service consumers with the older version of the message. Becomes a big problem with lots of consumers.

Forward compatibility: service is able to process newer messages they don’t really understand. Clients that have moved ahead of the service. Typically occurs when message defined by external groups.. Problem with validating / transformation.

Open standards now-a-days prevent vendor locking, but you will always have coupling. This you can not eliminate it. So while managing to prevent breaking changes, your talking governance. But as we all know, this is easier said then done.

As Robert states we need a tolerant reader:

lax or no schema validation over data binding

favor surgical data extraction: xpath, jquery selectors

enable unknown content to be forwarded

be conservative with exceptions

And relaxed message structure:

favor optional items over required items

avoid strict sequences

My personal remark: I understand that this could be helpful with read-services, but for write services you would need more requirements regarding valid data being send to your backend systems. So I would assume write services should have less relaxed message structures then read services could use.

So Robert summarizes, the problem of Web APIs

may be used by multiple clients, so impact high (1-n) when changes needed

documentation becomes dated (JvZ: as seems to be the case in general)

architect need to think ahead about client future needs

Consumer Driven Contracts (patterns)

service consumer developer writes integration tests that express their expectations

Belgium Integration Architect Ignaz Wanders talks us through his experience with service versioning in a SOA landscape. An issue I often ran into myself as well, so I was curious what other peoples experience and best practices are in these. Especially since Ignaz mentioned to me during high-tea he often made use of the Oracle Service Bus in his projects.

The general version principles he summarizes:

clients should not be forced immediately, but gradual, retire gracefully

support multiple service versions

An overview is presented about existing design patterns that reference to versioning which Ignaz recognized mentioned by Thomas Erl in his book “SOA Design Patterns”

Identical to Robert sessions, also Ignaz mentions 2 service compatibility strategies:

forward compatible:

todays version, comp tomorrow

complex topic, so nobody uses it

xml schemas supports this, but it’s unreadable and so complex

backward compatible:

new version available, consumers with older version

optional field added for instance, then schema validation is ok but service contract not

Ignaz also explains the 2 options for message validation (compatibility contracts) in a service landscape: design time vs run time .

Design Time (schemas: wsdl/xsd):

version in tech service contract (namespaces)

single governance

new version, requires new client build

Run Time (schematron):

version in non-technical service contract

must be governed

new version not necessarily requires a new client build or deployment

a bit more flexible then design, but harder to maintain

Ignaz then continuous with the real-world common scenario:

endpoint of services contains version number

grammar based service contracts (wsdl/xsd) are used

version numbers in xml namespaces, which is terrible (JvZ: i fully agree)

Only a single service version in operation at any time

So to minimize the big bang to mediation

design by contract, contract first instead of contract last (JvZ: no db schemas or backend system element naming in the service consumer messages, sadly something that you still often see is being used)

don’t hardcode versions in your service landscape

use rule-based (xpath/schematron) instead of WSDL/XSD (full message) (JvZ: Ignaz has the same opinion as Robert, I’m very stubborn so I’m still in doubt if I would agree on them both)

At the end of his presentation he pleads for a WS-Versioning standard for SOAP webservices. This would allow version mediators to be build into a service bus and frameworks. An example is that ?versions could be added to w3c standards as is now the ?wsdl standard

I know Guido as co-author (and main driving force) of our Oracle Service Bus Developers Cookbook project. As I met Guido earlier that conference I mentioned I probably wouldn’t be attending his BigData/NoSQL session because my knowledge of the subject was very minimal. However Guido told me that his session actually could be seen as a good introduction and overview of NoSQL world. So I was convinced, and mainly because I fully agree to what he mentioned as well in the start of his presentation: “Architects should look around for trends that seem to occur and which trends are becoming more and more interesting for them”. In heart, I’m still and always will be a technology nerd so these kind of sessions are very valuable.

Guido starts with an overview of the history of databases during the 60’s until now. From file based, hierarchical databases through SQL query relational databases and NoSQL nowadays.

He explains while relational databases we all know are great, but makes an overview of the different problems:

problem: complex objects graphs

object/relational impedance mismatch

map screen/object to relational schema (2 tables). We have hibernate

performance issues: many rows, many joins, eager vs lazy loading

problem: schema evolution:

adding attribute to object, have to add columns to table

problem: semi-structured data

name value table, poor performance / lack of constraints

serialize as a blob, no query

So then we arrive at the subject NoSQL (Not Only SQL) and its characteristics:

An overview of NoSQL Database types is shown (key/value, column, document, graph) and examples of the available products out there.

Guido closes his presentation with a picture showing 3 different data access architectures:

consumer / SOA middletier / database: example we see a lot in SOA landscapes where adapters/services connect to the database and present data to the service consumers. Positive aspect is the control over the data

html5 webpage example / REST with JSON / object database: he warns about going back 20 years. While it is fast development it’s also very strict and hard coupling. Governance is almost none, so in the end you will regret this.

consumer (html5) / SOA middletier / NoSQL database: the way to go, usage of middletier to maintain control over your data and prevent hard coupling between consumers and data.

Conclusion:

2 very interesting days where I had to conclude that not all sessions were evenly interesting for me (some I found to high level and/or to abstract). But enough interesting sessions with experience from the front line trenches. Another pleasant surprise was when I received a preliminary manuscript review edition of ‘Cloud Computing: Concepts and Technology‘ by Thomas Erl. More books to read, the pile is only getting bigger.