Kuva 1. OMG:n Object Management Architecture.
Tietojenkäsittely on siirtymässä uuteen vaiheeseen jota leimaa olio-orientoituneisuus ja ohjelmistojen hajausttaminen verkkoon. OMG:n CORBA pyrkii vastaamaan ajan haasteisiin mahdollistamalla olioiden hajauttamisen tietoverkkoon. Tämä tarkoittaa sitä että 'CORBA-oliot' näkyvät kaikille asiakassovelluksille samanlaisina riippumatta siitä millä teknologialla asiakassovellus tai oliot on toteutettu.CORBA määrittelee olio-väylän (object bus) jonka olioita kaikki väylään yhteydessä olevat asiakassovellukset voivat käyttää. Väylä muodostuu keskenään kommunikoivista ORB:sta. ORB puolestaan tarjoaa sidonnan johonkin isäntäkieleen (tyypillisesti C++ tai Smalltalk) jonka kautta asiakassovellus pystyy käyttämään väylän olioita samalla tavalla kuin jos ne sijaitsisivat sovelluksen paikallisessa muistiavaruudessa. Tekniikka pohjautuu TCP/IP:n päälle toteutettuun RPC:hen johon on lisätty TPMonitorin ominaisuudet sekä rajapinta- ja totetutustietokannat (interface repository ja implementation repository). CORBA määrittelee myös protokollat IIOP ja GIOP joilla ORB:it kommunikoivat keskenään. GIOP huolehtii viestien syntaksista ja IIOP niiden siirtämisestä (vrt. OSI-mallin siirto- ja esityskerrokset). IIOP:ta ajetaan kuitenkin TCP/IP:n päällä joten GIOP/IIOP:n tehtävät liittyvät tiedon loogiseen esitykseen jonka CORBA määrittelee.
OMG:n muodostaa yli 700 yhteistyöyritystä jotka edustavat tietotekniikkateollisuuden eri aloja. OMG-yhteisön päämääränä on kehittää avoin standardi joka määrittelee olioiden hajauttamisen tietoverkoon. Merkittävimmän poikkeuksen muodostaa Microsoft joka on lähtenyt kehittämään omaa kilpailevaa teknologiaansa joka ei ole avoin (DCOM).
CORBA-arkkitehtuurin neljä perusosaa ovat:
Alla oleva kuva valottaa näiden suhdetta toisiinsa.
Kuva 1. OMG:n Object Management Architecture.
ORB on olioväylä joka mahdollistaa olioiden tehdä ja vastaanottaa palvelupyyntöjä muilta olioilta, joko paikallisilta tai etäolioilta.Asiakasolio tai -sovellus ei näe mekanismia jolla palvelinolion kanssa kommunikoidaan. CORBA ORB tarjoaa runsaasti palveluita jotka ovat muita hajautetussa tietojenkäsittelyssä käytettyjä työkaluja (RPC, MOM, päästä päähän ratkaisut) sofistikoituneempia. CORBA ORB:in tärkeimmät edut muihin middleware ratkaisuihin nähden ovat:
COS koostuu kokoelmasta systeemitason palveluita jotka on IDL:llä kuvattuja komponentteja. COS laajentaa ja viimeistelee ORB:in tarjoamat palvelut. COS:in palveluita käytetään luomaan komponetteja, nimeämään niitä ja esittelemään ne ympäristölle. OMG on määritellyt seuraavat yksitoista tärkeintä oliopalvelua:
CORBA:n päätarkoitus on määritellä mekanismit
joilla oliot voidaan hajauttaa toisiinsa kytkettyjen tietokoneiden kesken.
Tietoverkko on yleisimmin Internet mutta tätä ei vaadita. Verkkoon
hajauttaminen vaatii paitsi myös metodien etäkutsumekanismeja
niin myös keinot saattaa eri koneissa sijaitsevat
CORBA 1.1 (1991) määritteli ainoastaan IDL:n, sidonnat isäntäkieleen
ja ohjelmointirajapinnat ORB:iin. Tämä mahdollisti siirrettävän
ohjelmakoodin kirjoittamisen jota voitiin ajaa useiden CORBA-yhteensopivien
ORB:ien päällä. CORBA 2.0 määrittelee yhteistoiminnan
eri toimittajien ORB:ien välillä.
Kuva 2. Inter-ORB Arkkitehtuuri. Harmaat osat kuluuvat pakollisina kaikkiin
ORB implementaatioihin.
GIOP on suunniteltu ORB:ien väliseen kommunikointiin ja se määrittelee kommunikoinnissa käytettävien viestien formaatit ja tiedon esitystavan. GIOP toimii suoraan yhteydellisen siirtoprotokollan päällä (IIOP / TCP/IP). GIOP määrittelee formaatin IOR:lle. IOR tarjoaa referenssin olioon tiedonsiirtoyhteyden yli.
IIOP määrittelee sen kuinka viestit (GIOP:n PDU:t) välitetään TCP/IP-yhteyden yli. IIOP mahdollistaa Internetin käyttämisen runkoverkkona jonka kautta ORB:it voivat kommunikoida keskenään (ORB-to-ORB bridging).
CORBA 2.0 määrittelee mekanismin jolla voidaan luoda geneerisiä ORB:ien välisiä siltoja. ORB ottaa vastaan DSI:n (Dynamic Skeleton Interface) kautta pyynnöt jotka se välittää edelleen seuraavalle ORB:lle DII:n (Dynamic Invocation Interface) kautta. ORB:ien välisiä siltoja voidaan käyttää hyvinkin joustavien topologioiden luomisessa samaan tapaan kuin siltoja käytetään lähiverkoissa. ORB:it voidaan ryhmitellä hallinnollisten tarpeiden, kuormituksen, tietoturvatarpeiden tai palveluiden mukaan joita kuhunkin ORB:iin liitetyt oliot tarjoavat.
factotum@anon.nymserver.com wrote:
[snip]
> So I am at a loss as to why my managers would want me to make my
distributed
> Java applications "CORBA compliant" and what significance
it has in a Java
> world (other than causing my company to pay for redundant technology).
In a word - 'scaling'. The corba servers are designed to scale, provide redundant services, fault tolerance, etc. The Corba vendors have spent years defining, and even providing those features to their customers, and the choice is do you leverage on all of this infrastructure or do you build it yourself. Just as you discussed earlier in your posting about leveraging your old 'C' code through the JNI, Corba is a way for you to leverage the facilities provided by the corba vendors. That doesn't mean that you have to write bad Corba (like companies all too often do), it just means it should be a consideration in the mix of technologies you consider implementing. We found Corba to be a great transport mechanism for our 3-tier secure database middleware because of its unique characteristics. We wrote our system so the developer is shielded from the harsh realities of Corba programming, however, and instead provided a higher level interface that keeps Corba transparent to them while leveraging its strengths.
Just my $.02
Ward Mullins
THOUGHT Inc.
ward@thoughtinc.com
http://www.thoughtinc.com
In article <333BDF9D.167EB0E7@uci.agh.edu.pl>,
VAhe <vahe@uci.agh.edu.pl> wrote:
>Hello!
>
>Since almost every ODB/ORDB vendor has its representative monitoring
>this newsgroup, I have a question directed first of all to them (as
well
>as to any other third-side expert or merely a person which has an
>experience with that products).
>
>Considering database/CORBA cooperation, new versions of most ODB/ORDB
>products include such option (in the most cases it is associated with
>Orbix ORB implementation). Some part of them have chosen object adapter
>approach (e.g. ObjectStore, Versant), while the others prefer wrapper
>(front-end) approach (e.g. O2 and Persistence). Unfortunately, I don't
>know wheter other ODB/ORDB products provide such a feature, i.e.
>integration facilites with ORB. My question is: except abovementioned
>products are there other ODB/ORDBs which support integration with ORB
>and, if yes, which kind of integration is it (i.e. through adapter
or
>wrapper). Any references to appropriate parers will be appreciated
as
>well.
>
>Thanks in advance, VAhe
>--
in general, vahe, i'd suggest browsing the web sites of the vendors. in particular, objectivity has announced a tight integration with orbix. i'm guessing you would describe it as an "adapter" approach. however, it goes beyond the standard orbix adapter (used by other integrations) to allow your orb object (which is also an odbms object) to act as a server, supporting simultaneous, multiple transactions for multiple, concurrent clients (which is what most orb objects do...). we plan a similar integration with visigenix. for other orbs, it should be possible for users to do it themselves with a small amount of extra effort (one user reported two days). regards, drew
Drew Wade
drew@objy.com
Objectivity, Inc.
info@objy.com
301B E. Evelyn Avenue
http://www.objy.com/
Mountain View,
CA 94041-1530 +1 (415) 254-7113, 71 fax
Jani Lall, 1997