Doorgaan naar hoofdcontent

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.

Reacties

Populaire posts van deze blog

OSB 10gR3 and SWA and MTOM

This blog is about using soap with attachments and the use of MTOM within the OSB (10gR3). A service is created that accepts a soap with attachment (DocumentService) and translates it to a service that accepts a binary element. MTOM is used for performance reasons for the second. Some notes: * For the use of attachments you need RPC-style document instead of the usual document-style. This due to the fact that the document-style limits a message to a single . * A service can not have both SWA and MTOM within OSB. First a WSDL is setup for the DocumentService: The $attachments variable holds the attachments and the body holds the attachment data. Also other data is stored within the attachment element (see h

Microservices mindmap

"The tree" - See also   my photo page When you are fairly new within the Microservices land, there are a lot of terms fired at you. So also for my own understanding i have made a mindmap. I think it has a good status now, so that i can share it with you. As always feedback is very welcome ! You can download the mindmap here .

Book review: Data Management at Scale (Piethein Strengholt)

 This blog is a review of the book "Data Management at Scale (See also at bol.com ) Data Management is a hot topic nowadays and this book does a fantastic job at adding value to this topic. It is a must read and one of the few technical books I finished reading in a weekend. The book gives a fantastic overview on how to implement a Data Mesh data architecture. The Data Mesh concept is explained by Martin Fowler here . The book is a good mix between conceptual and implementation architecture level. It gives a lot of examples of how this architecture at scale can work, for both small and big companies. It is practical and I used it to implement it at one of my customers. The book describes an architecture in which the focus is on the DIAL (Data- and Integration Access Layer).  On a high level the book covers the following topics: The key principles for data management at scale - Domain-Driven Design  - Domain Data Stores - Meta data management Ready Data Store The concept of servin