2009/03/14

SOA De Hype Voorbij?

Voor mijn werkgever ben ik bezig met de implementatie van een ESB dat als basis zou moeten gaan dienen voor een SOA Architectuur.
Zoals te lezen in de Computable is dit eigenlijk niet direct de goede benadering. Dit is meer een bottom up benadering terwijl een meer top down benadering nodig is. In ieder geval vertikaal waarbij je begint bij de business functionaliteit (indiensttreding van een werknemer), en deze case verticaal implementeerd (BPM, EAI, Data).
In ons project zijn we eigenlijk meer bezig met EAI met Messaging i.p.v. de "service" benadering.

Messaging in een SOA omgeving


Ik zal dit nader proberen uitleggen. Als voorbeeld neem ik de indiensttreding van een werknemer en om het voorbeeld eenvoudig te houden onderken ik slechts een paar stappen:
1) Invoer werknemer met NAW gegevens
2) Werknemer moet een IT account krijgen
3) Werknemer krijgt een kostenplaats binnen het financieel systeem

In dit scenario spelen 3 systemen applicaties een rol:
A) Systeem invoer werknemer waar hij en personeelsnummer krijgt
B) Systeem waar financiele afhandeling en grootboek bijgehouden wordt
C) Systeem waar IT accounts worden aangemaakt

In mijn beeld kun je dit scenario op de volgende manieren aanpakken:
I) Je zet op de ESB een Medewerker (CDM) bericht. De 3 systemen zullen onafhankelijk van elkaar het bericht oppikken en hiermee aan de slag gaan (zie stappen 1-3). Dus 1 systeem zal de werknemer toevoegen aan het HRM systeem. Het financieel systeem zal een kostenplaats voor de werknemer aanmaken en het IT systeem zal een IT account aanmaken.


II) Er worden 3 verschillende CDM Entiteiten op de ESB geplaatst (Medewerker, Account, Kostenplaats). Dit zijn in feite drie verschillende CRUD operaties op Domein entiteiten.

Laten we deze twee mogelijkheden nader bekijken. In het eerste geval is de oplossing meer EAI gebaseerd. Hiermee bereik je data herbruikbaar op de ESB. Het heeft echter als nadeel dat de verschillende functionaliteiten niet afzonderlijk herbruikbaar zijn (toevoegen kostenplaats, aanmaken IT account). Dit is bij de tweede oplossing wel het geval.

Dus je Domein Model is zeer belangrijk in de je SOA oplossing.

2009/03/12

WebService Testing

When I wanted to test a WSDL I looked accross the internet for a free test tool and found a great tool: soapUI.

With this tool you are able to:
  • Test operations
  • Set assertions on it
  • Create test suites
  • Create mocks
  • Test REST, SOAP and HTTP interfaces
  • Load testing

2009/03/11

SOA Design Patterns

Just like Design Patterns, Enterprise Integration Patterns and Architecture Patterns, Thomas Erl comes with a SOA Design Pattern book.
InfoQ has an interview with him: read interview

He states that a SOA patterns is something different than a webservice patterns. SOA is about services and a webservice is a technology specific realization of a service. He also states that in fact EAI frameworks and middleware, enterprise service bus platforms, grid computing, transaction management systems, messaging queues, event-driven messaging frameworks, broker and mediation technologies were used as inspiration for the SOA patterns.

He also explains his difference between service orientation and a SOA: "Service-orientation is a distinct paradigm that you apply to achieve a specific target state and a technology architecture is considered service-oriented if it has the characteristics necessary to support the application of this paradigm." Nice and clear right?

I have not read the book (yet), but I will come back to it. Hopefully it helps to answer when a service is a service. Does it have to have business value, or can secondary business functionality like HRM services also be considered services?