Difference between revisions of "3.3.2 Applicatie integratie tijdpad"

From Geonovum Wiki
Jump to: navigation, search
(EAI: Enterprise application integration)
 
m (1 revision)
(No difference)

Revision as of 09:56, 26 September 2009


Evolutie van informatieverwerking.

De evolutie van informatieverwerking verloopt van een meer technische naar een steeds meer geintegreerde procesmatige insteek, zie onderstaande figuur.

Applic1.jpg

De figuur geeft de reeks van concepten weer die de voorgaande decennia gangbaar waren om software applicaties met elkaar in verband te brengen. Het toont dus de evolutie van software architectuurmodellen. De horizontale as geeft de tijd weer, de verticale as weerspiegelt de geleidelijke verschuiving in de focus van die concepten: vroeger ging het om technische problemen, nu staat het werkproces, de 'business', centraal.


Verdere evolutie
De laatste jaren was SOA de smaakmaker. Inmiddels is er sprake van een mogelijke opvolger: EDA (Event Driven Architecture). Deze aanname valt te lezen in Computable 19 november 2008.
Met 'events' worden bepaalde gebeurtenissen in het werkproces bedoeld, die services moeten triggeren. Overigens zal in een organisatie EDA pas kunnen worden gerealiseerd als daar SOA op orde is.


De afkortingen

IPC: Inter-Process Communication

Inter-Process Communication (IPC) is een reeks technieken voor de uitwisseling van gegevens langs meerdere 'threads'; in één of meerdere processen. De processen kunnen op één of meerdere computers lopen die door een netwerk worden aangesloten. IPC technieken zijn verdeeld in methodes voor:

  • het berichtenverkeer,
  • synchronisatie,
  • gedeeld geheugen,
  • remote procedure calls (RPC).

De gebruikte methode van IPC kan variëren afhankelijk van de bandbreedte en de 'wachttijden' (latency) bij communicatie tussen de threads en het type gegevens die worden gecommuniceerd. Naar IPC kan ook als inter-thread communication en inter-application communication gerefereerd worden.

► Bron en meer hierover in de wikipedia


CORBA: Common Object Request Broker Architecture

Common Object Request Broker Architecture (CORBA) is een standaard die door de {http://www.omg.org/ Object Management Group (OMG)] is bepaald en die omschrijft hoe in verschillende computertalen geschreven softwarecomponenten op meerdere computers in samenhang met elkaar kunnen worden uitgevoerd. CORBA is een software mechanisme voor het normaliseren van het aanroepen van methodes in meerdere toepassingen in dezelfde omgeving worden uitgevoerd (zelfde host, of remote host op het netwerk). Versie 1.0 werd vrijgegeven in Oktober 1991.

► Bron en meer hierover in de wikipedia


COM: Component Object Model

Het Component  Object Model (COM) is een standaard voor de interface tussen software componenten die door Microsoft in 1993 is geintroduceerd. Het wordt gebruikt om inter-process communicatie mogelijk te maken bij het dynamische aanmaken van objecten in meerdere programmeertalen. COM wordt vaak gebruikt in softwareontwikkeling als een paraplu-begrip voor OLE, OLE, ActiveX, COM+ en DCOM.

► Bron en meer hierover in de wikipedia


EAI: Enterprise application integration

Enterprise application integration (EAI) wordt gedefiniërd als het gebruik van software en computersystemen om een reeks toepassingen in een organisatie te integreren. EAI is het proces om deze toepassingen binnen één enkele organisatie te koppelen om bedrijfsprocessen te vereenvoudigen en te automatiseren, terwijl tegelijkertijd vermeden moet worden dat bestaande toepassingen  en gegevensstructuren gewijzigd moeten worden. In de woorden van de Groep Gartner, EAI is the “unrestricted sharing of data and business processes among any connected application or data sources in the enterprise.”

► Bron en meer hierover in de wikipedia


SOA: Services Oriented Architecture

Services Oriented Architecture (of Approach). Service-oriëntatie, vertaling van Service-Oriented Architecture (SOA), is een architectuurmodel, geen technologie op zich. Centraal bestaat een SOA opgebouwd systeem service contracten. Hierbij is sprake van afnemers van diensten en leveranciers. Kenmerkend voor de diensten (en contracten) is:

  • Een service is virtueel: de afnemer heeft geen weet van de implementatie van de dienst. De dienst is onafhankelijk van de afnemer. Scheiding van verantwoordelijkheid is exliciet vastgesteld. Voordeel hiervan is onafhankelijkheid van veranderingen van afnemer en leverancier. Voldoen aan het contract staat immers centraal;
  • Een service is gestandaardiseerd: er is slechts één implementatie aanwezig van een verantwoordelijkeheid. Voordeel is het rationaliseren van de standaard. Standaardiseren=massa, massa=kassa. De dienst wordt 'commodity' en eenvoudig te vervangen door een andere leverancier of goedkoper door een efficientieslag;
  • Een service is modulair (vervangbaar) en compositioneerbaar. Standaard is niet flexibel. Flexibiliteit wordt bereikt door combineren (componeren) van standaards...tot een nieuwe standaard;
  • Een service is abstract: generiek, niet afgestemd voor 1 specifieke afnemer, maar op een doelgroep van afnemers;
  • Losgekoppeld: afnemer en leverancier zijn maximaal onafhankelijk van implementatie van beide. Elke service is daarom autonoom. Er bestaat geen directe link of relatie tussen verschillende services. Services zijn zich ook niet van elkaar bewust.

SOA en Software

De SOA principes zijn al decennia bekend binnen softwareontwikkeling. Sinds begin van de 21e eeuw heeft de softwareindustrie SOA aangegrepen voor technische dienstverlening, zoals ESB, XML, SOAP, webservices. De technologische benadering van SOA is alleen geschikt om platformonafhankelijke communicatie te bewerkstelligen. SOA komt tot zijn recht wanneer een organisatie(onderdeel) de SOA principes toepast op zichzelf en daarmee ook de ICT dienstverlening hierop aanpast.


► Bron en hierover in de wikipedia en zie verder deze module.



previous Services Oriented Architecture (SOA) next