An easy process calling a Webservice

<definitions>
...
  <import importType="http://schemas.xmlsoap.org/wsdl/"
          location="http://localhost:63081/counter?wsdl"
          namespace="http://webservice.activiti.org/" />

  <process id="asyncWebServiceInvocationWithDataFlowUEL">
	  <!--
		  The Data Inputs and Outputs of a Process have to be explicitly
		  declared with their type to be valid BPMN 2.0
	  -->
  	<ioSpecification>
  		<dataInput id="dataInputOfProcess" itemSubjectRef="tns:setToRequestItem" />
  		<inputSet>
  			<dataInputRefs>dataInputOfProcess</dataInputRefs>
  		</inputSet>
        <outputSet />
  	</ioSpecification>
    ...
    <serviceTask id="webService"
                 name="Call WS"
                 implementation="##WebService"
                 operationRef="tns:setToOperation">
            <!-- The BPMN 2.0 Meta Model requires an Input/Output Specification -->
            <ioSpecification>
                <dataInput itemSubjectRef="tns:setToRequestItem" id="dataInputOfServiceTask" />
                <inputSet>
                    <dataInputRefs>dataInputOfServiceTask</dataInputRefs>
                </inputSet>
                <outputSet />
            </ioSpecification>
            <dataInputAssociation>
                <sourceRef>dataInputOfProcess</sourceRef>
                <targetRef>dataInputOfServiceTask</targetRef>
   				<assignment>
   					<from>${dataInputOfProcess.newCounterValue}</from>
   					<to>${dataInputOfServiceTask.value}</to>
   				</assignment>
            </dataInputAssociation>
    </serviceTask>
    ...
  </process>
  <!-- Interface: implementationRef = QName of WSDL Port Type -->
  <interface name="Counter Interface" implementationRef="counter:Counter">
    <!-- Operation: implementationRef = QName of WSDL Operation -->
    <operation id="setToOperation" name="setTo Operation" implementationRef="counter:setTo">
      <inMessageRef>tns:setToRequestMessage</inMessageRef>
    </operation>
  </interface>
  <message id="setToRequestMessage" itemRef="tns:setToRequestItem" />
  <itemDefinition id="setToRequestItem" structureRef="counter:setTo" /><!-- QName of input element -->
</definitions>

I don’t want to explain the BPN 2.0 XML in detail here, actually I could recommend a good book on it

As you can see the XML is pretty verbose. But sure, there is a good reason for that: There are a lot of indirections to define the data, the data input and output mappings, the interface of the service in a technology neutral way and so on. So there is a reason, but without good graphical tooling, it is hard to handle.

Java-Alternative

So the next thought is: Hey, we are Java developers, why not do it much easier in a Java way? We could leverage Apache CXF (like the Activiti Webservice implementation does internally as well) and hook it into our BPMN process by an Activiti extension. Wait: An Activiti extension? That doesn’t sound standard compliant. Right, it is not. But actually look what you get out of it, this is the same process calling the Webservice directly:

<definitions>
  <process name="SimpleWS" id="SimpleWS">
    ...
    <serviceTask id="Call_WS" name="Call WS" activiti:class="com.camunda.training.delegate.WsDelegate" >
      <extensionElements>
        <activiti:field name="wsdl" expression="http://localhost:18080/VacationService?wsdl" />
        <activiti:field name="operation" expression="saveVacationApproval" />
        <activiti:field name="parameters" expression="${user}, ${days}" />
        <activiti:field name="returnValue" expression="myReturn" />
      </extensionElements>
    </serviceTask>
    ...
  </process>
</definitions>

Isn’t that a huge difference? Okay, the downside is, that this isn’t standard compatible any more. But actually I have never seen somebody really exchanging the process engine without any effort. I haven’t even seen that with Databases or Application servers often (and these are stone age technologies compared to BPMN), so I don’t think that this is such a huge disadvantage. But that differs in every project…

Now, in order to get the above process to work we need a so called JavaDelegate (a small Java class we can attach to the BPMN process, which is executed when the process instance runs through the service task). This just takes the parameters I configured and calls the Webservice. Agreed, the parameter gathering is a bit hacky and not powerful enough yet, but hey, it is a 15 minutes prototype. And it was really only 15 minutes with all components. Here you can see the code of that piece of Java Code:

public class WsDelegate implements org.activiti.engine.delegate.JavaDelegate {
  private Expression wsdl;
  private Expression operation;
  private Expression parameters;
  private Expression returnValue;

  public void execute(DelegateExecution execution) throws Exception {
    String wsdlString = (String)wsdl.getValue(execution);

    JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance();
    Client client = dcf.createClient(wsdlString);

    ArrayList paramStrings = new ArrayList();
    if (parameters!=null) {
      StringTokenizer st = new StringTokenizer( (String)parameters.getValue(execution), ",");
      while (st.hasMoreTokens()) {
        paramStrings.add(st.nextToken().trim());
      }
    }
    Object response = client.invoke((String)operation.getValue(execution), paramStrings.toArray(new Object[0]));
    if (returnValue!=null) {
      String returnVariableName = (String) returnValue.getValue(execution);
      execution.setVariable(returnVariableName, response);
    }
  }
}

By the way: We are currently discussing if we include this possibility of calling Webservices in the Activiti engine intself. But currently we want to finish the standard way first, which is for sure important to support. But I guess later on we will go for something like that as well, since that is really developer friendly

Location transparency

With our neat little Webservice call in the process we face a problem now: We have the WSDL-Address written in the process definition (actually in both of the examples above). What if the host for that service changes? Do I have to change all running processes? Not a good idea actually. Wait, location transparency, routing, that must be a job for an ESB! I would say: Maybe. Very often not If I just want to hide the host of that Webservice to my process, what I need is a Registry. A Registry is included in every ESB, so the ESB may make sense. But very often I see the ESB as too unhandy, complex and oversized. Especially if you only need it as a Registry. Don’t get me wrong, there are use cases for ESBs, but only a Registry is not enough.

So to finish my quick post today, I extended the Webservice example with Mule Galaxy, an open source Registry. Therefor I just add the WSDL to the registry and access it from there now:

<serviceTask id="Call_WS" name="Call WS" activiti:class="com.camunda.training.delegate.WsDelegate" >
  <extensionElements>
    <activiti:field name="wsdl" expression="http://my-registry-cluster/galaxy-web-1.5.3-embed/api/registry/Demo/VacationService.wsdl" />
    <activiti:field name="operation" expression="saveVacationApproval" />
    <activiti:field name="parameters" expression="${user}, ${days}" />
  </extensionElements>
</serviceTask>

Now I could configure everything centrally in the registry but keep the neat simple Webservice mechanism I just developed

Or using ESB?

Calling a Webservice frm the process but using a Registry

Calling a Webservice directly from the process

Calling a Webservice via the Mule ESB

Bernds cooles Interview

Bitte nicht vergessen: Am 23. April ist der SOA & BPM Day auf der Jax, den Bernd moderiert und wo auch ich selbst in gewohnt unbescheidener Manier etwas zu BPMN erzählen werde.

Man sieht sich

Naja, ganz so einfach ist es natürlich nicht. Aber es ist ein wenig schade dass die Leute sich immer nur für diese Frage interessieren, obwohl das 1) Stand heute nun mal nicht (wirklich) funktioniert, 2) auch gar nicht unbedingt soviel bringt und 3) es andere Möglichkeiten im BPM-Kontext gibt, die heute schon funktionieren und sehr viel bringen.

Aber was sollt’s – hier kommen die Folien zum Vortrag:

3.3.2.3    SOIA in der Praxis
Die Integrations- oder Agilitätsebene umreißt das Themengebiet, das in der öffentlichen Diskussion auch gern als Zusammenspiel von BPM und SOA bezeichnet wird. Es geht um die an der Unternehmensorganisation ausgerichtete Definition und Wartung von Services, sowie um ihre prozessorientierte Nutzung. Leider befinden sich die Kenntnisse und Erfahrungen im SOIA-Bereich heute noch weit unter dem Niveau der SOSA-Ebene. Das bedeutet, es existieren noch viele offene Fragen, wie eine SOIA richtig umgesetzt werden kann – und teilweise sind noch nicht einmal die richtigen Fragen gestellt worden.

Als relativ sicher gilt die grundsätzliche Feststellung, dass sich die Prozessagilität aus der Fähigkeit ableitet, definierte Services relativ einfach neu kombinieren zu können, und dass es deshalb eine Möglichkeit geben muss, die Reihenfolge der Nutzung vieler Services direkt an der Prozesslogik auszurichten, und diese Reihenfolge über einen Mechanismus verändern zu können, der keine direkte Programmierung erfordert. Diese Überlegung führt zunächst zum Ansatz der Service Orchestrierung, bei dem eine Orchestration Engine die Rolle eines Dirigenten übernimmt, und wie bei einem Orchester ausgehend vom Prozessmodell mal den einem, mal den anderen Service zur Ausführung einer Aufgabe anweist. Solche Aufgaben können sich auf einfache Datenoperationen beziehen, wie das Auslesen von Kundenstammdaten aus einem CRM-System, oder auf komplexe Geschäftslogik, wie die Berechnung eines Beleihungswertes im Rahmen einer Baufinanzierung.

Sofort drängt sich der Vergleich zum Human Workflow Management  auf: Dort übernimmt die Workflow Engine diese Rolle, und die am Prozess beteiligten Mitarbeiter und Partner stellen mit ihrer Arbeitskraft und Kompetenz die „Services“ bereit, die mittels Aufgabenzuweisung aufgerufen werden.
Somit wird auch ersichtlich, warum ein ganzheitliches Business Process Management die Methoden „Human Workflow Management“  und „Service Orchestration“ gleichermaßen abdecken muss.

Eine für die praktische Serviceorchestrierung sehr wichtige Differenzierung ist die Unterscheidung von synchronen und asynchronen Service Aufrufen („Service Calls“; Bild 3.18): Bei einem synchronen Service Call geht der Consumer davon aus, dass der Provider kurzfristig die Aufgabe abarbeiten und das Ergebnis zurückgeben wird. Dementsprechend wartet der Consumer auf diese Antwort und führt keine weiteren Prozess-Schritte aus. Dieses Szenario macht Sinn, wenn der Provider nicht überlastet ist oder die auszuführende Aufgabe nicht zu viel Zeit in Anspruch nimmt, wie zum Beispiel die Ausführung einer überschaubaren Berechnung. Mitunter kann der Consumer aber nicht wissen, wie lange die Antwort des Providers auf sich warten lassen wird. Möglicherweise dauert es Stunden, Tage oder gar Monate, weil die Realisierung des Services selbst ein komplexer Prozess ist. In solchen Fällen wird der Service asynchron aufgerufen, d.h. der Provider schickt nach erfolgtem Service Call lediglich eine Empfangsbestätigung und beendet dann vorerst die Kommunikation. Der Consumer führt seinen Prozess weiterhin aus, sofern er hierzu nicht auf die Antwort des Providers angewiesen ist, und irgendwann, zu einem späteren Zeitpunkt, meldet sich der Provider mit dem Ergebnis der erledigten Aufgabe. Diese Meldung findet dann als Aufruf des Consumer durch den Provider statt, weshalb dieser Vorgang auch „Callback“ genannt wird.

Um diese abstrakte Darstellung besser greifbar zu machen, kann man sich Beispiele aus der physischen Welt vor Augen führen: Im Rahmen des jährliches Prozesses der Einkommenssteuererklärung überkommt den Bürger, während er das Formular ausfüllt, eine Idee zur Steueroptimierung. Weil er nicht weiß, ob diese auch legal ist, nimmt er die Beratungsleistung seines Steuerberaters in Anspruch, und ruft diesen kurzerhand an. Technisch gesehen führt er via Telefon einen Service Call durch, wobei er in diesem Call seine Frage als Parameter übergibt, und nun darauf wartet, dass der Steuerberater die Aufgabe des darüber Nachdenkens ausführt, und ihm in seiner Antwort seine Einschätzung der rechtlichen Lage mitteilt. Solange der Bürger am Telefon sitzt und auf die Antwort wartet, unterbricht er das Ausfüllen des Formulars, und sein Prozess ist in einen Wartezustand eingetreten. Es handelt sich also um einen synchronen Service Call.

Hätte der Bürger hingegen damit gerechnet, dass der Steuerberater gerade nicht verfügbar ist oder seine Fragestellung so komplex ist, dass diese eine ausführliche Prüfung erfordert, hätte er seinen Service Call möglicherweise via Email durchgeführt. Dann hätte er, ohne auf die Antwort zu warten, das Ausfüllen seines Formulars fortgesetzt. Irgendwann wäre er an einem Punkt angelangt, wo er die Antwort des Steuerberaters gebraucht hätte, um das Formular zu finalisieren, und wäre in einen Wartezustand eingetreten (zumindest, was diesen Prozess angeht). Technisch gesehen hätte er auf den Callback des Services gewartet, den er zuvor via Email asynchron aufgerufen hätte (Bild 3.19).

Die Nutzung asynchroner Service Calls ist mit einer besonderen Herausforderung verbunden, die sich ebenfalls mit dem skizzierten Beispiel erklären lässt: Die Antwort des Steuerberaters erreicht den Bürger vermutlich ebenfalls per Email. Dieser registriert zunächst den Erhalt und erkennt anhand des Absenders, dass es sich um eine Email seines Steuerberaters handelt, und (für gewöhnlich) anhand des Betreffs, dass sich diese nicht auf die noch offene letzte Honorarabrechnung bezieht, sondern eine Antwort auf die zuvor gestellte Frage ist. Er hat also eine gedankliche Zuordnung der Nachricht zu seinem Prozess vorgenommen. Dieser schlüsselbasierte Zuordnungsvorgang wird Corellation Handling genannt und ist eine unabdingbare, aber auch schwierige Anforderung im Rahmen der Service Orchestrierung.
Einige Service Orchestration Prozesse funktionieren aus der Business-Perspektive nur nach dem Alles-oder-nichts-Prinzip: Es müssen alle Service-Aufrufe erfolgreich durchgeführt werden. Sollte auch nur ein Service-Aufruf fehlschlagen, müssen alle bereits erfolgten Aufrufe rückgängig gemacht werden. Dieses Prinzip der Atomarität dient der Transaktionssicherheit und gilt beispielsweise im Rahmen von Überweisungen:  Wenn im ersten Service Call der Betrag vom Konto A abgebucht wurde, jedoch der zweite Service Call zur Buchung auf Konto B fehlschlägt (zum Beispiel, weil es einen technischen Defekt im Netzwerk gibt), muss der Betrag auf das Konto A zurückgebucht werden, damit das Geld nicht „verloren“ geht. In derart kritischen Szenarien muss für jeden Service, der eine Aktion ausführt, vom Service Provider ein zweiter Service bereitgestellt werden, der genau diese Aktion wieder rückgängig machen kann und durch die Orchestration Engine im Fehlerfall aufgerufen werden kann. Der Umgang mit solchen Szenarien wird für gewöhnlich Compensation Handling genannt.

Die bis hierher vorgestellten Konzepte der

• Prozessorientierte Servicenutzung über Service Orchestration
• Synchrone versus asynchrone Service Calls
• Correlation Handling zur Zuordnung von Callbacks
• Compensation Handling zur Realisierung atomarer Service Orchestrations

sind bei weitem nicht alle, aber die in der Praxis besonders häufigen Aspekte, die es bei der technischen Umsetzung einer SOIA zu beachten gilt. Sie werden in vielen BPM-Suites entweder proprietär oder durch Implementierung von Standards wie z.B. BPMN zur optischen Gestaltung oder BPEL zur technischen Realisierung abgebildet.

Während diese Herausforderungen, wenngleich anspruchsvoll, so doch intellektuell bereits weit durchdrungen sind, existieren weitere, vergleichsweise mangelhaft geklärte Probleme auf der SOIA Ebene. Ein besonders schwieriges Problem bezieht sich auf die sinnvolle fachliche Abgrenzung von Services. Diese Abgrenzung mündet in eine Service Definition, die wiederum Grundlage der Service Implementierung ist. Dieser Prozess ist aufwendig, führt aber, sofern erfolgreich durchlaufen, erst wirklich zum gewünschten Effekt der flexiblen Nutzung von Services, um sie in verschiedenen Prozessen einsetzen zu können bzw. innerhalb eines Prozesses zu verschiedenen Zeitpunkten aufrufen zu können, und somit Prozessänderungen rasch umzusetzen – also genau der Zielsetzung der Integrationsebene, die dynamische Organisationsebene mit der starren Software-Ebene flexibel zu verbinden. Wenn diese organisatorische Ausrichtung fehlschlägt, führt dies im Ergebnis zu starren Services, die nur eine ganz bestimmte fachliche Anforderung abbilden, und nur zu einem ganz bestimmten Zeitpunkt innerhalb eines Prozesses aufgerufen werden können. In der Konsequenz könnten die implementierten Services zwar dank Orchestration Engine relativ schnell neu kombiniert werden, sind aber selbst gar nicht fähig zu unterschiedlichen Kombinationen, weil der Grad der „losen Kopplung“ nicht ausreicht und logische Abhängigkeiten zwischen den Services bestehen, die eine bestimmte Reihenfolge der Ausführung erzwingen, obwohl diese Reihenfolge nicht zwangsläufig der Prozesslogik geschuldet ist.

Für den Prozess der SOIA-gerechten Abgrenzung, Definition und Implementierung von Services gibt es (noch) kein Patentrezept, sondern nur die häufig leidvollen Erfahrungen derjenigen, die ihn bereits durchlaufen haben. Nicht wenige gehen tatsächlich den Weg über die Prozesse: Sie sammeln sämtliche Abläufe, die durch die SOIA zukünftig unterstützt werden sollen, und identifizieren die Gemeinsamkeiten und Unterschiede der jeweils benötigten IT-Unterstützung einzelner Schritte und Aktivitäten. Aus dieser Sammlung entsteht ein Domänenmodell, in dem sich zunächst Gruppen von Services zusammenfassen lassen. Innerhalb der Domänen werden dann einzelne Services voneinander abgegrenzt, wobei es durchaus zu Überlappungen in der bereitgestellten Leistung kommen darf. Die Implementierung dieser sehr grobgranularen Services muss dann auch nicht direkt in Code erfolgen, sondern kann selbst wieder eine Orchestrierung eher feingranularer Services sein – wobei man sehr darauf achten muss, die unterschiedlichen Prozessebenen konsistent aufeinander abzustimmen. So kann es vorkommen, dass ein feingranularer Service in unterschiedlichen grobgranularen Services Verwendung findet.

Sind Services implementiert und publiziert, können sie durch die „Allgemeinheit“ innerhalb, mitunter auch außerhalb des Unternehmens genutzt werden. Aufgrund des dezentralen Charakters einer SOA muss auch nach der Implementierung der Betrieb der Services gewissenhaft betreut werden, weshalb man hier auch vom Service LifeCycle Management spricht. Schließlich darf es nicht passieren, dass ein Service zur Angebotskalkulation, der im Unternehmensbereich A entwickelt und betrieben wird, eines Tages abgeschaltet wird, ohne alle anderen Unternehmensbereiche, die den Service in ihren Prozessen nutzen, rechtzeitig darüber zu informieren. Eine weitere unerwünschte Entwicklung wäre die Einrichtung einer eigenen Angebotskalkulation durch Unternehmensbereich B, weil sie den Service von Bereich A für mangelhaft hält, sodass innerhalb des Unternehmens zwei verschiedene Services für dieselbe fachliche Anforderung existieren. Die Sicherstellung der Serviceverfügbarkeit, die Vermeidung eines Wildwuchses und weitere Aspekte des Service LifeCycle Managements werden im Rahmen einer SOA-Governance organisiert. Doch auch für den Aufbau einer solchen Governance existieren bislang keine standardisierten, wissenschaftlich fundierten und praxiserprobten Verfahren, sondern lediglich die ersten punktuellen Erfahrungen von Unternehmen, die eine SOA größeren Umfangs eingeführt haben.

Abschließend muss konstatiert werden, dass sich SOIA momentan immer noch in einem Prozess der Entdeckung befindet. Zwar haben viele, vor allem größere Unternehmen bereits umfangreiche Projekte zur Steigerung ihrer Agilität durch die Einrichtung einer solchen Ebene angestoßen, und einige haben auch schon erste Erfolge melden können. Aber in der Breite existieren noch nicht ausreichend viele analysierbaren Ergebnisse, um eindeutige Muster für alle auftretenden Herausforderungen ableiten zu können. Wer sich mit der Einrichtung einer SOIA beschäftigt, muss deshalb  Pioniergeist und einen längeren Atem mitbringen, denn es passiert noch vieles nach dem Prinzip „Versuch-und-Irrtum“. Es wird vermutlich noch einige Jahre dauern, bis sich der Erfahrungshorizont im SOIA-Bereich auf dem heutigen Niveau der SOSA-Ebene befindet – diese zunächst negative Feststellung bedeutet natürlich gleichzeitig auch eine Chance für Unternehmen, die als „First-Mover“ eine Agilitätsebene in ihrer Prozesslandschaft entwickeln und somit einen Vorsprung gegenüber ihren Wettbewerbern realisieren wollen.

Die Idee der SOIA-Ebene steht auch in einem direkten Zusammenhang mit der allgemeinen Zusammenführung der Organisations- und IT-Perspektive von Business Process Management. Weitere Herausforderungen und Lösungsansätze in diesem Themenfeld werden in Kapitel 4 beschrieben.

3.3.2.4    SOPA in der Praxis
Zum Thema Service-Orientierung auf Prozessebene gibt es über die allgemeine Zielsetzung hinaus in der Praxis momentan noch nicht viel zu sagen: Die Klärung der wesentlichen Fragen der SOIA-Ebene ist Voraussetzung, um sich überhaupt seriös mit Vorgehensweisen zur Einrichtung einer serviceorientierten Organisation befassen zu können. Deshalb ist es müßig, sich heute bereits die Frage zu stellen, wie man die eigenen Geschäftsprozesse organisatorisch „serviceorientiert“ gestalten kann. Diskussionen und Publikationen zu diesem Thema rutschen derzeit schnell in eher schwammige Diskurse über Kundenorientierung und Dienstleistungsmentalität ab, und münden gern in Forderungen wie „Prozesse müssen als Service gegenüber dem Kunden gestaltet werden, den dieser muss im Mittelpunkt der Betrachtung stehen“. Diese Ambition ist zwar löblich, aber gleichzeitig eine absolute Binsenweisheit und hat mit dem eigentlichen SOA-Paradigma nichts mehr zu tun.

Im Kontext der Anwendungsintegration ist in jüngerer Zeit ein Paradigma der Softwaretechnik zu großer Popularität gelangt: Das Prinzip der serviceorientierten Architektur (SOA). Ein negativer Nebeneffekt dieses Hypes ist die Ausdehnung des Begriffes auf verschiedenste Problemstellungen, was zu allgemeiner Verwirrung und, daraus resultierend, zum Teil sogar Ablehnung  des Themas geführt hat. Aus diesem Grund soll an dieser Stelle zunächst eine Klärung und Abgrenzung des Begriffes vorgenommen werden.
Diese Klärung orientiert sich an der Differenzierung des SOA-Begriffes, die Prof. Dr. Robert Winter vom

Institut für Wirtschaftsinformatik an der Universität St. Gallen vornimmt [WINTER2007].

Die Darstellung im Bild ist angelehnt an das Business Engineering Framework der Universität St. Gallen, die zwischen fünf Ebenen der Unternehmensarchitektur unterscheidet:

•    Die strategische Ebene bezieht sich auf die grundsätzlichen Geschäftsmodelle des Unternehmens.
•    Die organisatorische Ebene beinhaltet u.a. die Gestaltung sämtlicher Geschäftsprozesse eines Unternehmens, insbesondere mit der Ambition der strategischen Ausrichtung
•    Die Integrationsebene (manchmal auch Agilitätsebene) verbindet Business und IT, indem sie die organisatorischen Anforderungen auf die unter ihr liegende
•    Software-Ebene abbildet. Diese Ebene umfasst sämtliche Anwendungen eines Unternehmens.
•    Die Infrastrukturebene wiederum bezieht sich auf die physische IT, also auf die Computer, Netzwerke, Peripheriegeräte etc.

Während die strategische Ebene aufgrund der steigenden Dynamik in den Märkten mittlerweile alle 1-2 Jahre angepasst werden muss, und die organisatorische Ebene sogar alle 3-6 Monate,  können die Ebenen Software- und Infrastruktur lediglich alle 6-10 Jahre, nämlich im Rahmen umfangreicher IT-Entwicklungs- bzw. IT-Beschaffungsprojekte, angepasst werden. In der Folge ist die IT in vielen Unternehmen ein Risiko für die inzwischen geradezu überlebenswichtige Beweglichkeit geworden. Dieses Agilitätsproblem soll zum Einen durch die Gestaltung der Integrationsebene gelöst werden, und ist zum Zweiten die wesentliche Motivation für das SOA-Paradigma. Allerdings unterscheidet Winter ausgehend vom Business Engineering Framework zwischen drei möglichen Ausprägungen der SOA-Diskussion:

Serviceorientierte Software-Architektur (SOSA)
Das Betrachtungsobjekt eines SOSA-Engagements sind die Anwendungen, die mit technischen Schnittstellen (Software-Services) auszurüsten sind. Diese Services kapseln Anwendungsfunktionalität auf relativ feingranularer Ebene. Hauptambition einer SOSA sind Interoperabilität, also die Fähigkeit zur plattformübergreifenden Zusammenarbeit von Anwendungen, und Wiederverwendbarkeit der Services. Im Business Engineering Framework ist SOSA dementsprechend der Software-Ebene zuzuordnen.

Serviceorientierte Integrations-Architektur (SOIA)
Auf der Integrationsebene spielen sich die Aktivitäten zum prozessorientierten Aufbau einer SOA ab. Hier werden die auf der Software-Ebene umzusetzenden fachlichen Services definiert und auf die Organisationsebene ausgerichtet. Die Gestaltungsziele einer SOIA sind dementsprechend Business-IT-Alignment und Flexibilität der Services.

Serviceorientierte Prozessarchitektur (SOPA)
Die Idee der SOPA ist wiederum die Definition von Services auf Organisationsebene, die durch Unternehmensprozesse umgesetzt werden und somit mit maximaler Effektivität und Effizienz gestaltet sein sollen.

Die von Winter vorgeschlagene Differenzierung ist sehr hilfreich, um die vielen verschiedenen öffentlichen Diskussionen, Vorschläge, aber auch die Kritik zu sortieren und zu bewerten, die sich momentan unter dem allgemeinen Schlagwort „SOA“ abspielen, und um einen nüchternen Abgleich mit der Praxis vorzunehmen.
Dieser nun folgende Abgleich basiert auf den Erfahrungen und Schlussfolgerungen der Autoren dieses Buches und soll somit nicht als Auffassung von Winter oder der Universität St. Gallen dargestellt werden, auch wenn hier möglicherweise Übereinstimmungen existieren.

3.3.2.2 SOSA in der Praxis
Betrachtet man zunächst den Bereich „SOSA“, so stößt man heute bereits auf viele erfolgreiche Praxisprojekte. SOSA ist ein sehr technisches Thema, und schon seit einigen Jahren haben sich die im Bereich der „Web Services“ definierten Standards in der Praxis bewährt. Das Basisprinzip von Software-Services ist das Zusammenspiel von Service-Provider, Service-Consumer und Service-Verzeichnis.

Der Consumer, also eine Anwendung, ruft einen von einem Provider, also einer anderen Anwendung, bereitgestellten Web Service auf (Bild). Der Kanal für diesen Aufruf ist in der Regel HTTP (Hypertext Transfer Protocol), bzw. das verschlüsselte und mit Authentifizierung versehene HTTPS (HTTP Secure). Prinzipiell können aber auch andere Kanäle genutzt werden, wie zum Beispiel SMTP (Simple Mail Transfer Protocol), der auch für den Versand von Emails benutzt wird. Der Provider führt die mit dem Service verbundene Funktion aus und gibt das Ergebnis an den aufrufenden Consumer zurück. Dieser Nachrichtenaustausch basiert häufig, aber nicht zwangsläufig, auf dem sogenannten SOAP-Protocol. Die Beschreibung des Services, die vom Provider veröffentlicht wird und durch den Consumer vor einem Aufruf gelesen werden muss, enthält die „Leistungsbeschreibung“ sowie die notwendigen Parameter, die der Consumer in seiner Anfrage übergeben muss, damit der Service ausgeführt werden kann. Diese Beschreibung wird in WSDL-Dateien bereitgestellt (Web Service Description Language). Beide Standards zur Realisierung von Web Services basieren ihrerseits auf XML. Proportional zur Komplexität der SOA steigt auch die Bedeutung eines Verzeichnisses, das die definierten Services verwaltet, eine sogenannte Service-Registry. Dieses Registry kann von einem interessierten Service-Consumer ähnlich wie ein Telefonbuch benutzt werden, um die Adressen von Services zu ermitteln, die Leistungen bereitstellen, die der Consumer benötigt. Im Kontext von Web Services wurden solche Verzeichnisse anfangs mit Hilfe des ebenfalls XML-basierten Standards UDDI (Universal Description, Discovery and Integration) aufgebaut, der sich jedoch im Gegensatz zu SOAP und WSDL auf breiter Front bislang nicht wirklich durchsetzen konnte.

Mittlerweile existieren viele weitere Standards und Frameworks, die spezielle Aspekte einer Web Services – Architektur adressieren, wie zum Beispiel das Thema Sicherheit. Wesentlich für das Verständnis aus übergeordneter Perspektive ist jedoch lediglich dieses relativ einfache Basisprinzip.
Das Gedanke hinter der SOA-Umsetzung mittels Web Services ist auch Teil des allgemeinen Strebens nach Modularisierung in der klassischen Programmierung, indem Programmlogik in Funktionen oder Methoden zusammengefasst wird, die dann aus verschiedenen anderen Programmteilen heraus aufgerufen werden können. Auch die programmiersprachenübergreifende Modularisierung von Code wird bereits seit Jahrzehnten unternommen – ein relativ bekannter Ansatz ist der bereits 1991 veröffentlichte CORBA-Standard. In der Folge ist das SOA- bzw. SOSA-Paradigma an sich nicht neu, wohl aber die Realisierung mittels Web Services, die sich gegenüber früheren Versuchen wie CORBA auf breiter Front durchsetzen konnte. Diese Differenzierung ist wichtig, um Kritikern begegnen zu können, die SOA zu Unrecht als „alten Wein in neuen Schläuchen“ diskreditieren wollen.

Insgesamt sind die Potentiale und Herausforderungen, die mit reinen SOSA-Projekten verbunden sind, heutzutage weitestgehend erforscht und bekannt, sodass eine umfangreiche Praxisreife erreicht wurde. Das bedeutet nicht, dass  SOSA trivial wäre. Im Gegenteil, der auf Aufbau und Betrieb einer sauberen SOA auf Software-Ebene ist außerordentlich anspruchsvoll und muss von hochgradig kompetenten IT-Architekten verantwortet werden, und es existieren zahlreiche wissenschaftliche und praktische Fachbücher, die sich allein diesem Thema widmen. Der Bezug zum Geschäftsprozessmanagement ist jedoch nicht wirklich vorhanden, denn dieser wird auf der SOIA-Ebene hergestellt. Insofern ist auch die mitunter zu hörende Aussage unsinnig, SOA könne ohne Prozessmanagement nicht effektiv funktionieren – eine SOA auf reiner Software-Ebene kann das sehr wohl.

Thema des nächsten Beitrags: SOIA und SOPA

Zu dem Thema kann man natürlich geteilter Meinung sein, an dieser Stelle möchte ich aber nur mal auf zwei Studien aufmerksam machen, die vor nicht allzulanger Zeit in Deutschland entstanden sind:

Die Erste ist eine Expertenbefragung zu den Nutzenpotentialen serviceorientierter Architekturen, für die auch ich mich vor einiger Zeit zur Verfügung gestellt hatte. Der Bericht wurde von Alexander Becker an der TU Darmstadt im Rahmen seiner Dissertation erstellt. Für mich haben die Ergebnisse zwar nicht soviel Neues enthalten, aber für manch einen ist es vielleicht interessant zu erfahren, dass der Agilitätsnutzen von sehr viel mehr Experten wahrgenommen wird, als der Nutzen der Wiederverwendung von Services (ich selbst gehöre auch zu dieser “Fraktion”).

Das zweite Dokument ist eine komplette Dissertation mit dem Titel Die organisatorische Bedeutung von “Service Oriented Architectures”. Sie wurde von Sebastian Remer erstellt, und das zufälligerweise ebenfalls an der TU Darmstadt. Das interessante hierbei ist das Fachgebiet, es handelt sich nämlich um eine Doktorarbeit in Sozialwissenschaften. Dementsprechend ist das Ganze natürlich etwas “weicher” als eine Arbeit aus dem Gebiet der Informatik. Sie liefert aber durchaus interessante neue Perspektiven auf das Thema und kann deshalb als Blick über den Tellerrand genutzt werden.