2009/05/27

Ken je Web Services standaarden!

De volgende tabel geeft een mooi overzicht van WS-* standaarden die gevolgd kunnen worden voor Web Services.










StandaardAdviesAlternatieven
OrchestrationBPELWS-Choreography, WS-CDL
Management
WS-DistributedManagement, WS-Provisioning, WS-Management
SecurityWS-SecurityWS-Trust, WS-Federation, WS-SecureConversation, WS-SecurityPolicy
TransactionWS-Transaction, WS-CoordinationWS-CompositeApplicationFramework (WS-CAF), WS-Context (WS-Ctx), WS-CoordinationFramework (WS-CF)
ReliabilityWS-ReliableMessagingWS-Reliability
DescriptionWSDL, UDDIWS-Inspection, Disco, WS-Discovery, WS-PolicyFramework, WS-MetaDataExchange
MessagingXML, SOAPWS-Addressing, WS-Notification, WS-ResourceFramework, WS-Eventing, WS-Policy, SOAP with Attachment
TransportHTTP, JMS, RMI-IIOPTCP, UDP, Jabber, SMTP
InteroperabilityWS-I Basic Profile

Mochten er toevoegingen zijn, dan voel je vrij om een Comment te plaatsen.

2009/05/26

SOA, EAI, BPM job trends

Op verschillende sites lees je dat de hype van SOA voorbij is. Dat geldt wellicht als marketing term, maar ik heb eens gezocht naar de vacatures die open staan.
Op de site indeed.com kun je de job trends bekijken (in amerika).


Nederland heeft ook een site indeed.nl. Helaas laat die site niet de trendlijn zien.
Maar dit geeft de volgende resultaten:
SOA: 483
EAI: 230
BPM: 133

De hype is wellicht voorbij maar het momentum is daar voor SOA om zich als distributed computing platform te bewijzen.

2009/05/20

Data Services

Het gebruik van Data Services (ook wel Entity Services genoemd) wordt goed uitgelegd in het volgende artikel: http://www.infoq.com/articles/narayanan-soa-data-services

Als tip zou ik ook nog meegeven: kijk ook eens naar een REST interface!

Gaat SOA slagen?

Ik lees veel artikelen over het Service Oriented Computing paradigma. Ik heb OO zien "slagen", in die zin dat het wereldwijd omarmd wordt. Ik heb Component Based Development toch al een stuk minder zien slagen. SOA gaat weer een stapje verder (enterprise wide) en ik ben benieuwd of deze vorm van architectuur kunst gaat slagen. OO is nog goed te overzien omdat het vaak binnen een applicatie blijft. Met herbruikbare componenten werken binnen je afdeling of zelfs binnen de organisatie vergt toch een hele andere vorm van samenwerken. Ditzelfde geldt ook voor SOA. Er is niet voor niets zoveel te lezen over Governance.
Net als de overgang van structured analysis/design (SA/SD) naar OO werd aangenomen dat dat alles zou oplossen. Dit is natuurlijk niet zo, je kunt er nog steeds een puinhoop van maken. Dit geldt ook voor de overgang naar een SOA, alleen dan nog een paar gradaties erger. Daarom denk ik dat het een zeer goede practice is om kleinschalig te beginnnen en eerst maar eens proberen om een enkele applicatie (Silo) te "SOAliseren". Dus verticaal i.p.v. horizontaal en dan beetje bij beetje meer zaken gaan toevoegen. Maar op deze manier doe je al ervaring op met Services en het herbruikmaar definieren van de Services. Ook kom je er dan achter dat er verschillende Service levels zijn (Entity, Task en Utility Services). Entity is een service die een business term omvat (dus zeer herbruikbaar), een task service is meer expliciet voor een stukje van een specifiek business process bedoeld (dus vaak ook minder herbruikbaar) en een utility service is meer een horizontale service zoals bijvoorbeeld voor logging of error handling.
Dus eerst maar eens terug naar de basis en een nette 3-tier applicatie bouwen dat is denk ik voor veel organisatie al een uitdaging op zich.

2009/05/18

Principles of Service Design

Het boek "SOA: Principles of Service Design" bevat een 8-tal service design principes.
Dit boek heb ik proberen te vangen in een MindMap:
Service-Oriented Computing
(Nog ongoing)

2009/05/11

JSpring 2009

Het is alweer eventjes geleden maar op 15 april was er weer de jaarlijkse NLJUG. Deze bijeenkomst van de Nederlandse Java Usergroup stond deze keer voor mij in het teken van SOA en integratie. Dus op zoek naar lezingen in deze richting ben ik naar de volgende sessies gegaan:
Het is natuurlijk altijd afwachten wat de kwaliteit van de lezingen is maar deze keer waren er 3 van de 5 (1 lezing heb ik niet eens genoemd) goed te doen.

Het modelleren van een CDM
Deze lezing gaf wat handvaten om een CDM te maken. Hierbij werd er onderscheid gemaakt tussen een hierarchisch en een relationeel datamodel. Ook werd er ingegaan hoe je semantiek kunt vastleggen m.b.v. schemas.
Conclusie: Helaas kon ze niet ingaan op het gebruik van Schematron, een andere XML standaard waarmee je semantische relaties kunt vastleggen (nog beter dan XML schema kan).

SOA its a hard knock life
Leuke lezing gegeven door Tijs Rademakers (auteur van Open Source ESBs) over de praktijk van de ESB. Zeer herkenbaar.
Conclusie: Een SOA (en ESB) is niet per definitie een oplossing natuurlijk. Hetzelfde zag je bij Object Orientatie en Component Based Development. Nu zie je ook weer bij SOA dat het een hele kluif is om dit goed te doen.

REST, het web als database
REST wordt altijd neergezet als de tegenhanger van SOAP, maar in deze lezing ging het vooral om het web als social web, waarbij alle data toegangekelijk gemaakt wordt via URIs.
Conclusie: Leuke lezing maar in het kader van SOA was ik meer geinteresseerd in het gebruik ervan. Maar hier ging de lezing niet echt over. Ik zie REST als een tool om (webservice) interfaces mee te maken evt naast SOAP interfaces. Wel iets om in de gaten te houden omdat grote spelers op de markt (Oracle, Microsoft) deze techniek aanbieden in hun producten.

Spring integration in jBPM
Dit was een zeer technische lezing over een implementatie van Spring in jBPM. Totaal niet wat ik van de lezing verwachtte. Dus niet over het gebruik van jBPM in combinatie met Spring.
Conclusie: Helaas zonde van mijn tijd geweest.

2009/05/08

SOA en Agile

Ik ben nog steeds van mening dat een Agile methodiek kan helpen om een SOA neer te zetten.
Ik kwam deze blog tegen over SOA en Agile.

Hierin wordt aangegeven waar het volgens hem fout gaat bij een SOA traject.
  • SOA als concept wordt niet begrepen. Er wordt vaak gedacht aan een WebService (WSDL) als de enige manier om "SOA enabled" te worden.
  • Geen commitment of betrokkenheid van de business.
  • Kosten zijn initieel hoog terwijl business voordeel laag is. Dit draagt natuurlijk niet bij aan het enthousiastme om verder te gaan.
  • Veel wordt de "Waterval" methode gebruikt, maar ook bij een SOA project zullen requirements veranderen, en zal de eindgebruik betrokken moeten worden.
Hoe kunnen we deze issues dan aanpakken:
  • Meer betrokkenheid van de business (processen analyseren).
  • Snellere opleveringen, waardoor er sneller resultaat te zien is.
En hier kom Agile SOA om de hoek kijken.
  1. Probeer samen met de business een case boven water te krijgen die directe business voordeel oplevert. Analyseer het huidige process en destileer hier Services uit.
  2. Veel opleveringen (bijvoorbeeld 1 keer per maand) en de business op de hoogte houden evt met presentaties, wellicht tot de conclusie komend dat een process zal veranderen.
  3. Betrek Eindgebruikers bij het project.
Met andere woorden een Verticale aanpak (gezien vanuit de SOA Stack) in plaats van een Horizontale.

2009/05/04

SOA Terminologie

Er is vaak verwarring en veel discussie over de terminologie die gebruikt wordt rondom SOA. Wat is SOA? Wat is een Service? Wat is ...?

Thomas Erl, een guru op SOA gebied, heeft een glossary site die handig is om te gebruiken.
http://www.soaglossary.com/

Planning en tracking

In mijn vorige project ben ik in aanraking gekomen met Agile en met name test driven development en Scrum. Met Scrum heb je een Agile process te pakken waarmee je zeer gedisciplineerd een project doorloopt. Een onderdeel daarvan is de planning en tracking d.m.v. zogenaamde Burndown charts. In een burndown chart houd je bij hoeveel tijd je nog nodig denkt te hebben. Bij klassieke project tracking methoden (iedereen kent wel de Microsoft Planning) wordt vaak alleen gekeken naar de hoeveelheid tijd gespendeerd. Want we hadden toch gezegd dat een bepaalde taak X uur duurde? Vaak is het echter zo dat je er gaandeweg achterkomt dat een taak meevalt of juist tegenvalt. Het is daarom ook interessant om te weten hoeveel tijd er nog te gaan is.

In mijn huidige project gebruik ik de burndown chart voor de voortgang in de gaten te houden. Echter een projectleider wil ook vaak weten hoeveel budget hij al besteed heeft. Dit heb ik als extra item toegevoegd in de chart om ook deze trend te volgen.

Als je dit alles dan in een diagram zet kun je zien wat de trend is van beide data.

Deze grafiek is goed te gebruiken om te zien of je de deadline gaat halen en of je niet te veel budget gebruikt. Je kunt met dit tool in handen dan ook eerder bijsturen door bijvoorbeeld taken te laten vervallen of anders in te vullen.

Enkele tips
  • Houdt de periodes klein (4/5 weken). Op deze manier kun je resources nog goed inplannen.
  • Schat in uren. Dit is vaak makkelijker dan zogenaamde story points (zoals in Scrum).
  • Communiceer vaak over de voortgang, problemen waar je tegenaan loopt. Wij werken op dit moment om de twee dagen de getalletjes bij.

2009/05/01

Afhandeling SOAP faults in ESB

Ik had laatst een interface specificatie gemaakt met WSDL met operaties die een soap fault terug kunnen geven. Deze wil ik afvangen in de ESB (10.1.3).
Eerst de WSDL code:

De provider van de webservice zal een soap fault retourneren met het element in het element van de soap fault:

Vervolgens kun je in JDeveloper in de Routing Service de fault en reply van de service afhandelen:
Vooral het feit dat de in het element moet staan is belangrijk en was even wat uitzoekwerk.