JSR264 Auftragsverwaltung API veröffentlicht!

Die Order Management API 1.0 ist veröffentlicht worden. Die Order Management API ist (soweit wir in der JSR264 Expert Group (EG) wissen) die einzige offene und auf Standards basierende API, die für die Auftragsverwaltung zur Verfügung steht und für jede Organisation, die eine Auftragsverwaltungslösung entwickelt, relevant ist. Wenn Sie diese API als Grundlage für Ihre Auftragsverwaltungslösung verwenden, können Sie das Wissen anderer wiederverwenden (und müssen nicht das Rad neu erfinden), Ihre Integrationskosten senken und eine flexible Auftragsverwaltungslösung erstellen. In einem früheren Blogbeitrag habe ich die Funktionen der API bereits ausführlich beschrieben, daher wiederhole ich nur die wichtigsten Funktionen: Die JSR264-Spezifikation können Sie von der JCP-Website herunterladen. Die Referenzimplementierung (RI) und das Technology Compatibility Kit (TCK) sind auf der Website des TelemanagementForum verfügbar. Weitere Informationen zu JSR264 finden Sie auf der JSR264 java.net-Website.

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. Obwohl die Order Management API aus der OSS/J-Familie von APIs stammt (die sich an Kommunikationsdienstleister richten), haben wir sichergestellt, dass die API nicht auf diese Branche beschränkt ist.

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 Bestellungen.
• 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.

Während meiner Teilnahme an der JSR264 Expert Group (EG) war ich in der glücklichen Lage, bei einem Kunden tätig zu sein, der die Nutzung von OSS/J-basierten APIs verstärken wollte. Bei diesem Kunden haben wir zusammen mit einem seiner Lieferanten eine Lösung auf der Grundlage der Entwürfe der Order Management API entwickelt. Der große Vorteil für mich war, dass ich die Theorie der JSR 264 EG mit den praktischen Erfahrungen aus dem Kundenprojekt kombinieren konnte. Dies war sowohl für den Kunden als auch für die JSR264 EG von Vorteil. Ein wenig Hintergrundwissen über den Weg zur Version 1.0.... Das JCP definiert die Meilensteine und Ergebnisse (Spezifikation, Referenzimplementierung (RI), Technologiekompatibilitätskit (TCK)), die jede EG für einen Java Specification Request (JSR) liefern muss, aber es definiert nicht, wie sich eine EG intern organisieren sollte. In unserem Fall haben wir Scrum verwendet. Die Herausforderungen, denen wir gegenüberstanden, waren:

• Die Mitglieder der Gruppe waren über den ganzen Globus verteilt (Europa, USA/Kanada, Australien) und arbeiteten für verschiedene Unternehmen.
• Jeder in der EG hat das auf Teilzeitbasis gemacht. Die meisten von ihnen taten es neben ihrer regulären Arbeit. Einige Leute hatten von ihren Arbeitgebern Zeit für den JSR zugewiesen bekommen, aber das waren nie mehr als 2 Tage pro Woche. Es war schwierig, die Arbeitszeiten zu synchronisieren.
• Das Kernteam bestand aus etwa 5 Personen, und da jeder nur eine begrenzte Zeit zur Verfügung hatte, fühlte sich der Fortschritt manchmal langsam an.
• Es gab keinen Produktverantwortlichen.

Um dies zu bewältigen, müssen wir:

• Der Verantwortliche für die Spezifikationen(Andreas Ebbert-Karroum) des JSR fungierte als Product Owner.
• Wir haben kurze 2-Wochen-Sprints verwendet, so dass wir uns schnell anpassen konnten und trotzdem in einem Sprint etwas Arbeit erledigen konnten.
• Wir hatten 2 Scrum Calls pro Woche, einen am (europäischen) Morgen und einen am (europäischen) Abend, so dass Leute aus allen Zeitzonen zumindest einmal teilnehmen konnten. Während der letzten paar Sprints hatten wir tägliche Scrum Calls.
• Die Aufgaben aus dem Backlog wurden so zugewiesen, dass Personen in derselben Zeitzone an denselben oder verwandten Aufgaben arbeiteten (in der Regel rund um RI, TCK, Spezifikationsdokumentation).
• Ich habe oft Instant Messaging benutzt.
• Wir beendeten jeden Sprint am Freitag mit einem 2-stündigen kombinierten Retrospektiv-/Planungsgespräch.
• Alle 8 Wochen fand ein persönlicher Workshop in Düsseldorf statt. An diesem Workshop nahmen nur die EG-Mitglieder teil, die leicht dorthin reisen konnten, aber er war wichtig, um die Ansichten abzustimmen und Themen eingehend zu diskutieren.

28 Sprints, hunderte von Telefonkonferenzen, mehr als 3600 E-Mails und voilà, die Spezifikation für das Order Management hat den JCP Ballot bestanden. Alles in allem ist und war es eine großartige Erfahrung, an dieser Spezifikation zu arbeiten. Es ist eine perfekte Möglichkeit, Ihr Netzwerk zu erweitern, von anderen zu lernen, Ihr Unternehmen und sich selbst zu vermarkten. Und ja, Artur Uzieblo hatte Recht, als er mir sagte, dass "es mehr harte Arbeit als Ruhm ist"... zumindest was den Teil "harte Arbeit" angeht. Ich muss mich auch bei Xebia dafür bedanken, dass ich an dieser Spezifikation mitarbeiten durfte, denn ohne die zugewiesene Zeit aus dem Xebia Tasking-Budget wäre ich nicht in der Lage gewesen, so viel mitzumachen, wie ich es getan habe. Ich würde es wieder tun... auf jeden Fall!