CORBA und JNDI

Die Referenzarchitektur
für verteilte Objektsysteme
CORBA
■ CORBA als Architekturmodell
■ Interface Definition Language
■ Objekt Referenzen
■ Verzeichnisdienst
Software Components and Services
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
2 von 43
The Industrial Revolution
■ Craftsmanship: separation of duties
■
Specialization increases efficiency
■ Manufactory 18th century: collocation of craftsmen
■
■
Craftsmen are collocated
■ Task is reduced to single "core" competence
Auxiliary task are centralized
■ Automation 19th century
■
Manpower partially replaced by machines
■ Assembly (line) of components 20th century
■
■
Assembly of prefabricated components
Separation into:
■ Component builder
■ Assembler
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
3 von 43
The Hardware Revolution
Levels of abstractions
■
Single electronic components
■ Resistors, transistors
■
Integrated logic gates: TTL
■
Highly integrated circuits
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
4 von 43
The Software Revolution
Levels of abstractions
■
Individual programming statements
■
Software library function calls
■ ANSI C library
■ Win32 API calls
■
Software components/services
■ Components: ActiveX (COM/OLE)
■ The only universal component standard that
ever succeeded
■ Technically and commercially
■ Now abandoned by Microsoft
■ Base of WinRT/UWP
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
5 von 43
Software Components and Services
■ A software component is… (according Szyperski)
■
■
■
■
i) a unit of composition and subject to third-party composition
ii) with contractually specified interfaces
iii) explicit context dependencies only.
iv) software component can be deployed independently
■ A service is…
■
■
i) ... iii) ditto
iv) already deployed Æ federated, located and accessed remotely
A service is a remotely accessible, instantiated component
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
6 von 43
CORBA
Architektur
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
7 von 43
Common Object Request Broker Architecture
eine
eineArchitektur,
Architektur,kein
keinProdukt!
Produkt!
Definition und Entwicklung einer Architektur für kooperierende
objekt-orientierte Software-Bausteine in verteilten heterogenen
Systemen
OMG (Object Management Group)
■ herstellerübergreifendes Konsortium
■ gegründet 1989 von 11 Firmen,
■ umfasst heute über 700 Mitglieder, sogar MS ist dabei.
■ Ziel war die Bereitstellung von Konzepten („open“) für die Entwicklung verteilter
Systeme mit objektorientierten Modellen.
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
8 von 43
ORB – die Kommunikations-Schiene
■ Der ORB (Object Request
Broker) ist selbst ein verteiltes
System.
■ Seine Dienste gehen weit über
die „reine“ Kommunikation
hinaus:
Client
Server
■ Verzeichnisdienste für das Publizieren/Suchen/Finden
von dienstbaren Objekten
und deren Interfaces (Syntax) und Fähigkeiten (Semantik)
■ Absolute Transparenz (Ort, Plattform, etc.)
■ Weitere Funktionen im Sinne von „Middleware“
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
9 von 43
OMA – Object Management Architecture
■ CORBA definiert damit auch eine
Infrastruktur mit einigen
Standard-Diensten
Application Objects
ORB
Common Object Services Common Facilities
(standardisiert)
(nützlich, fakultativ)
■ COSS (Common Object Services Specification):
Realisierung ist für CORBA-konforme Produkte zwingend,
jedoch sind noch längst nicht alle Services spezifiziert.
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
10 von 43
CORBA Common Object Services
■ Lifecycle
Erzeugen, entsorgen, kopieren, verlagern, ... von Objekten
■ Naming
Erzeugen von Namensräumen („naming contexts“)
Abbildung von Namen auf Objektreferenzen
Lokalisierung von Objekten
nicht URL, sondern
„machine-readable“
■ Transaction
Protokoll für 2 Phase Commit
...
Sind die 2(3) Services die absolut notwendig sind
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
11 von 43
...CORBA Common Object Services
...
■ Event Distribution
Weiterleitung asynchroner Ereignisse (Observer Pattern)
über sogenannte „Event Channels“
■ Concurrency
■ Persistence, Replication, Externalization
■ Licensing, Security
■ Trading
hochgestecktes Ziel, Objekte, deren Dienste und Schnittstellen
dynamisch handeln und verhandeln zu können
...
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
12 von 43
Common Facilities
Höherwertige Dienste für ein breites Anwendungs-Spektrum
(analog zu grossen Klassenbibliotheken)
Horizontal Common Facilities
■ secure time
■ printing
■ mobile agents
■ information management
... ein bisschen Data Warehousing
... IIM, ITIL Configuration Management
... Workflow
■ systems management
■ task management
■ ...
Vertical Common Facilities
■ Basisfunktionen für diverse Marktsegmente
(Banking, Gesundheitswesen, etc.)
■ vgl. „application frameworks“, „business objects“ und dergleichen
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
13 von 43
Ausserhalb des ORB Core ...
■ „Statische“ Schnittstelle
generiert (wie RPC, RMI)
■ Dynamische Schnittstelle
(Client kann zur Laufzeit das Schnittstellenverzeichnis abfragen und den geeigneten
Methodenaufruf zusammenbauen)
■ Objektadapter (anwendungsunabhängige Funktionen des Serverobjekts)
BOA (Basic Object Adapter)
– Minimalmodell
POA (Portable Object Adapter) – Erweitertes Modell
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
14 von 43
Interface Definition Language
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
15 von 43
IDL – die Interface-Definition
■
■
■
■
Wie beim RPC steht im Zentrum die Definition des Server-Interfaces.
Die Sprache IDL ist CORBA-spezifisch und „unabhängig“.
IDL ist selbst objektorientiert (Vererbung).
Aus einem Stück IDL werden die konkreten Elemente für die jeweilige Plattform
generiert.
■ Ein ORB kann sowohl IDL-Definitionen als auch deren dazugehörige
Implementationen „verwalten“
grundsätzlicher
Aufbau
[oneway] <op_type_spec>
<identifier>
(param1,....,paramL)
[raises(except1,...,exceptN)
] [context(name1,...,nameM)]
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
16 von 43
IDL – allgemeines
■ Eine Deklaration, umwandelbar in „Target Code“
■ Sieht syntaktisch „gewohnt“ aus, ist aber weder C/C++ noch Java.
■ Methoden-Signaturen spezifizieren neben Parameter-Typen auch
ob es sich um „input“ oder „output“ handelt.
■ wichtig für die Übertragung von Argument-Werten und/oder
Synchronisation von “by-reference” übergebenen Variablen
■ Pro IDL-File können mehrere Interfaces deklariert werden.
■ Hat ein „Modul“-Konzept für „scoping“-Zwecke,
mit der Möglichkeit der Verschachtelung (nesting).
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
17 von 43
IDL – Beispiel
module SomeDBApp {
module services {
struct Person {
string name;
int
in;
long
balance
}
typedef sequence<string> PersonNameSeq;
exception AlreadyOnLine{};
exception Duplicate{};
interface Server {
boolean init(in string name) raises(AlreadyOnLine);
}
interface someLookup {
PersonNameSeq doit(in string name, out Person p) raises(Duplicate);
}
}
...
}
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
18 von 43
IDL-to-Java
> idlj -fall ThisOrThatServer.idl
interface ThisOrThatServer
class ThisOrThatServerHelper
■ CORBA Streams für Objekt-Transport
class ThisOrThatServerHolder
■ hält out/inout-Argumente
class _ThisOrThatServerStub
■ client-side proxy
class ThisOrThatPOA
■ enthält den Adapter für Server
Eigentlich klar. Aber doch aufwendig!
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
19 von 43
Client - Struktur
■ Der Client sieht den Server als Objekt;
Argumente/Parameter sind Objekte
■ Jedes Interface (seine Signatur)
spezifiziert Objekte, die alle „gehandelt“
werden müssen.
■ Dies erfordert die Abbildung von
„Pointers“ und dergleichen
auf ORB-taugliche Referenzen.
■ Eine Menge „Library-Routines“ besorgt
die Abbildung der Datentypen (à la XDR).
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
Proxies
20 von 43
Server - Struktur
■ Skeletons besorgen den
konkreten Aufruf der
Methode, Prozedur,
Subroutine, wie immer das
dann halt heisst.
■ Auch hier erfolgt die Abbildung von
ORB-tauglichen Referenzen auf
„Pointers“.
■ Eine Menge „Library-Routines“
besorgt die Abbildung der Datentypen
(à la XDR).
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
21 von 43
Object Adapter
■ Server-Objekt muss sich hier
anmelden, als:
■
■
■
■
Shared Server
Unshared Server
Server per Method
Persistent Server
Object
Adapter
■ Server-Objekt muss sich auch beim
„Implementation Repository“
anmelden
■
■
■
■
■
■
Generierung und Interpretation von Objekt-Referenzen
Objekt-Lebenszyklus-Management
Methoden-Aufrufe
Abbildung von Objektreferenzen auf konkrete Implementation
Sicherheit der Interaktionen
Registrierung von (Objekt-) Implementationen
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
22 von 43
Integration „fremder“ Systeme
■ Die Integration von sogenannten „Legacy Systems“ ist einer der wichtigeren
Zwecke einer Enterprise Architektur.
■ Man steckt diese (produktiven) Altlasten einfach in ein CORBA-Hemd.
■ simpel:
■ normal:
■ schwierig:
Die Applikation lässt sich BOA- oder POA-tauglich machen
Die Applikation benötigt einen speziellen Adapter
Die Applikation muss in etwas verpackt werden, das
nach aussen weitgehend einen Standard ORB spielen kann
(Transaktionen, Security)
■ Kommunikation zwischen ORBs ist durch ein IOP
(Inter-ORB-Protocol) definiert.
■ IIOP (über TCP/IP) ist nur eines von vielen.
Object
ObjectSystem
System
as
another
as anotherORB
ORB
IOP
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
23 von 43
Messaging Service
■ Asynchrones Kommunikations-Paradigma (im Gegensatz zu RPC)
Motivation:
■ mobile Geräte sind nicht immer „online“
■ bei grossen, komplexen Systemen sind unausweichlich auch
nicht immer alle Dienste erreichbar
■ Zeitliche Entkopplung von Sender und Empfänger
■ Sender blockiert nicht
■ Nachricht kann immer irgendwo zwischengespeichert werden, bis der
Empfänger erreichbar ist und sie entgegennimmt
■ Meldungen können umgeleitet werden (Kaskaden, Zuständigkeiten); RouterAgenten implementieren „Policies“ zur Erreichung bestimmter Ziele
(Zeitlimiten, Prioritäten, Reihenfolgen, QoS, )
■ Von der Anwendung geforderte Semantik muss mit darüberliegenden
Protokollen realisiert werden
■ Sicherheit/Fehlerbehandlung sind nicht ganz trivial
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
24 von 43
AMI – Asynchronous Method Invocation
■ synchron
■ verzögert synchron (non blocking)
■ one way („maybe“)
Bisher (vgl.
RPC):
AMI
Callback
■ Client gibt beim Aufruf eine Objektreferenz mit
■ Callback-Objekt muss sich nicht notwendigerweise im Client
befinden, sondern kann irgendwo existieren
■ Kommunikations-Exceptions werden
im Callback-Objekt geworfen
Polling
■ Client erhält als Sofort-Antwort ein Objekt zurück
■ Dieses wird dann das Resultat bereithaben; der Client kann
sich periodisch danach erkundigen (poll)
■ Client kann Event-Listener drauf setzen (???)
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
25 von 43
Objekte „by Reference“ oder „by Value“
„parameter passing by reference“
■ Objekte werden als Pointer oder Referenzen gehandelt (siehe später).
„parameter passing by value“
■ Argument-(Objekt) erscheint im Parameter als Kopie:
es wurde durch „marshalling“ serialisiert und übertragen,
daraus macht eine „factory“ eine Kopie mit eigener Identität
■
■
■
■
Was geschieht mit zyklischen Strukturen? Was mit Alias-Referenzen?
Wie transportiert man das Verhalten des Objekts (Methoden) ?
Ausführbarer Code in heterogener Umgebung (Maschine, Sprache) ?
Auch so eine „factory“-Lösung möglich?
Vorderhand Beschränkung auf „valuetypes“
■ Struct inIDL
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
26 von 43
CORBA Components
Stichwort Komponenten ...
■ Gemeint ist damit eine Möglichkeit und die dazugehörige Systematik, verteilte
Anwendungen nicht nur „modularisiert“ zu entwickeln,
sondern sie „sich im Verlaufe der Lebenszeit entwickeln zu lassen“.
Also dynamisches Wachstum, allmähliche "Alterung zur Reife".
Nutzen (dieselben Begriffe wie bei der Objektorientierung), dazu:
■ grafische Tools zum Zusammenstecken und Plazieren von Komponenten
Elemente eines Komponenten-Modells
■
■
■
■
Konfiguration
Persistenz
Verpackung
Lizenzierung
■
■
■
■
Definition
Interaktion
Komposition
Introspektion
Weitgehend von JEE abgedeckt
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
27 von 43
CORBA Components
■ Komponenten leben in sogenannten Containern, welche bestimmte
Basisdienste bereitstellen (bsp. CORBA Object Services)
Definition
■ spezielles CORBA-Objekt
■ funktionale Schnittstelle (mehrere Interfaces)
■ Konfigurations-Attribute
Interaktion
■ Event-Modell (Publish/Subscribe)
■ in IDL deklariert, können Transaktionscharakter haben
Komposition
■ Aggregation (vgl. Analyse-Muster bei OOD)
■ bedeutet hier auch Verbindung durch Kommunikationskanäle
Introspektion
■ Ermittlung einer Schnittstelle (Signaturen) zur Laufzeit
■ Dynamische Anreicherung des Interface Repository
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
28 von 43
CORBA und DCOM
Microsoft „Distributed Component Object Model“,
Wurde durch .NET Remoting in WCF abgelöst
■ Weitgehend gleiche Zielsetzung mit anderen Begriffen
■
■
■
IDL heisst MIDL
Repository heisst Registry
Aufgaben von ORB und Object Adapter werden
von „Service Control Manager“ wahrgenommen
■ DCOM ist proprietär
■ Einige Unterschiede
■
Schnittstellen-Aggregation, keine Schnittstellen-Vererbung
■
DCOM hat „einen“ Garbage Collector“ mit Referenzzähler
DCOM definiert auf seiner „Schiene“ ein Binärformat
(CRL = common runtime layer)
■
■ DCOM ist faktisch an seiner Komplexität gescheitert
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
29 von 43
CORBA und Java
■ Java nimmt für sich ebenfalls Plattformunabhängigkeit in Anspruch
■ JEE bietet auch eine Menge von „Common Object Services“
■ Interoperabilität durch Zusammenführung von Java RMI und CORBA
IIOP
Java RMI läuft über IIOP (und irgendeinen Standard ORB)
■ IDL kann automatisch aus Java-Programmen generiert werden
■
■
■
„reverse mapping“ IDL
Interface
CORBA-Objekte werden ohne IDL-Kenntnisse nutzbar
anderssprachige Objekte können von Java angesprochen werden
■ Das „single language“ Paradigma von Java wird aufgebrochen
■
Java-Objekte werden über CORBA zugreifbar
■ alles natürlich mit „Einschränkungen“ -> hat sich nicht durchgesetzt
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
30 von 43
CORBA und Open Source
■ Zwar ist die OMG ein Konsortium mit den üblichen Problemen
■
Standardisierung = langwieriger Prozess, komplexe Resultate
■ Jedoch sind die Standards offen: konforme Implementierungen
finden Absatz und Einsatz, egal unter welchem Lizenzierungs-Schema
OpenSource (u.v.a.)
Kommerzielle Produkte (u.v.a.)
■
■
■
■
■
■
■
■
■
■
■
JRE
MICO
JacORB
TAO
omniORB
ILU
IBM:
Borland:
BEA:
OOC:
ExperSoft:
Websphere
Visibroker
ObjectBroker
ORBacus
PowerBroker
■ Implementierungsstand ist allerdings sehr unterschiedlich
■ Ernstzunehmende JEE Applikationsserver haben einen eingebauten ORB.
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
31 von 43
Objekt Referenzen
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
32 von 43
Objektreferenzen
■ Referenzen auf Objekte im eigenen Kontext sind klar definiert
■
Pointer, References, Adressen
■ Problem: Objektreferenz über Maschinen-/und Sprachgrenzen hinweg
Abbildung
Sprachspezifische Objektreferenzen
C, C++
Pointer
Java
(Objekt-) Variable
ORB-spezifische Objektreferenzen
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
33 von 43
Objektreferenzen
■ Interoperable Object References (IOR)
■ Jeder ORB muss pro unterstützte Programmierumgebung
„dieselbe“ Sprachbindung für Objekte anbieten.
■ Dadurch wird „Interoperabilität“ erreicht.
IIOP version
version implemented by the ORB
Host
TCP/IP address of the ORB's host machine
Port
port number where the ORB is listening for client requests
Key
Value uniquely identifies the server to the ORB exporting the service
Components
A sequence that contains additional information applicable to object method
invocations, such as supported ORB services and proprietary protocol support
An IOR specifies the wire protocol for talking to an object as well as specifying the
object's network location.
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
34 von 43
IOR -- „stringified“
■ Eine IOR enthält binäre Werte.
■ Jedoch wird aus praktischen Gründen eine String-Version umgewandelt
werden
ServerServerObjekt
Objekt
string_to_object()
string_to_object()
Referenz
Referenz
für
fürdas
das(Server)
(Server)
Objekt
Objekt
School of Engineering
object_to_string()
object_to_string()
IOR:000000000000001649444c3a6578616d706
IOR:000000000000001649444c3a6578616d706
c652f48656c6c6f3a312e300000000000000100
c652f48656c6c6f3a312e300000000000000100
00000000000070000102000000000f3231322e3
00000000000070000102000000000f3231322e3
234362e3137372e313600000b0c000000000021
234362e3137372e313600000b0c000000000021
afabcb0000000020036657d7000000010000000
afabcb0000000020036657d7000000010000000
00000000000000004000000000a000000000000
00000000000000004000000000a000000000000
010000000100000020000000000001000100000
010000000100000020000000000001000100000
002050100010001002000010109000000010001
002050100010001002000010109000000010001
0100
0100
Implementation
Implementation
Repository
Repository
Instantiierung des Servers
Interface
Interface
Repository
Repository
Info für den Client
© E. Mumprecht, K. Rege, ZHAW
35 von 43
Java
Verzeichnisdienst
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
36 von 43
Verzeichnisdienst in Java
■ Jedes nicht-triviale System benötigt Verzeichnisdienste, weil die Komponenten
kommen und gehen, mobil und volatil sind.
■ Beispiele:
Internet
e-Mail
General Purpose
Unix/Linux
Novell
Windows
RPC
RMI
CORBA
WebServices
SNMP
DNS
X.500
LDAP
NIS
NDS
Registry; ADS
Portmapper
RMI-Registry
ORB/COS-Naming
UDDI
MIB
■ Jeder Verzeichnisdienst hat seine Eigenheiten.
■ Jedoch lassen sich viele Verzeichnisdienste in Java über ein
gemeinsames Modell ansprechen: JNDI
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
37 von 43
Java Naming and Directory Interface
Anwendungen
Anwendungen
JNDI API
■ Gemeinsames Interface
Naming Manager
■ Gemeinsame Grundfunktion
JNDI SPI
■ Interface für „Plugins“ (Service Provider)
über
überContext
ContextFactories
Factories
Konkrete
KonkreteVerzeichnisdienste
Verzeichnisdienste
JNDI-Packages
javax.naming
javax.naming.directory
javax.naming.event
javax.naming.ldap
javax.naming.spi
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
38 von 43
JNDI Grundkonzepte
■ Namen und Objekte sind zeitweilig aneinander gebunden.
■ Solche Bindungen (Bindings) existieren in einem Kontext.
■ Also repräsentiert ein Context eine konkrete Sammlung von Bindings.
■ Operationen (auf einen Context) sind u.a.
object = context.lookup(name)
context.bind(name,object)
bindings = context.listBindings()
■ Namen bestehen aus verschiedenen Teilen.
Sie werden in Form von Strings und auch als Names gehandelt.
■ Ein Binding ist eine Assoziation name
object.
■ Manchmal sind Objekte lediglich über Hinweise zu haben:
So lässt sich ein object allenfalls über eine reference „nachbilden“.
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
39 von 43
Der JNDI-Context
■ Ein Context muss mit Hilfe einer Factory erstellt werden.
■ Der Hersteller/Lieferant des „Service Providers“ liefert für „seinen“
Verzeichnisdienst, bzw. sein Plugin, die Factory-Klasse.
■ Beispiele:
... ORB/COS-Naming
Context context = null;
Hashtable details = new Hashtable();
details.put(InitialContext.INITIAL_CONTEXT_FACTORY,
„org.jnp.interfaces.NamingContextFactory“);
details.put(InitialContext.PROVIDER_URL,„jnp://localhost:8888“);
context = new InitialContext(details);
... LDAP
DirContext context = null;
Hashtable details = new Hashtable();
details.put(Context.INITIAL_CONTEXT_FACTORY,
„com.sun.jndi.ldap.LdapCtxFactory“);
details.put(Context.PROVIDER_URL,
„ldap://ldap.zhaw.ch:389/dc=zhaw,dc=ch“);
context = new InitialDirContext(details);
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
40 von 43
Einige Context Providers
(nach javasoft.com)
LDAP
LDAP oder ADS
RMI Registry
[com.sun.jndi.rmi.registry.RegistryContextFactory]
DSML
Directory Services Markup Language (OASIS e-Business Standard)
DNS
[com.sun.jndi.dns.DnsContextFactory]
File System
[com.sun.jndi.fscontext.RefFSContextFactory]
JNDI2R
Windows Registry
...
...
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
41 von 43
JNDI – Directory Context
■ Konkrete Verzeichnisdienste arbeiten mit Attributen
in verschiedensten Organisationsformen
■ Das Interface DirContext erlaubt den „lookup“ aufgrund von Attributen
■ Beispiel:
Hashtable details = new Hashtable();
details.put(Context.INITIAL_CONTEXT_FACTORY,
„com.sun.jndi.dns.DNSContextFactory“);
details.put(Context.PROVIDER_URL,
„dns://ns1.zhaw.ch/zhaw.ch“
DirContext dns = new InitialDirContext(details);
normaler
normalerDNS-Lookup
DNS-Lookup
Attributes ia = dns.getAttributes(„hostname“, new String[] {„A“});
Attributes mx = dns.getAttributes(„dns://ns1.zhaw.ch/zhaw.ch“,
new String[] {„MX“};
MX-Anfrage an Mail-Domain
MX-Anfrage an Mail-Domain
■ Attributwerte lassen sich auch modifizieren.
■ Damit sind z.B. auch Update-Operationen im konkreten Verzeichnis möglich.
■ Mehrere Operationen lassen sich auch als Transaktionen verpacken.
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
42 von 43
JNDI
■ mag etwas einschüchtern
■ spart jedoch bereits bei kleineren Aufgaben eine Menge Aufwand
■ hat für komplexere Systeme einiges zu bieten
Literatur
Das Tutorial (ist vollständig on-line, hat als Buch 823 Seiten)
http://docs.oracle.com/javase/jndi/docs.html
Praktische Leitfäden
http://docs.oracle.com/javase/1.5.0/docs/guide/jndi/
Speziell für CORBA: “The COS Naming Service Provider”
http://docs.oracle.com/javase/1.5.0/docs/guide/jndi/jndi-cos.html
School of Engineering
© E. Mumprecht, K. Rege, ZHAW
43 von 43