This article was written during a research project I did. The original paper was written on a Macintosh IIfx using Aldus Pagemaker, Aldus Paint and possibly some other obsolete software, which is why the document is still undergoing software archeology in order to re-create it in html.

by A.Rutges & R.W.Vens

Faculty of Management and Organization
University of Groningen
Landleven 5
P.O.Box 800
9700 AV Groningen
The Netherlands
Fax: +xxxxxxxxx
Phone: +xxxxxxxx
E-mail:
This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.

Copyright © 1991 by Ap Rutges & Rob Vens 

(Dit artikel is eerder gepubliceerd in de Spring '96 ING Component Architecture newsletter - ICA)

Back ten years or so, when I started dabbling in object technology, I could afford to be some kind of a “software hippie”. I’m sure you know the kind. They pop up every now and then, even in respected software companies (I didn’t name one, did I?). They radiated the unrelenting optimistic attitude that melted the software crisis, budget restrictions and management dedicated to the old ways like an overheated nuclear reactor. They seem to become however, at least from my point of view, rarer. But then my point of view has changed of course. What was a new, untested, and indeed overly optimistic and enthusiastic “new wave”, has now become a respected and accepted technique. I have less and less difficulty in advocating this “new way” to the decision makers. Instead of bright and curious technical persons, often working as programmers in the larger companies, it is more and more middle and higher management acting as object oriented evangelists. So I started wearing ties, stopped trying to convince and put my efforts in the “how” instead of the “if”.

 (Dit artikel is eerder verschenen in Software Release Magazine / jaar: 1997 / nummer: 4 / 6 Juni 1997) onder de titel Waarom software terugbijt.

De wraak van systemen

Wat zijn de problemen waar software ontwikkelaars tegenaan lopen? Op welke manieren kunnen wij verwachten dat onze huisdiertjes terugbijten? Op welke wijze kunnen wij systemen bouwen die dat voorkomen?

De wereld waarin Alice terecht kwam nadat ze voldoende moed had verzameld om door de spiegel te stappen was een merkwaardige wereld.

“… de oude kamer was nogal gewoon en oninteressant, maar al het andere was zo anders als maar mogelijk was. Bijvoorbeeld de plaatjes op de muur naast het vuur leken allemaal te leven, en de klok zelf op de schoorsteen (je weet dat je alleen de achterkant kunt zien in de Spiegel) had het gezicht van een klein oud mannetje, dat naar haar grijnsde …”

Als ik dit lees komt een uitspraak van Alan Kay, de uitvinder van de moderne computer, in mij op: “…de computerrevolutie heeft nog niet plaatsgevonden…” (OOPSLA 1997, keynote speech, video link onderaan het volledige artikel voor de geïnteresseerden, aanbevolen!).

Wat wij als Java ontwikkelaars doen lijkt vaak teveel op wat we al eerder deden in C++, VisualBasic of welke taal dan ook waar we ons van bedienden voordat we gegrepen werden door het Java virus (of misschien voordat onze baas gegrepen werd door dit virus …!). Wat er werkelijk aan nieuwe dingen mogelijk zijn door welke verandering dan ook onttrekt zich in eerste instantie aan onze ogen, getraind als we zijn om alleen die dingen waar te nemen die ons uitentreuren zijn uitgelegd. “Wat de boer niet kent …”

Het grote probleem bij de invoering van Java als onderdeel van transitietrajecten van organisaties is het gebrek aan vuistregels die aangeven op welke wijze de inzet van Java tools het beste kan plaatsvinden.

Er zijn mij nog geen publicaties bekend die een architectuur uitwerken gebaseerd op thin clients, communicerend met een server die als EJB container een multi-channel wereld bediend op een object-georiënteerde manier. De schrijvers van de bestaande publicaties maken zich vooral druk om de technologische implicaties van Java, hetgeen ook wel begrijpelijk is voor een jonge technologie.

Wat ik in dit artikel wil behandelen zijn de volgende vragen:

1. Wat zijn de beperkingen van de EJB architectuur?
2. Zijn er mogelijkheden om deze beperkingen te omzeilen?
3. Wat zijn de consequenties van deze mogelijkheden voor de kosten-effectieve inzet van standaard componenten?

Daarom kan dit artikel beschouwd worden als een aanzet om te komen tot een werkbare heuristiek voor het werken met deze technologie.

Dit artikel bevat een visie op historische ontwikkelingen. De mens die de geschiedenis niet kent is gedoemd deze te herhalen wordt wel eens gezegd. Bovendien zijn veel historische ontwikkelingen gestold in een eenzijdige of sterk gekleurde interpretatie, en ik probeer in dit artikel enkele standaard interpretaties onderuit te halen of aspecten te laten zien die wellicht nieuw of onbekend zijn.

Het doel is om hieruit lessen te leren die ons kunnen helpen het vakgebied van software engineering verder te helpen. Veel leesplezier, en ik hoop op uw (opbouwende) kritiek. Zoals alle artikelen op deze site is dit bedoeld een levend document te zijn, dat kan groeien en aan kwaliteit en hopelijk ook impact kan winnen.

Dit is deel 1 van een serie van drie artikelen die architectuurprincipes introduceren van een domain driven architectuur.

 Deze serie is oorspronkelijk gepubliceerd in 2001, maar zoals alle artikelen op deze site die niet als blog artikel zijn verschenen in de loop van de jaren aangepast. Deze architectuurprincipes zijn in een groot aantal projecten met succes geïmplementeerd — op verzoek kunnen wij referenties aanleveren.

In dit tweede deel wordt de structuur van het business domein component duidelijk gemaakt. Deel 1 behandelt de basisprincipes. Deel 3 gaat over de service architectuur koppeling.

Inleiding

Nadat de vorige keer een algemene structuur is geschetst van wat door mij genoemd wordt een domein- of business-centered architectuur, is het in dit artikel de bedoeling duidelijker te maken wat dit inhoudt.

Het doel van het domein component, zoals in het vorige artikel geschetst, is een draaiend software systeem dat een exacte replica tracht te zijn van de business.

Dit artikel is de tweede in een reeks van drie. In deel drie zal de architectuur uitgewerkt worden in een schets van een fysieke implementatie die probeert zo duidelijk mogelijk een beeld te geven van wat een mogelijke realisatie van de ideeën in de praktijk zou kunnen zijn. De term die hiervoor gebruikt wordt is die van Service Architectuur, waarin duidelijk wordt dat onder architectuur niet alleen een fysieke, maar ook een logische en conceptuele betekenis moet worden gehecht.

In dit derde deel worden de principes die in de voorgaande delen zijn behandeld uitgewerkt in een simpele voorbeeldimplementatie.

Deel 1 behandelt de basisprincipes. Deel 2 gaat over de business domein component.

Doelstelling

Teneinde de beweringen in de voorgaande artikelen te ondersteunen met voorbeelden uit de praktijk, wil ik in dit artikel een eenvoudige implementatie uitwerken. Deze implementatie heeft tot doel de lezer een helder beeld te geven van wat de uitwerking van de ideeën in de praktijk behelsd, en de pragmatiek van het architectuurmodel te bewijzen. Hier is geen sprake van rocket-science, alleen uitvoerbaar door genieën of bovengemiddeld begaafde ontwikkelaars! Dat zou onder andere één van de vooronderstellingen al onderuit halen, namelijk resultaten op korte termijn.

What we generally see when we look at tools for business modelling is an attempt to visualise the flow of activities in an organisation. I once heard a consultant from a workflow tool vendor proudly say that:

"Now finally the managing director understood what was really happening in his organisation!"

We don''t want to argue that this consultant was entirely wrong. In fact, workflow modelling has helped many organisations to finally get a grip on their processes, and took important steps toward a more controlled and repeatable process. Especially for QA and CMM this has had a positive effect. But I beg to question whether the managing director "really" had a better understanding.

Should they be simpler? This is what almost every definition or treatise on models and the art of modelling argues: models should be simpler than the thing they model. Otherwise, what''s the use? The darned thing is too complex, right? So we create a model, we factor out the parts we don''t need, we are left with the model containing those aspects of the real thing we need and nothing more, and the world seems manageable again.

Indeed it seems this scientific technique is prevailing in many areas. You cannot read a textbook on physics, without encountering statements like "we do not take into consideration aspects like friction". It is this strategy of trying to create a virtual "ideal world" that makes many scientific endeavours doable, and indeed I certainly acknowledge that this strategy has made progress of modern science possible. But let''s not lose sight of the psychological aspects of this technique. It has been applied in the Renaissance for the first time, a period in which Western culture detached humanity from nature, resulting in "power over" nature. This was the birth of "modern" science.

Metaphors have a profound impact on the effectiveness (or lack of it...) of your solutions. Especially for business modelling the choice of the right metaphor can have benefits you would not have expected. This is because modelling in general and business modelling especially suffers from symptoms caused by an endemic use of the wrong metaphors.

The unconscious use of metaphors is detrimental, and handicaps us in exploiting the possibilities a specific technology or invention offers, to be creative, find new ways of using them, but also hinders us in realising the negative effects it might have, and the ethical and political implications.

This article describes the role of metaphors and how insight in how they function can help you in become a better modeller.

I know of only two infinitely scalable systems ever built.

One we know, and many people will correctly guess this when asked. It is the internet. The internet started up October 29, 1969 when the first two systems, located in Stanford University and the University of California, connected. Since then, this network has been growing continually:

1. October 1969: 2
2. December 1969: 4
3. December 1971: 23
4. October 1972: ARPANET went public with a demo linking computers in 40 different locations.
5. currently: estimated minimum size of 500,000,000

(source: http://www.isc.org)

Lewis Carroll''s Alice in Wonderland has been a source of inspiration for me and many others concerning a specific aspect of complex systems. This aspect is one that in my view is essential if we want to realise the quantum leap in complexity that we need: reflection.