computerwoche.de
Newsletter  |   CW-TV  |   Bilder-Galerien  |   Blogs & Forum  |   CW mobil  |   RSS  |   Aboshop


SOA & BPM

OOP 2008: Entwicklertipps für den SOA-Einstieg



Repository nicht vorrangig

Ein aktiver Service sollte nicht geändert werden. Will man weitere Datentypen einbinden, ist dafür ein neuer Service nötig.
Ein aktiver Service sollte nicht geändert werden. Will man weitere Datentypen einbinden, ist dafür ein neuer Service nötig.

Für entbehrlich, zumindest zu diesem Zeitpunkt, hält er das von Herstellern im Rahmen von SOA dringend empfohlene Repository, in dem die fachlichen Beschreibungen der Services hinterlegt sind, sowie eine Registry, in der die technischen Details zum Servicebetrieb gesammelt werden. Stattdessen reiche meist ein einfaches zentrales Verwaltungs-Tool. Viel wichtiger sei dagegen von Anfang an die Verwendung eines Metamodells, denn nur so erhalte der Entwickler eine Vorstellung von der Mächtigkeit seiner Service-Schnittstellen.

Was den Lebenszyklus eines Service betrifft, so ist dieser mit einer entscheidenden Ausnahme dem in der traditionellen Softwareentwicklung ähnlich: Der Anforderungsaufnahme entspricht das Identifizieren eines Service, es folgt die Modellierung beziehungsweise das Design, die Implementierung über Codegeneratoren, der Test und die Auslieferung. Die in der klassischen Entwicklung aufgrund eines Change-Requests vorgenommene Änderung eines Programms sollte es in einem aktiven Service jedoch nicht geben. "Änderungen an den Services einer SOA sind im Grunde nie rückwärtskompatibel", warnt Josuttis. Der Grund: Ist ein Service in Betrieb und wird nachträglich etwa mit weiteren Datentypen angereichert, müssen alle bei der Codierung erzeugten Bibliotheken neu kompiliert werden. Das gelingt in der Praxis offensichtlich nicht immer, so dass die Gefahr besteht, dass der Service einem Consumer nicht mehr zur Verfügung steht. Mit Ausnahme von Bugfixes, die keine Auswirkungen auf Service-Schnittstellen haben, wird daher dringend empfohlen, für Änderungen einen neuen Service aufzusetzen und den alten gegebenenfalls außer Betrieb zu nehmen. Damit geht auch die Notwendigkeit einher, Serviceaufrufe zu protokollieren, um einen Nutzer über die geplante Abschaltung eines Service informieren zu können.


Leserkommentare 
(0 Beiträge), 
Kommentieren

Beitrag schreiben

Noch kein Forums-Mitglied?
Dann gleich hier anmelden.

SOA & BPM: CW-REDAKTEURE EMPFEHLEN
FAQ Business Process Management FAQ Business Process Management Was verbirgt sich wirklich hinter dem BPM-Konzept und wie können Unternehmen davon profitieren? Die Antworten finden Sie hier. weiter
SOA macht die HVB flexibler SOA macht die HVB flexibler Wie die HypoVereinsbank mit einer SOA-Infrastruktur schneller auf Veränderungen reagieren kann. weiter
Was vom SOA-Hype übrig bleibt Was vom SOA-Hype übrig bleibt Die SOA-Euphorie ist abgeklungen. Viele Projekte stecken in Schwierigkeiten. Trotzdem halten IT-Verantwortliche an ihren Plänen fest.  weiter
Warum SOA-Projekte schiefgehen Warum SOA-Projekte schiefgehen SOA-Initiativen scheitern nur selten an technischen Hürden. Viel häufiger sind menschliches Versagen und kulturelle Probleme. weiter
In zehn Schritten zur SOA In zehn Schritten zur SOA Die COMPUTERWOCHE beschreibt zehn Schritte, die sich beim Aufbau einer SOA in der Praxis bewährt haben.  weiter
FAQ Business Process Management SOA macht die HVB flexibler Was vom SOA-Hype übrig bleibt Warum SOA-Projekte schiefgehen In zehn Schritten zur SOA
MEHR ZUM THEMA SOA & BPM
  • Artikel
  • Whitepaper
SOA meets BPM
FEATURED LINKS

KOSTENLOSE NEWSLETTER VON COMPUTERWOCHE
Nachrichten morgens
Whitepaper
Nachrichten mittags
CW-Mittelstand
Highlights der Woche
Hardware
Neu: SAP-Newsletter
Software
Job + Karriere
Open-Source
Stellenmarkt
Produkte + Techn.
Freiberufler
Security