Accounting Tariffing GUI Zwischenschicht
Inhalt
1. Proxy - Interface Zugriffe -
Tabelle: NameServer Namensraeume
2. Accounting / Tariffing Proxy-Dateien
3. Exception Handhabungs Varianten
1. Proxy - Interface Zugriffe
Die Proxies benoetigen vier Varianten, an die Referenzen des/der Interfaces zu kommen, deren Requests sie dann anbieten koennen. Diese Uebergabe kann z.T. schon bei der Instanziierung oder spaeter per Methodenaufruf erfolgen.
Interface-Referenz via Name-Server
Die Proxies bekommen die IOR (String) des NameServers uebergeben.
a. Dort holen sie sich das Initial-Interface des CO und benutzen es, um das fuer spaetere Requests benoetigte operationale Interface des CO zu erlangen.
b. Dort holen sie sich gleich das benoetigte operationale Interface des CO.
Accounting benoetigt z.T. die Variante a.
Tariffing benoetigt die Variante b.
Subscription benoetigt (vorlaeufig) Variante b.
Interface-Referenz per Request
Zwei weitere Varianten zur Erlangung einer Interface-Referenz sind, daß das Proxy die Interface-Referenz
c. mittels eines Methodenaufrufs von einem anderen Objekt der Application-Schicht bekommt, dem sie (als IOR-String) als Rueckgabewert eines Requests uebergeben wurde,
oder
d. mittels eines Requests von einem CO erhaelt. Dazu muss das Proxy erst selber ein IDL-ORB-Interface erzeugt und exportiert haben ("aktives Proxy").
Accounting benoetigt z.T. die Variante c. Subscription benoetigt (kuenftig) Variante d.
Accounting und Tariffing
Proxy BasicTariffMgmtIFAccess spiegelt (alle) Methoden des Interfaces i_BasicTarifMgmt (des TariffMgmt CO), das es sich aus dem NameSerice aus dem Namensraum ("TINAPlatform", "TariffManagement", "BasicTariffMgmt") holt.
Proxy UserPlanTariffMgmtIFAccess spiegelt (alle) Methoden der Interfaces i_UserPlanTariffMgmt (des TariffMgmt CO), das es sich aus dem NameSerice aus dem Namensraum ("TINAPlatform", "TariffManagement", "UserPlanTariffMgmt") holt.
Proxy ChgMgmtIFAccess spiegelt (eine Auswahl der) Methoden des Interfaces i_ChgMgmt (des ChgControl CO), das es sich vom i_ChgControlInit Interface besorgt, das es vom NameService aus dem Namensraum ("TINAPlatform", "AccountingChargeControl") holt.
Proxy ChargeQueryIFAccess spiegelt (eine Auswahl der) Methoden des Interfaces i_ChargeQuery (des OnlineCharge CO), das es von der Application-Schicht nach seiner Instanziierung uebergeben bekommt (d.h. die Application-Schicht holt das i_ChargeQuery Interface mittels des InitialInterfaces des OnlineCharge CO und reicht es ans Proxy weiter).
Tabelle: NameServer Namensraeume
--------------------------------------------------------------------------------------------
Namensraum-Hierarchie im NS -> ORBA-Objekt
--------------------------------------------------------------------------------------------
TINAPlatform
AccountingChargeControl -> i_ChgControlInit
TariffManagement
UserPlanTariffMgmt -> i_UserPlanTariffMgmt
BasicTariffMgm -> i_BasicTarifMgmt
--------------------------------------------------------------------------------------------
2 Accounting / Tariffing Proxy-Dateien
Java Interfaces:
(spezifizieren die Methoden der IF Access Klassen)
UserPlanTariffMgmtInterface.java
BasicTariffMgmtInterface.java
ChargeQueryInterface.java
ChgMgmtInterface.java
TINAPlatform IF Access:
(realisieren den IF Zugriff und die Requests)
BasicTariffMgmtIFAccess.java
UserPlanTariffMgmtIFAccess.java
ChgMgmtIFAccess.java
ChargeQueryIFAccess.java
Exceptions:
DPESystemException.java
AccountingException.java
TariffMgmtException.java
SubscriptionException.java
Oberklassen:
IFAccess.java
IFAccessInterface.java
IFAccessException.java
Hashtable Templates:
basicTariffTemplate.txt
userPlanTemplate.txt
userChargeTemplate.txt
Texte zu Konzept und Implementierung:
ProxyKonzept.txt
ActTafIDLFragen.txt (offene Fragen)
ActTafProxyDateien.txt (dieser Abschnitt)
3. Exception Handhabungs Varianten
Exception werden in TINA-COs erzeugt (geworfen) und wandern durch die Zwischen-Schichten
GUI Application-Schicht Proxy (Interface-Access-Schicht) TINA-CO
bis zum GUI.
Wenn das CO eine Exception wirft, kann das Proxy diese entweder
1. "weiter nach oben werfen", d.h. eine IDL-deklarierte Exception landet in der Schicht über den Proxies
oder
2. auffangen und statt dessen
2.1 eine "eigene entsprechende Exception werfen", d.h. für jede IDL-spezifizierte Exception wird eine entsprechende Java class implementiert
oder
2.2 eine spezielle Java-Zwischenschicht-Exception" (die im Text ihren Ursprung angibt) auslösen
oder
3. auffangen und statt dessen "eine Meldung in die Console schreiben" z.B.
catch (Act.e_AccountingException ex) { System.err.println ("Exception: AccountingException " + ex); }
Variante 1. widerspricht der Abkoppelung der GUIs von CORBA-Strukturen.
Variante 3. ist vorläufig das einfachste (der evtl. Rückgabewert eines gescheiterten Requests (ans GUI/die Application-Schicht) wäre "null").
Variante 2.1 soll möglichst im März erreicht werden.
98-02-05, tko
|