Architect Consultant blog

De volgende tabel geeft een mooi overzicht van WS-* standaarden die gevolgd kunnen worden voor Web Services. Standaard Advies Alternatieven Orchestration BPEL WS-Choreography, WS-CDL Management WS-DistributedManagement, WS-Provisioning, WS-Management Security WS-Security WS-Trust, WS-Federation, WS-SecureConversation, WS-SecurityPolicy Transaction WS-Transaction, WS-Coordination WS-CompositeApplicationFramework (WS-CAF), WS-Context (WS-Ctx), WS-CoordinationFramework (WS-CF) Reliability WS-ReliableMessaging WS-Reliability Description WSDL, UDDI WS-Inspection, Disco, WS-Discovery, WS-PolicyFramework, WS-MetaDataExchange Messaging XML, SOAP WS-Addressing, WS-Notification, WS-ResourceFramework, WS-Eventing, WS-Policy, SOAP with Attachment Transport HTTP, JMS, RMI-IIOP TCP, UDP, Jabber, SMTP Interoperability WS-I Basic Profile Mochten er toevoegingen zijn, dan voel je vrij om een Comment te plaatsen.

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). soa, eai ,bpm Job Trends soa jobs - eai jobs - bpm jobs 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.

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!

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 een

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)

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 modelleren van een Canoniek Data Model m.b.v. XML Schema SOA It's a hard knock life REST, het web als database? Spring integratie in jBPM 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 h

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. Probeer samen met de business een case boven water te krijgen die directe business voordeel opl

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/

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. A

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.