Java in der Telekommunikation - Auftragsverwaltung API

In den beiden vorangegangenen Folgen dieser Serie haben wir die Position von Java in der Telekommunikationsbranche, das Telemanagement Forum und die Grundlagen von OSS/J beschrieben. Diese Folge konzentriert sich auf die Order Management API (JSR 264), eine der OSS/J-APIs, die im Rahmen des JCP-Prozesses entwickelt werden (der vorgeschlagene endgültige Entwurf 2 wird im Mai/Juni '07 veröffentlicht). Es ist auch die API, die wir in der letzten Woche auf der JavaOne behandelt haben .

Die Auftragsverwaltung ist ein weit verbreiteter Prozess und praktisch jedes Unternehmen führt eine Art Auftragsverwaltung durch, um sicherzustellen, dass es die Anfragen seiner Kunden bearbeiten und das gewünschte Produkt (z.B. Buch, Auto, Führerschein) oder die gewünschte Dienstleistung (z.B. Telefonie, Krankenversicherung, Fernsehen) liefern kann. Die Order Management API ist (soweit wir wissen) die einzige offene und auf Standards basierende API, die für die Auftragsverwaltung verfügbar ist, und ist daher für viele Unternehmen relevant, die eine Auftragsverwaltungslösung entwickeln (nicht nur für die Telekommunikation). Wenn Sie diese API als Grundlage für Ihre Auftragsverwaltungslösung verwenden, können Sie das Wissen anderer wiederverwenden (und müssen das Rad nicht neu erfinden) und Ihre Integrationskosten senken.

Die wichtigsten Funktionen sind:

• Unterstützt sowohl einfache als auch komplexe Anwendungsfälle

• Unterstützt lang laufende Transaktionen

• Definiert die verwalteten Entitäten, mit denen die Vorgänge der Auftragsverwaltung arbeiten (Auftrag, OrderItems usw.). Diese sind eine Erweiterung des gemeinsamen Informations-/Datenmodells des Telemanagement-Forums. Die aus dem TMF-SID verwendeten Elemente sind die nicht telekommunikationsspezifischen.

• Definiert das (erweiterbare) Zustandsmodell für Orders.

• Unterstützung beim Erstellen, Starten, Aktualisieren und Entfernen von Aufträgen.

• Unterstützung für Massenoperationen zum Erstellen, Aktualisieren und Entfernen von Aufträgen. Diese sind in einer atomaren (alle müssen erfolgreich sein) oder einer Best-Effort-Variante (fehlgeschlagene Aufträge werden zurückgemeldet) verfügbar.

• Unterstützung für Benachrichtigungen, um Kunden über den Fortschritt eines Auftrags zu informieren (nicht nur Kunden, die einen Auftrag erteilt haben, sondern auch andere interessierte Kunden).

• Benachrichtigungen, die den Kunden um die Validierung bestimmter Aspekte der Bestellung bitten (bevor die Bearbeitung fortgesetzt wird).

• Benachrichtigungen, die den Client um zusätzliche Eingaben bitten (bevor er die Verarbeitung fortsetzt).

• Erweiterbarkeit. Die Auftragstypen (und alle Inhalte) und die Auftragsstatus können für Ihre speziellen Bedürfnisse erweitert werden.

• Flexible Abfragemöglichkeiten wie Abfrage nach Schlüssel, Abfrage auf der Grundlage einer Vorlage und Definition benannter Abfragen (vergleichbar mit JDBC Prepared Statements).

• Unterstützung für statische und dynamische Typisierung von Attributen einer Bestellung.

• Unterstützen Sie Meta-Operationen, die es einem Client beispielsweise ermöglichen, zur Laufzeit herauszufinden, welche Aufträge verfügbar sind.

Die Auftragsverwaltungs-API ist nicht an telekommunikationsspezifische Aufträge gebunden. Die API ermöglicht die Definition eigener Auftragstypen und kann somit an die spezifischen Bedürfnisse anderer Branchen angepasst werden. Um sicherzustellen, dass die von der API für die Auftragsverwaltung angebotenen Operationen nicht an eine bestimmte Branche gebunden sind, wurde ein allgemeiner Typ 'Anfrage' definiert. Dieser Anfragetyp ist der Supertyp aller Aufträge und alle Vorgänge der Order Management API beziehen sich auf Anfragen. Es ist möglich, eigene Auftragstypen als Untertyp von Anfrage oder als Untertyp eines der vier vordefinierten Untertypen von Anfrage zu definieren: ProductOrder, ServiceOrder, ResourceOrder, WorkOrder (letzteres erfordert einen menschlichen Eingriff).

"Alles schön und gut", werden Sie denken, "aber kann ich das nicht auch mit BPEL erreichen?". Aus funktionaler Sicht könnten Sie die gleiche Funktionalität mit BPEL (oder vielen anderen Technologien) realisieren, allerdings würden Sie Ihre eigene API erfinden, anstatt auf einer standardbasierten aufzubauen. BPEL bietet zum Beispiel kein standardisiertes Informationsmodell, Zustandsmodell oder eine Reihe von Operationen. Sie müssten diese selbst definieren und würden damit eine proprietäre Lösung schaffen. Der Vorteil der geringeren Integrationskosten geht dabei verloren.