Die Anforderungen an Softwaresysteme steigen stetig. Die Suche nach neuen Techniken und Architekturen führte immer wieder zu neuen Lösungsansätzen. Insbesondere die Integration der verschiedenen Applikationen blieb jedoch bisher meist unzureichend. Mit der serviceorientierten Architektur (SOA) entsteht nun anstatt einer Entwicklungstechnologie eine Integrationstechnologie. Funktionen sollen nicht mehr ständig und von Grund auf neu entwickelt, sondern mit geringem Aufwand integriert werden. Entsprechende Schnittstellen sollen das System befähigen, organisch zu wachsen, indem die einzelnen Softwarebausteine unabhängig funktionieren und ausgetauscht werden können. Dies bedeutet eine Flexibilisierung von komplexen Unternehmensarchitekturen.

Die Kunden wünschen sich heute Softwareprodukte mitsamt Services, welche auf ihre Bedürfnisse zugeschnitten sind. Dies ist mit den klassischen Softwarearchitekturen nicht möglich. Informatiker programmieren meist strukturiert und modular, um so flexible, überschaubare und langlebige Software zu entwickeln. Wenn man aber die bestehenden Applikationen betrachtet, stellt man fest, dass diese längst nicht immer modular und die Codes jeweils zu 40 bis 60 Prozent redundant sind.

Die objektorientierte Softwareentwicklung war ein erster Schritt vom monolithischen zum organischen Softwaresystem. Leider wurden die Erwartungen an die objektorientierte Softwareentwicklung betreffend Wiederverwendbarkeit von einzelnen Objekten nicht erfüllt. Einerseits weil Objekte oder Klassen als Einheiten zur Wiederverwendung zu klein waren und keine vollständige Business Aktivität in einem Geschäftsprozess abdecken konnten. Andererseits weil die Unternehmen die dafür erforderlichen organisatorischen Massnahmen nicht ergriffen haben.

Das aktuelle Schlagwort der IT-Branche heisst serviceorientierte Architektur (SOA). Das neuartige Architekturkonzept geht von der allgemeinen Idee «Software als Service» aus. SOA stellt nicht einfach eine Technologie dar, sondern vielmehr einen grundsätzlichen, konzeptionellen Ansatz zur effizienten Realisierung komplexer IT-Systeme. SOA wird oft mit Web-Services in Verbindung gebracht. Diese bieten zwar eine geeignete Basis, um die SOA zu realisieren, eine Kombination ist jedoch keinesfalls zwingend. Eine SOA lässt sich auch mit anderen Technologien wie beispielsweise EJB (Enterprise Java Beans) umsetzen. SOA versprechen Wiederverwendbarkeit. Namentlich in Form einzelner Services des Systems und ihres Zusammenspiels. Unabhängig von der konkreten technologischen Umsetzung sind die einzelnen Services Softwarebausteine, die eine eigenständige Funktionalität beinhalten und eine abgrenzbare Aufgabe übernehmen können.

Neue Herausforderung

Auch die Eidgenössische Zollverwaltung (EZV) ist stets auf der Suche nach neuen Techniken und Architekturen, um den steigenden Anforderungen gerecht zu werden. Dabei ist sie auf den Lösungsansatz SOA gestossen. Die EZV wickelt ihre unterschiedlichen Zollgeschäfte seit Anfang der 90er-Jahre über verschiedene Plattformen (M90A, M90E, NCTS) ab. Das neue Produkt E-Dec ist aus der Idee eines Frachtportals als Gesamtprodukt für die Zollabfertigung von Import-, Transit- und Exportwaren entstanden. E-dec ist eine umfassende Plattform für sämtliche Warenabfertigungen - für alle Verkehrskanäle und in alle Richtungen. In Zukunft werden alle Beteiligten ihre Zollgeschäfte auf dieser einen Plattform abwickeln. E-Dec ist eine E-Government-Applikation und beinhaltet sowohl G2B- (Government to Business) als auch B2G- (Business to Government) Prozesse. Die EZV wollte ihre Bedürfnisse mit einer zukunftsorientierten Architektur abdecken. E-dec soll möglichst flexibel, personal-unabhängig, erweiterbar und langlebig sein. Darüber hinaus soll das neue Produkt einen kostengünstigen Betrieb und eine ebensolche Wartung gewährleisten. Um diese Anforderungen zu erfüllen hat das Projektteam auf neue Technologien gesetzt.

E-dec ist eine Kombination der Architekturen J2EE (Java 2 Plattform, Enterprise Edition) und SOA und setzt auf XML (Extended Markup Language), einen offenen Standard, der den Datenaustausch über standardisierte Schnittstellen ermöglicht. Das funktioniert in etwa so: Die Zollkunden melden ihre Warenlieferungen elektronisch an und ihre Daten werden sogleich über E-Dec durch verschiedene Services verarbeitet. Sobald alles in Ordnung ist, erhalten die Zollkunden ihre Zollpapiere elektronisch im XML-Format und als PDF-Datei - und schon sind die Waren verzollt und die Fahrt kann weitergehen.

Die Zollfachleute können über eine Web-Applikation die Waren- und Datenströme steuern oder die Daten nach den unterschiedlichsten Kriterien auswerten. Auch die Bundesämter profitieren von den Services. Täglich bekommen sie von E-Dec die gewünschten Daten.

Das E-Dec System besteht aus drei Hauptbestandteilen: E-Dec Flow, E-Dec Core und E-Dec Datenlagerung. Die folgenden Architekturprinzipien wurden in E-Dec berücksichtigt: SOA, Asynchrone Messaging und 5-Tier J2EE Architektur (Client, Präsentation, Integration, Business Logik, und Datenhaltung) E-dec Flow dient sowohl für die G2B- als auch für die B2G-Geschäfte als Schnittstelle. Sie bietet Importeuren und Exporteuren, Grosshändlern sowie Spediteuren die Möglichkeit, Verzollungsgeschäfte über E-Dec Services abzuwickeln. Die Kommunikation zwischen E-Dec und den Partnern läuft via Internet (E-Mail und künftig Web Service).

E-Dec Flow ist gleichzeitig auch ein Messaging System. Es baut auf MQ (Message Queueing) und ESB (Enterprise Service Bus) auf. Als Messaging Standard wird JMS (Java Message Service) benutzt. Die Daten werden mit sicheren Schnittstellen (Public Key Infrastructure (PKI)) im XML-Format ausgetauscht. Der Enterprise Service Bus dient der Definition von Abläufen und dem Aufruf von Services innerhalb dieser Prozesse. In dieser Schicht werden beispielsweise der Konvertierungsservice, der Validierungsservice, der Authentisierungs- und Authorisierungsservice sowie der Datenlieferungsservice aufgerufen. Diese Services sind nicht zollspezifisch. Alle fachspezifischen Services laufen auf der Ebene E-Dec Core. Über eine asynchrone Schnittstelle (Message Queue) werden die Verzollungsservices angestossen. E-Dec Flow übernimmt alle Kommunikations- und Integrationsaktivitäten mit den Umsystemen und stellt somit die Integrationsschicht des gesamten Systems dar.

E-dec Core wurde auf einer 5-Tier-J2EE-Plattform gebaut. Wie der Name sagt, werden hier Core- oder Kerngeschäfte von Import-Warendeklarationen realisiert, insbesondere der Verzollungsservice. Beim automatischen Verzollungsprozess werden verschiedene Geschäftsaktivitäten durchlaufen, die als Services implementiert sind. Unter anderem sind dies die Prüfung der fachlichen Plausibilität einer Zollanmeldung, die so genannte Selektion (Risikoanalyse) und die Abgabenberechnung. Diese Services wurden mit EJB (Enterprise Jave Beans) erstellt und werden über eine Web-Applikation von Zollfachpersonen verwendet.

Nach dem Motto «so standardisiert wie möglich, so individuell wie nötig» realisierten die Fachleute des Bundesamtes für In-formatik BIT mit den EZV-Experten die zollspezifischen Business Cases selber und in-tegrierten die auf dem Markt erhältlichen Komponenten und Werkzeuge in E-Dec Core. Ein Beispiel dafür ist der Risikoanalyse-Service, bei dem eine Business Rule Engine (BRE) zum Einsatz kommt. Diese ermöglicht den Zoll-Fachpersonen, die beliebige Anpassung von Geschäftsregeln. Dadurch wird die Flexibilität der Applikation erhöht, denn der Programmcode braucht nicht mehr von einem Informatiker angepasst zu werden.

Die Resource-Schicht von E-Dec wird über eine relationale Datenbank betrieben. Alle Verzollungsdaten werden in einer Oracle Datenbank abgelegt und täglich in einen Operational Data Store (ODS) verschoben. Bestimmte Daten werden so mit einem Business Intelligence Tool analysiert. Zudem werden Reports generiert. Die Daten werden für Bundesämter und weitere Empfänger zugänglich gemacht oder direkt an die Empfänger verschickt.

E-dec wurde aus mehreren Software-Services erstellt. Neben informatiktechnischen Services ergänzen mehrere zollspezifische Services das System. Diese so genannten Business Oriented Services können die Aufgabe einer vollständigen Business Aktivität in einem Geschäftsprozess übernehmen. Heute hat die EZV die Möglichkeit, neue Anwendungen aus bereits existierenden Services zusammen zu setzen oder zu in-tegrieren. Aus den gleichen Software-Services kann E-Dec Import, E-Dec Export und E-Dec Transit realisiert werden.

E-dec ermöglicht durch den Einsatz von modernen Technologien wie Business Rule Engine eine grössere Transparenz im zolltechnischen Regelwerk und vereinfacht dadurch die Wartung. Heute können im System E-Dec die Geschäftsregeln durch Benutzer bei der EZV unterhalten werden. Mit dem Einsatz einer solchen BRE bei den Kriterien der Risikoanalyse (Selektionsregeln) entsteht ein komfortables Web-Interface, welches der grossen Anzahl Benutzer den Umgang mit Business Rules erleichtert.

Die Benutzer wollen jederzeit Zugriff auf die gewünschten Informationen eines IT Systems und die Unternehmer wollen einen zügigen Datenfluss. Dies fordert immer komplexere Businessprozesse und verursacht eine Mehrzahl Schnittstellen im IT-System, was in der Vergangenheit zur Entwicklung von monolithischen Systemen führte. Heute kann sich die EZV dank einer SOA auf ihr Kerngeschäft - die so genannten E-Dec Core-Services - konzentrieren. Diese erledigen Verzollungsprozesse, ohne mit den Umsystemen konfrontiert zu werden. Die Kommunikation mit und die Integration ins Gesamtsystem wurde von E-Dec Flow über ESB Services realisiert. So ist das Kerngeschäft von der Umgebungskomplexität verschont geblieben.

Der Autor, Turabi Köse, ist Projektmanager E-Dec beim Bundesamt für Informatik und Telekommunikation