JAIN™ & JAIN™ SLEE FAQ

Manche Fragen bleiben offen bei JAIN™, JAIN™ SLEE und damit zusammenhängenden Technologien. Einige davon werden hier beantwortet.

Frage: Was bedeutet JAIN™?

Die Abkürzung "JAIN™" bedeutete "Java™ APIs for Intelligent Networks", was auf gut Deutsch so etwas heißt wie "Java™ Programmierschnittstellen für Intelligente Netzwerke".
Netzwerke beziehen sich hier im Wesentlichen auf Kommunikationsnetzwerke im Bereich der Telekommunikation. JAIN™ ist ein eingetragenes Markenzeichen der Firma SUN Microsystems, die auch Rechte an der Programmiersprache Java™ selber besitzt.
Die JAIN™ Initiative wurde ursprünglich von SUN Microsystems gegründet (Douglas Tait) und hat sich als Ziel gesetzt Java™ Programmierschnittstellen zu entwickeln, um netzwerknahe Dienste und Anwendungen zu entwerfen, zu entwickeln und letztlich auch zu betreiben. JAIN™ hat sich zu einer Industrieinitiative entwickelt und wird nun von Partnern und Softwareexperten weiterentwickelt.
JAIN™ hat sich zum Ziel gesetzt speziell diese Java™ typischen Ziele auch im Bereich der Netzwerke durchzusetzen:

• Portierbarkeit von Anwendungen und Diensten - Write Once, Run Anywhere
• Unabhängigkeit vom Netzwerk - Any Network
• Netzwerkbetreiber - By Anyone

Frage: Was umfasst JAIN™?

JAIN™ umfasst eine Vielzahl an Aktivitäten auf verschiedenen Ebenen: Definition von Protokollabstraktionen, Definition von Abstraktionen zur Anrufssteuerung (CallControl), Definition von Vorgehensweisen zur Diensterstellung (Service Creation), Definition von Programmierschnittstellen zur Verwaltung und für den Zugriff auf ENUM Verzeichnisse und letztlich die Definition einer Laufzeitumgebung im netzwerknahen Bereich (JAIN™ SLEE).
Derzeit umfasst die JAIN™ Initiative folgende JSRs:

Protokollabstraktionen	Status	Latest Activity
TCAP [JSR-11]	Final	Oct 2001
ISUP [JSR-17]	Withdrawn	-
Megaco [JSR-79]	Final	Dec 2004
MAP [JSR-29]	Withdrawn	-
MAP [JSR-137]	Withdrawn	-
SIP [JSR-32]	Final	Nov 2006
SIP Lite [JSR-125]	Withdrawn	-
INAP [JSR-35]	Final	Mar 2002
MGCP [JSR-23]	Final	Oct 2001
H.323 [JSR-81]	Withdrawn	-

Anrufsteuerung (CallControl)	Status	Latest Activity
JCC [JSR-21]	Final	Jul 2002
JCAT [JSR-122]	In Progress	Aug 2003

Diensterstellung (Service Creation)	Status	Latest Activity
SCE [JSR-100]	In Progress	Oct 2002
SCE [JSR-192]	Withdrawn	-

Sonstige	Status	Latest Activity
OAM [JSR-18]	Final	Sep 2000
OAM [JSR-132]	Withdrawn	-
ENUM [JSR-161]	In Progress	May 2004

Laufzeitumgebung (Execution Environment)	Status	Latest Activity
SIP Servlet [JSR-116]	Final	Mar 2003
SIP Servlet v1.1 [JSR-289]	In Progress	Jan 2007
JAIN™ SLEE [JSR-22]	Final	Mar 2004
JAIN™ SLEE v1.1 [JSR-240]	In Progress	Feb 2007

Frage: Wo wird JAIN™ definiert?

JAIN™ wird durch Java Specification Requests (JSRs) im Java Community Process (JCP) definiert.

Frage: Was bedeutet JAIN™ SLEE?

SLEE steht für "Service Logic Execution Environment", was auf Deutsch etwa "Laufzeitumgebung für Dienstelogik" heißt. SLEEs sind in der Telekommunikationsindustrie im Netzwerkbereich Synonyme für Plattformen, die in der Lage sind generische Logik auszuführen, die durch Netzwerkereignisse ausgelöst wird. Nach der Bearbeitung der Dienstlogik wird eine Protokollnachricht generiert, die dann wiederum eine Aktion im Netzwerk auslöst. Derzeit sind "Intelligent Network" Platformen (IN) typische Vertreter dieser Plattformen.
Neu an JAIN™ SLEE ist, dass diese Plattformen in Java™ implementiert und erweitert werden können.
"JSLEE" ist übrigens ein typisch gebrauchtes Akronym für JAIN™ SLEE.

Frage: Was ist JAIN™ SLEE?

Der JAIN™ SLEE Standard definiert eine Java™-basierte, komponentenorientierte und transaktionsgestützte Laufzeitumgebung, die explizit für den Einsatz im Bereich der Intelligenten Netze in der Telekommunikationsindustrie entworfen wurde. Oberstes Designziel war es niedrige Latenzzeiten und den geforderten hohen Durchsatz von Kommunikationsnetzwerken zu erreichen. JAIN™ SLEE enthält ein ereignisgesteuertes und -optimiertes Laufzeitmodell, das bewährte Konzepte aus dem Unternehmensbereich (J2EE™) aufgreift und basierend auf Komponenten eine Entkopplung von Diensten vom darunterliegenden Netzwerk durch das Konzept von Ressource Adaptern erlaubt.
Mehr Informationen und ein ausführliches Tutorial zu JAIN™ SLEE gibt's hier: JAIN™ SLEE Tutorial.

Frage: Warum JAIN™ SLEE?

Im Vergleich zur Unternehmenssoftwareentwicklung schreiten Entwicklungen im Bereich von Telekommunikationsunternehmen eher langsam voran. Lange wird an Bestehendem festgehalten und auf antiquierte Vorgehensmodelle gesetzt. Dennoch, gestützt durch die Annäherung von Telekommunikations- und Unternehmensapplikationen, halten neuere Methoden Einzug.
Die Einführung von JAIN™ SLEE findet seine Hauptmotivation im Trend hin zu komponentenbasierten Architekturen, die idealerweise auf offenen Standards beruhen und auf nicht-proprietären Plattformen implementiert werden. Darüberhinaus ermöglicht JAIN™ SLEE eine Netzwerkabstraktionsebene, die die Komplexität von gewachsenen Netzwerken und deren Eigenheiten vor Diensten versteckt.

Frage: Ist JAIN™ SLEE reif für den Einsatz in Unternehmen?

Derzeit wird JAIN™ SLEE als "emerging technology" im Telekommunikationssektor wahrgenommen. Es gibt einige Unternehmen, die JAIN™ SLEE Applikationsumgebungen anbieten. Eine Herstellerauswahl ist auf der SUN Homepage zu finden.

Frage: Was passiert in der Standardisierung?

Der JSR-22 ist seit dem 3. März 2004 abgeschlossen. Die Spezifikation der JAIN™ SLEE Version 1.0 kann auf der JCP-Homepage heruntergeladen werden. Die Spezifikation ist nicht einfach zu lesen und richtet sich im Wesentlichen an Hersteller von Plattformen, die den JAIN™ SLEE Standard implementieren. Auf rund 300 Seiten sind fast alle relevanten Element der Laufzeitumgebung definiert. Lediglich eine einheitliche Ressourcen Adapter Architektur fehlte und einige Feinheiten waren zu ändern. Firmen, die beim JSR-22 mitgemacht haben waren: 8x8, Fujitsu, IBM, Incomit, Motorola, Nortel Networks, NTT, OpenCloud, Personeta, Telcordia Technologies, TrueTel, Siemens, Sun und Vodafone.

Seit dem 14. Januar 2005 ist die Spezifikation für JAIN™ SLEE Version 1.1 im "Early Draft Review". Auf der JCP-Homepage können also alle Interessierten die Spezifikation herunterladen, durchsehen und Kommentare an die Expert Group des JSR-240 mailen. Mitte 2005 soll der JSR-240 abgeschlossen sein. Das Hauptthema sind die Architektur der Ressourcen Adapter und die Integration von J2EE&rade; und JAIN™ SLEE. Firmen im JSR-240 sind: AePONA, BEA Systems, Cingular Wireless, Instituto de Telecomunicacoes, JBoss, jNETx, Lucent, Net4Call, NIST, Nokia, Nortel Networks, NTT Data, Mobilkom Austria, Telecom Italia, TrueTel, OpenCloud, Personeta, Sun und Vodafone.

Teil der Standardisierung ist das Technology Compatibilty Kit (TCK) und die Reference Implementation (RI). Das TCK verwenden Hersteller, die den Standard umgesetzt haben, um nachzuweisen, dass deren Implementierung auch wirklch kompatibel ist. Die Referenzimplementierung wird vom Specification Lead, also dem Vorsitzenden der Expertgruppe, erstellt und hat den Zweck, nachzuweisen, dass die Spezifikation auch wirklich umsetzbar ist. Interessant am RI ist, dass es normalerweise kostenlos zur Verfügung gestellt wird und Interessierte damit experimentieren können. Die RI für JAIN™ SLEE kann man hier herunterladen.

Frage: Wo kann JAIN™ SLEE angewendet werden?

JAIN™ SLEE Applikationsserver werden derzeit von der Industrie als generische Anwendungsplattformen in Telekommunikationsnetzwerken diskutiert. Einsatzgebiete sind vornehmlich die Ersetzung von existierenden IN Systemen. JAIN™ SLEE ist per Design als Ersatz für IN Platformen gedacht und greift den Grundgedanken des IN Netzes auf - Call State Models. Basierend auf dieser Netzwerkansicht definiert sich auch der Einsatzbereich der Technologie.

Frage: Wo ist JAIN™ SLEE nicht optimal anzuwenden?

JAIN™ SLEE Applikationsserver setzen auf das traditionelle IN Netzmodell auf und stellen Service Creation Points für Service Switching Points dar. Diese Ansicht folgt dem IN Modell. Der Applicationsserver reagiert auf Ereignisse aus dem Netzwerk und generiert darauf Antworten.
Die Antworten können über Service Interaction innerhalb des Servers abgestimmt werden. Leider funktioniert dieser Ansatz nur für Dienste innerhalb des SLEE's. Weitergehende Anwendungesmodelle Richtung SCIM müssen programmatisch erstellt werden.
Dem Standard folgend sind JAIN™ SLEE's hier nicht optimal anzuwenden:

• IMS Application Server, da zu komplexes Programmiermodell
• Netzwerkabstraktion, da keine Unterstützung von synchronen Aufrufen
• Gateway, da nur komplexe Realisierungsmöglichkeiten für Schnittstellen nach außen zur Verfügung stehen