Java 2 Micro Edition - Entwicklung mobiler Anwendungen mit CLDC und MIDP

7 Das Generic Connection Framework (S. 152-153)


Homer: Welcome to the Internet, my friend, how can I help you? Customer: I’m interested in upgrading my 28.8 kilobaud Internet connection to a 1.5 megabit fibre optic T1 line. Will you be able to provide an IP router that’s compatible with my Token Ring / Ethernet LAN configuration? Homer: (pause) Can I have some money now?

The Simpsons


Das MIDP richtet sich an ein breites Spektrum von Endgeräten, die trotz ihrer Heterogenität quasi definitionsgemäß zwei elementare Eigenschaften gemeinsam haben: Sie sind mobil einsetzbar und ermöglichen es, mit anderen Teilnehmern oder anderen Rechnern, seien es mobile Endgeräte oder größere Computersysteme, zu kommunizieren. Auch wenn der Löwenanteil des übertragenden Volumens heute noch auf Sprachtelefonie zurückgeht, kommt der Datenkommunikation doch eine stetig wachsende Bedeutung zu. Das liegt unter anderem daran, dass neu erscheinende Endgeräte zunehmend bessere Unterstützung für Kommunikationsprotokolle der TCP/IP-Familie bieten. Dieser Trend ist in die Spezifikationen eingeflossen. Mit der Einführung des Generic Connection Framework (GCF) ist es in der CLDC gelungen, eine durchgängige Programmierschnittstelle für verschiedene Protokolle zu schaffen. Zwei Protokollen der Anwendungsschicht kommt hierbei eine besondere Bedeutung zu:

- Hypertext Transfer Protocol (HTTP)
- Hypertext Transfer Protocol over TLS/SSL (HTTPS)

Ihre Sonderstellung ist dadurch begründet, dass sie in allen MIDP-2.0- kompatiblen Terminals unterstützt werden müssen. Weitere Protokolle sind in der Spezifikation vorgesehen, aber als optional ausgewiesen.

7.1 Entwurfsziele

Eine übergeordnete Entwurfsregel für die J2ME besteht darin, vorzugsweise bestehende Klassen und Methoden unverändert aus der J2SE zu übernehmen, soweit sie nötig und ausreichend sind. Bei der Netzwerkkommunikation ist eine Abweichung von diesem Ziel zu beobachten. Während der Arbeiten an den CLDC- und MIDP-Spezifikationen stellte sich heraus, dass die J2SE-APIs im Paket java.net für den Einsatz in mobilen Endgeräten ungeeignet sind. Diese Erkenntnis beruht im Wesentlichen auf den folgenden Punkten:

- Speicherbedarf: In J2SE 1.4 enthält java.net 27 Klassen, sechs Interfaces und elf Ausnahmen. Die daraus resultierende Bytecode- Größe von mehr als 200 kByte übersteigt bereits die Minimalanforderungen für CDLC-Geräte. Hinzu kommt, dass java.net weitere Pakete referenziert, die in der CLDC und den darauf aufbauenden Profilen nicht notwendigerweise zur Verfügung stehen.

- Konsistenz: java.net bietet keinen durchgängig konsistenten Umgang mit verschiedenen Protokollen. Der Aufbau einer Socket-Verbindung, die durch ein Socket-Objekt repräsentiert wird, erfordert beispielsweise die Adresse des Zielrechners als InetAddress-Objekt und eine Portnummer. Eine Verbindung zu einem Web-Server wird dagegen durch eine URLConnection dargestellt, für die man man eine Zieladresse als URL-Objekt benötigt, um sie zu öffnen. Im Gegensatz dazu sollte die CLDC nach den Vorstellungen seiner Schöpfer ein homogenes API für alle Arten von Netzwerkverbindungen beinhalten.

- Flexibilität: java.net stellt überwiegend Klassen zur Verfügung, auf die Entwickler direkt zugreifen können. Daraus resultiert Unflexibilität hinsichtlich der Austauschbarkeit der Protokollimplementierungen. Die CLDC ist für heterogene Ablaufumgebungen ausgelegt, in denen hochoptimierte, herstellerspezifische Implementierungen für systemnahe Schnittstellen integriert werden müssen.

Ein überwiegend auf Interfaces aufgebautes API erscheint dafür geeigneter als das durch Klassen dominierte API in java.net. Aus diesen Gründen fand java.net keinen Einzug in die CLDC und das MIDP. Mit dem Generic Connection Framework steht dort eine funktional vergleichbare Alternative zur Verfügung, in der die oben geschilderten Aspekte berücksichtigt sind.