Autor: admin

Jeśli mamy osiągnąć coś w rodzaju pełnego potencjału globalizacji, nie możemy oczekiwać, że wszystkie interakcje międzyludzkie będą miały miejsce twarzą w twarz. Zamiast tego musimy używać narzędzi, które umożliwiają współpracę na odległość. Praca zespołowa wspomagana komputerowo (CSCW) to jedno ze zbiorowych terminów używanych do opisania działań, które zazwyczaj są wspierane nie tylko przez komputery, ale także przez infrastrukturę komunikacyjną. Zostało to wzmocnione na rysunku , który przedstawia najczęściej używane narzędzia, jako funkcję lokalizacji i czasu.

Jeśli ludzie mogą spotykać się razem w tym samym miejscu, w tym samym czasie, nie ma potrzeby korzystania z technologii (może z wyjątkiem, być może, pomocy w nagrywaniu protokołów). Jeśli wszyscy mieszkają w tym samym miejscu, łatwo jest zapewnić dostęp do wspólnych dokumentów lub zostawiać notatki na swoich biurkach. Bardziej interesujące opcje technologiczne pojawiają się, gdy dzieli je odległość. Nawet jeśli dzieli je odległość, mogą być dostępne w tym samym czasie. W takim przypadku mogą rozmawiać przez telefon lub korzystać z wideokonferencji. Kolejną opcją w czasie rzeczywistym jest możliwość udostępniania wspólnych danych na tablicy przez rozproszone zespoły. Ta funkcja umożliwia wyświetlanie tekstu i grafiki ze wspólnego serwera plików w każdej witrynie. Możliwe jest manipulowanie wyświetlanymi informacjami, np. za pomocą myszy „narysuj” okrąg wokół części diagramu i wyświetlając ten okrąg na wszystkich terminalach. Tekst dokumentu można również edytować, a wyniki uzgodnionych edycji następnie wykorzystać do aktualizacji pliku na serwerze.

Do tej pory przyjrzeliśmy się zautomatyzowanym procesom związanym z integracją wielu działań e-biznesu, ale niewiele powiedzieliśmy o procesach, które zależą od zaangażowania ludzi w organizacji. Z pewnością procesy obliczeniowe są „łączone”, aby uniknąć konieczności interwencji człowieka bardziej niż jest to konieczne. Nie chodzi tylko o zaoszczędzenie na zarobkach. Za każdym razem, gdy wymagamy od operatora ponownego wprowadzenia danych do systemu, wprowadzamy znaczny koszt awarii z powodu błędów. (Na przykład odnotowano, że od 20% do 40% wszystkich arkuszy kalkulacyjnych zawiera błędy). Nie możemy jednak całkowicie zrezygnować z ludzi. W rzeczywistości ludzie we właściwym miejscu, z odpowiednimi umiejętnościami, są najcenniejszym zasobem większości firm. Krytyczne negocjacje nadal toczą się między ludźmi, a nie maszynami, i nie ma poważnych perspektyw, aby ta zmiana się zmieniła w dającej się przewidzieć przyszłości, nawet pozwalając na szybki rozwój sztucznych agentów handlowych do zadań niekrytycznych. Dlatego, szczególnie w przypadku działań intrabusiness i interbusiness, wymagamy tworzenia środowisk typu „person-to-person”, które budują zaufanie i wspierają działania interpersonalne przez cały cykl ich życia. Wspólny model pracy zespołowej podkreśla potrzebę rozważenia jej w kategoriach trzech odrębnych, ale powiązanych ze sobą działań  – procesów, zespołów i działań indywidualnych.

Procesy, takie jak przyjmowanie i realizacja zamówień, projektowanie produktu itp. przepływają przez organizację, ale tylko w wyniku wspólnych działań zespołów osób, które mogą należeć do tej samej jednostki funkcjonalnej lub do różnych jednostek, nawet zlokalizowanych w różnych miejscach. O tych osobach należy myśleć jako o podejmowaniu określonych ról, np. urzędnik ds. zakupów, organ projektowy itp., a także jako osoby fizyczne. Rozróżnienie jest ważne: kupiec posiada zestaw obowiązków i uprawnień, np. prawo do podpisania zamówienia zakupu. Organizacyjnie każdy specjalista ds. zakupów „zrobi”, jeśli wymagany jest podpis. Jednak jako osoba fizyczna, że osoba wnosi konkretny talent i wiedzę do konkretnej domeny zakupowej – komputery, podróże i środki utrzymania itp. i należy się z nią skonsultować, jeśli ma dokonać dobrego osądu. Odnosząc to konkretnie do działania współpracującej infrastruktury komputerowej, widzimy, że musimy zachować te różnice i wzajemne powiązania. Rozważymy jeden z przykładów: przypadek obsługi wiadomości e-mail od klientów. W tym przypadku potrzebujemy oprogramowania, które może kierować pocztę do dowolnej grupy osób, a nie do pojedynczych osób, w taki sam sposób, w jaki automatyczny przełącznik połączeń kieruje przychodzące połączenia telefoniczne do dowolnego z wielu agentów call center. Powodem takiego postępowania jest to, że na centrum odbioru e-maili spoczywa zbiorowa odpowiedzialność za udzielenie szybkiej i pełnej odpowiedzi na zapytanie klienta, a nie czekanie, aż jedna konkretna osoba stanie się dostępna. Wiadomość e-mail jest kierowana do „centrum”, a nie do osoby (chyba, że, jak to jest możliwe w takich systemach, obsługa wyjątków nakazuje kierowanie poczty do konkretnej osoby). Z drugiej strony wspólne opracowywanie produktu, które obejmuje interakcję poszczególnych członków rozproszonego zespołu projektowego, wymaga nawiązania z nimi kontaktu w sposób, który promuje swobodny przepływ informacji, a także zachęca do empatii między tymi konkretnymi osobami. Jednym z takich mechanizmów są systemy konferencyjne.

Kompleksowy e-biznes obejmuje nie tylko więcej procesów niż tylko zapewnienie eSklepu; niektóre z tych procesów mają również bardziej krytyczne właściwości. Możemy być gotowi wrócić do sklepu, który nie zawsze pokazywał nam wszystko, co ma na stanie. Być może moglibyśmy tolerować taki, który twierdził, że ma przedmioty, z których go nie było. Ale bylibyśmy znacznie mniej chętni do ponownego odwiedzenia takiej, która zabrała naszą kartę kredytową i nigdy jej nie zwróciła ani nie obciążała jej zakupami innych osób. Jest kilka zadań, które należy wykonać całkowicie i poprawnie. Techniczne środki do osiągnięcia tego to przetwarzanie transakcji. Często używamy terminu „transakcja” dość luźno, w znaczeniu interakcji między stronami lub systemami. W tej sekcji używamy jednak tego słowa w znacznie bardziej ograniczonym sensie, aby opisać interakcje, które mają dość specyficzne właściwości.

† Atomowość: transakcje mają miejsce lub nie mają miejsca – nie ma czegoś takiego jak transakcja częściowo zakończona. Jeśli transakcja nie została w pełni zrealizowana, oznacza to niepowodzenie, a wszystkie dane i stany zaangażowanych systemów muszą powrócić do swoich wartości, tak jakby transakcja nigdy się nie rozpoczęła.

† Spójność: ogólne „zasady” procesu, w którym odbywa się transakcja, w żadnym momencie nie powinny zostać naruszone – na przykład rachunki finansowe powinny być zbilansowane przed, po i w trakcie transakcji.

† Izolacja: transakcje są przeprowadzane niezależnie od siebie, nawet jeśli kilka odbywa się jednocześnie w tym samym środowisku. Implikacją tego jest zakazanie dwóm transakcjom jednoczesnego działania na tym samym fragmencie danych.

† Trwałość: po zakończeniu transakcji jej wpływ na dane i stany systemu powinien się utrzymywać – skutki transakcji powinny trwać dłużej niż czas trwania procesu transakcyjnego.

Patrząc w mniej abstrakcyjny sposób, warunki te muszą wydawać się oczywiście rozsądne: jeśli pieniądze są przekazywane z jednego konta na drugie, końcowym produktem musi być zmniejszenie jednego konta i zwiększenie drugiego (pomniejszone o wszelkie opłaty za usługę). Pieniądze nie powinny „opuszczać” jednego konta i nie docierać na drugie, na przykład z powodu awarii sieci. Transakcja audytu i równoważenia, która w połowie swojej operacji tymczasowo zamienia saldo dodatnie na moim koncie na saldo ujemne, nie powinna pozwolić transakcji obliczania kredytu w rachunku bieżącym na zobaczenie zmienionych danych i naliczenie odsetek od kredytu w rachunku bieżącym. Wreszcie, po dokonaniu przelewu na moje konto, nie spodziewałbym się, że przelew zniknie, ponieważ program przetwarzający przeszedł na coś innego. Przetwarzanie transakcji jest dość trudne i tak naprawdę nie podziela trybu kulturowego twórców stron internetowych: nie chodzi o szybki sukces przedsiębiorczy; chodzi raczej o konsekwentne zapobieganie niepowodzeniom. Na szczęście przetwarzanie transakcji ma długą historię w systemach mainframe, takich jak IBM CICS i gotowe rozwiązania kompatybilne z siecią WWW. Szczegóły dotyczące tych systemów są złożone, ale warto zapoznać się z niektórymi związanymi z nimi zasadami. Centralnym elementem operacji jest koncepcja menedżera transakcji, który współdziała z wieloma menedżerami zasobów.

Rolą menedżera transakcji jest pełnienie roli centralnego punktu koordynującego szereg operacji bazodanowych związanych z transakcją. Współdziała z menedżerami zasobów, które są ochronnymi opakowaniami umieszczonymi wokół różnych baz danych. Gdy instancja transakcji jest tworzona (tj. gdy klient składa zamówienie), menedżer transakcji najpierw tworzy w pamięci zdefiniowaną przestrzeń dla tej konkretnej transakcji. Następnie kontaktuje się z odpowiednimi menedżerami zasobów, aby zwerbować ich do utworzenia instancji ich operacji na danych, które można prześledzić wstecz do tej konkretnej transakcji. Mówiąc dokładniej, rozważmy, w jaki sposób metody Enterprise JAVA JDBC pozwalają nam obsłużyć transakcję składającą się z wielu operacji na bazie danych. Załóżmy na przykład, że chcemy przyjąć zamówienie na niektóre towary, pod warunkiem, że kontrola kredytowa potwierdziła, że ​​klient ma środki.

† W przypadku prostej operacji JDBC za każdym razem, gdy wykonujemy operację na bazie danych, ta pojedyncza operacja jest uważana za transakcję. Linia kodu odpowiadająca „umieszczeniu adresu klienta w bazie danych wysyłkowych” doprowadziłaby natychmiast do tego. Proces odpowiedzialny za wysyłkę towaru, który przebiega asynchronicznie, umieściłby więc tę pozycję na liście do wysłania – czego nie chcemy, aby działo się to automatycznie.

† Musimy więc wyłączyć automatyczną zmianę danych w bazie danych. Robimy to za pomocą prostej instrukcji, która wyłącza funkcję „autocommit” w poleceniach JDBC. Odbywa się to za pomocą wiersza kodu, który zawiera oświadczenie: „.setAutoCommit(false)”. Zasadniczo zmiana w bazie danych jest zawieszona. Prawdopodobnie chcemy również zrobić podobną rzecz z fakturą rozliczeniową dla naszego klienta. W ten sposób wszystkie polecenia bazy danych w określonym bloku kodu mogą być trzymane w napięciu.

† Teraz otrzymujemy wiadomość zwrotną z bazy danych o kredytach mówiącą, że kredyt X jest dobry. Następnie reaktywujemy żądania do odpowiednich baz danych.

† Ale jeszcze nie skończyliśmy; wiele innych rzeczy może pójść nie tak: na przykład wpis danych może być błędny lub tymczasowo niedostępny. Po pierwsze, wszystkie bazy danych muszą zwrócić komunikat, że mogą skutecznie zmienić dane w zadowalający sposób. Dopiero gdy to zrobią, komenda „.commit” otrzyma flagę „prawda”, która sygnalizuje wszystkim bazom danych, że można bezpiecznie kontynuować zmianę danych. Polecenie również następnie zwalnia wszelkie blokady, które wymusili wobec innych procesów, które chciały uzyskać dostęp do tych samych danych. Proces ten jest znany jako zobowiązanie dwufazowe i jest podstawowym elementem przetwarzania transakcji.

† Ale załóżmy, że coś pójdzie nie tak: kredyt jest zły lub baza danych przewróciła się: w tym przypadku flaga to „false”, a program wydaje polecenie „.rollback”, które przerywa transakcję, pozostawia dane we wszystkich bazy danych bez zmian i usuwa wszelkie blokady danych. Rzeczy wracają dokładnie do tego, czym były przed próbą transakcji.

Projektowanie oparte na komponentach jest stosunkowo nowe i nadal jest przedmiotem ożywionych dyskusji, w tym poważnej debaty na temat względnych zalet CORBA i DCOM. Względne zalety i wady często wynikają z różnych podejść przyjętych przez ich wynalazców: DCOM pochodzi ze stajni firmy Microsoft i, między innymi, daje znaczną moc klientom z systemem Windows. Aby podać tylko jeden przykład, DCOM garbage collection korzysta z prawa do niszczenia obiektów, gdy nie ma już do nich odniesień żaden klient. Z drugiej strony, CORBA zachowuje prawo serwera do utrzymywania tych obiektów, zapewniając w ten sposób lepszą skalowalność, ale wymagając napisania specjalistycznych rozwiązań dla każdej aplikacji. Nowy uczestnik, Enterprise Java, jest wyraźnie bardzo ważnym rozwiązaniem dla wymagań dotyczących  handlu elektronicznego i, w porównaniu z większością alternatyw, oferuje wygodne „proste” podejście. Jest to również, przynajmniej w zasadzie, w pełni otwarte rozwiązanie: niezależnie od konkretnego środowiska sprzętowego i programowego, na którym działa, wirtualna maszyna Java zapewnia programiście spójne środowisko programistyczne. Niestety, może to również stanowić problem: ponieważ kod maszyny wirtualnej musi zostać przetłumaczony na „prawdziwy” kod dla „prawdziwej” używanej maszyny, występują nieuniknione spadki wydajności, w szczególności szybkość. Z tego powodu deweloperzy w branżach, w których wymagane są procesy wymagające intensywnych transakcji, na przykład bankowość detaliczna, które generalnie zastrzegają ocenę, czy korporacyjna Java zapewni odpowiednie rozwiązanie. Inny problem pojawia się w przypadku starszego kodu: jak powiedzieliśmy, poprzez Java Native Interface (JNI) można zintegrować się z innymi językami, ale mogą pojawić się trudności z definicjami obiektów, które muszą być zakodowane w JAVA. Kontrastuje to z CORBA, która jest po prostu specyfikacją, pozwala na kodowanie obiektów w dowolnym języku, pod warunkiem, że istnieje funkcja biblioteki ORB. To dopiero początek, aby móc komentować bezpieczeństwo architektur komponentów. Można się martwić o moc, jaką DCOM daje klientom. Twierdzono również, że bezpieczeństwo CORBA jest nadal raczej szarą strefą. Mechanizmy bezpieczeństwa Javy powinny skorzystać na podejściu piaskownicy, chociaż należy zauważyć, że kod inny niż Java, połączony przez JNI, zachowa swoje własne luki. To powiedziawszy, zgodnie z naszą dyktaturą podaną w części 3.2 dotyczącą konieczności opracowania prostych operacyjnie procedur bezpieczeństwa, prawdopodobnie prawdą jest, że wszystkie omówione przez nas rozwiązania komponentowe ułatwią programistom ocenę bezpieczeństwa ich kodu niż dostępne wcześniej dla nich opcje. Na koniec powinniśmy zauważyć, że żadna z architektur nie została zaprojektowana z myślą o aplikacjach działających w czasie rzeczywistym, takich jak ciągłe przesyłanie strumieniowe wideo. Na razie nie jest to pilny wymóg, ale głupotą byłoby polegać na tym, by tak było przez dłuższy czas.

Ostatnio dość nowatorskie podejście, Enterprise Java ,przenosi zdolność interoperacyjności na szereg funkcji Java, które działają na serwerach. Wśród innych zalet wymienia się znaczną poprawę czasu opracowywania . Programy Java działają na zasadzie, że działają na wirtualnej maszynie JAVA – oprogramowaniu działającym na dowolnym komputerze lub systemie operacyjnym, które zostało zdefiniowane tak, aby zachowywać się jak standardowa idealizacja komputera, niezależnie od tego, co znajduje się pod nim . Jednym ze szczególnych aspektów tych programów niezależnych od komputera jest serwlet Java. Serwlety działają na większości serwerów WWW (podobnie jak ich odpowiedniki klienckie, aplety, działają na większości przeglądarek klienckich) i działają w środowisku maszyny wirtualnej (lub „piaskownicy”). Jak pokazano na rysunku, typowe aplikacje serwletu mogą obejmować dostęp do bazy danych lub wywołanie zdalnej metody (RMI). Aplet jest wywoływany i ładowany do pamięci maszyny wirtualnej tylko raz, na początku uruchomionego programu, a następnie może obsługiwać kilka żądań jednocześnie, po prostu tworząc zduplikowany blok w innej części pamięci dla nowego zadania. (Jest to powszechnie stosowana technika obliczeniowa, w której każdy nowy bit kodu rezydującego w pamięci jest nazywany wątkiem, a proces nazywany jest wielowątkowością. Wielowątkowość jest wydajna i szybka, ponieważ nie musimy ładować i uruchamiać nowej wersji programu dla każdego zadanie.) Serwlety wykonują swoje wyspecjalizowane operacje za pośrednictwem interfejsów, takich jak Java Database Connectivity, JDBC (dla baz danych) i Remote Method Invocation, RMI (do uruchamiania zdalnych procesów lub metod, jak określa się je w modelu obiektowym, który Jest używane). RMI pełni funkcje podobne do CORBA; jego podejście zorientowane obiektowo pozwala na wywoływanie i interakcję z obiektami na zdalnych serwerach, za pośrednictwem kodów pośredniczących (instrukcje interfejsu po stronie klienta dla obiektu zdalnego) i szkieletów (kontrolki po stronie serwera do wywoływania obiektu i przekazywania do niego parametrów), podobnie do CORBA Odcinki IDL. Java posiada również Java Native Interface, JNI, który umożliwia integrację kodu C i C11 z programami Java. Jest to wygodny sposób integracji starszych programów ze środowiskiem Java, ale tylko wtedy, gdy mają interfejsy C lub C11. Jeśli tak nie jest, jednym z rozwiązań jest użycie CORBA jako oprogramowania pośredniczącego między Enterprise JAVA a starszą aplikacją. Można to wykorzystać na przykład do integracji dużych programów w języku COBOL i korporacyjnych aplikacji Java .

Powyższa dyskusja przeszła do czwartej warstwy na rysunku 1.26, która dotyczy rozwoju aplikacji w e-biznesie, które naprawdę wyróżniają go jako „on-line”. We wcześniejszych rozdziałach odnosiliśmy się do różnych elementów oprogramowania niezbędnych do podstawowych aplikacji detalicznych eCommerce: HTTP, HTML, aktywne strony, aktywne X, Java i tak dalej. Są one również wymagane w przypadku aplikacji wewnątrz- i wewnątrz-biznesowych, ale przy znacznie większej potrzebie bardziej złożonej interakcji między klientem a serwerem, na przykład: przetwarzanie transakcji, elektroniczna wymiana danych standardowych faktur, zlecenia typu call-off itp. Te aplikacje muszą również działać w trybie bardzo rozproszonym w tak zwanych architekturach n-warstwowych (tj. obejmujących kilka serwerów aplikacji) o wysokim stopniu niejednorodności sprzętu. Jak pokazuje rysunek 1.26, chcielibyśmy, aby aplikacje działały spójnie w środowiskach, które wykorzystują wiele systemów operacyjnych hosta, które mogą uruchamiać różne oprogramowanie pośredniczące i korzystać z różnych baz danych. Możliwe jest tworzenie aplikacji w wielu językach programowania, aby działały na przykład w oprogramowaniu pośredniczącym CORBA, i podobnie do pisania programów zapytań do baz danych, aby uzyskać dostęp do baz danych ORACLE SQL, IBM DB2 itp.

Object Management Group dostrzegła znaczenie e-biznesu w swoich obszarach zainteresowań i stała się bardzo aktywna w próbach zdefiniowania funkcjonalności CORBA i funkcji OMA na tym polu. Jako grupa standardów, ich podejście jest naturalnie raczej przemyślane niż pochopne i dlatego może cierpieć z powodu niebezpieczeństwa wyprzedzenia przez wydarzenia. Jednak obecnie wydaje się, że mają pewien wpływ na kierowanie kolejnymi krokami w architekturze e-biznesu, a także widzą implementacje CORBA na większości popularnych platform. Dlatego warto zastanowić się nad niektórymi aspektami infrastruktury CORBA, które mają szczególne zastosowanie w e-biznesie. Rysunek

przedstawia w ujęciu CORBA/OMG procesy, które tworzą razem e-biznes, przynajmniej w takim zakresie, w jakim wymagają one przetwarzania rozproszonego. Niektóre, takie jak być może płatności, katalog i własność intelektualna (IPR), są oczywiste, podobnie jak ogólne obiekty biznesowe, obiekty i usługi pokazane na dole rysunku. Niektóre inne mogą wymagać wyjaśnienia:

† Dane semantyczne: dzisiejsze instancje procesów handlowych on-line zostały opracowane ad hoc, przy czym każdy programista pracuje z różnymi jednostkami podstawowymi i z własnymi konwencjami nazewnictwa. Oznacza to, że nie jest łatwo połączyć rozwiązanie jednej osoby z rozwiązaniem innej, a nawet utrudnia wspólne zrozumienie wymagań.

† Ułatwienia negocjacyjne: negocjacje muszą być wielostronne (przynajmniej dwustronne). W związku z tym należy je zdefiniować w spójny sposób, aby umożliwić stronom rozszerzenie swoich komponentów handlowych w stosunku do siebie nawzajem i umożliwić powiązanie ogólnych wartości (na przykład ceny) z konkretną wartością (dolary amerykańskie, funty szterlingi itp.). ) w sposób spójny między wszystkimi uczestnikami.

† Usługi umowne: podobnie te usługi, które określają poddziałania w ramach umowy lub mogą odnosić się do ogólnych ustaleń umownych, również wymagają spójnej specyfikacji.

† Usługi maklerskie i agencyjne: nad tymi obiektami znajduje się wyższy poziom zgrupowania obiektów związanych z ogólną infrastrukturą rynkową, z których szczególnie interesujące są usługi handlowe i maklerskie. Zapewniają one możliwość rozsyłania reklam wymaganych usług i rekrutowania usługi zdalnej zgodnej z profilem. Model procesu transakcyjnego dla takich czynności, jeśli mają być przeprowadzane automatycznie, jest oczywiście dość skomplikowany i znowu standaryzacja będzie korzystna.

OMG i inne organizacje ciężko pracują, aby urzeczywistnić te pomysły, z których wiele jest nadal koncepcyjnych.

Bardzo istotnymi składnikami usług CORBA są usługi „nazewnictwa” i „handlu”. Nazewnictwo jest prostsze. CORBA posiada zbiór katalogów systemowych, które ustalają korespondencję między nazwą obiektu a jego aktualną lokalizacją, tak jak sieć telefonii komórkowej może przekierować połączenie, opisane numerem telefonu, na konkretną antenę obsługującą komórkę, w której o nazwie strona obecnie jest. (Po prostu używasz nazwy; usługa CORBA utrzymuje ścieżkę do obiektu.) Ale to zakłada, że ​​wiesz, do kogo chcesz zadzwonić (a także, być może, w jakim celu i na jakich warunkach). Załóżmy, że chcesz dowiedzieć się, kto może sprzedać Ci dany typ samochodu, za jaką cenę i jak szybko. Musisz zajrzeć do katalogu Yellow Pages, który zawiera listę firm objętych usługami, które oferujesz, i uzyskać numer kontaktowy. To część tego, co zrobi usługa Trader. Pozwoli Ci to zidentyfikować źródła potrzebnych Ci obiektów. Na początku mogą to być proste usługi, takie jak aplikacja do bezpiecznego „znakowania wodnego” danych przed kradzieżą praw autorskich, ale w zasadzie powinna być w stanie znaleźć listę wirtualnych organizacji, które mogą zdalnie zarządzać zasobami ludzkimi na przykład oprogramowanie dla Twojej organizacji. Sprzedawca nie tylko podaje nazwy odpowiednich obiektów; podaje również szczegółowe informacje o oferowanych przez nich usługach – szybkości, kosztach, polityce bezpieczeństwa i tak dalej. W tym momencie należy powiedzieć, że niektóre właściwości Tradera muszą jeszcze zostać zdefiniowane przez OMG, a większość korzyści z usług Tradera można jedynie postulować. Niemniej jednak, podstawowe koncepcje są powszechnie akceptowane, a CORBA staje się powszechnie wykorzystywana jako platforma dla zaawansowanych usług.

Sama CORBA zajmuje się interfejsami między obiektami i sposobem ich określania w IDL. Jest to najniższy poziom kompleksowej architektury zarządzania obiektami („OMA”), który obejmuje wizję nienastawionej na zysk kooperacyjnej grupy dostawców, znanej jako Object Management Group (OMG). Ich ideą jest stworzenie, w drodze konsensusu, wspólnej architektury dla przetwarzania rozproszonego, zbudowanej wokół opisanych powyżej zasad obiektowych. Oddzielają one podstawowe, niższego poziomu usługi dla obiektów, poziom CORBAservices, od udogodnień udostępnianych aplikacjom, poziom CORBAfacilities  

Usługi CORBA obejmują bardziej podstawowe i ogólne potrzeby wspólne dla większości obiektów: takie rzeczy jak nazewnictwo, zapytania, grupowanie obiektów, bezpieczeństwo i tak dalej. Wiele z nich jest dostępnych w stabilnej formie od kilku dostawców. Placówki CORBA są raczej słabiej rozwinięte. Zdefiniowano cztery podstawowe kategorie: interfejs użytkownika, zarządzanie informacją, zarządzanie systemami, zarządzanie zadaniami. Są one wyraźnie przydatne we wszystkich rozproszonych aplikacjach biznesowych. „Pionowe” obiekty CORBA są również generowane dla określonych sektorów rynku, takich jak opieka zdrowotna i finanse. Polityką OMG jest przyjęcie istniejących modeli informacji i procesów już stworzonych przez te sektory i zintegrowanie ich z OMA, na przykład poprzez tworzenie nowych interfejsów IDL.

Wyobraźmy sobie przypadek żądania od „klienta” (czyli od procesu wykonywanego w dowolnym miejscu w systemie rozproszonym) dla obiektu. Na przykład klient może chcieć wywołać obiekt TAXM, aby poradzić sobie z kalkulacją podatku. W implementacjach CORBA klient nigdy nie komunikuje się bezpośrednio z obiektem; żądanie zawsze przechodzi przez Object Request Broker (ORB), część oprogramowania CORBA, która działa jako bufor upraszczający między klientem a obiektem

Celem ORB jest ukrycie przed programistą aplikacji zawiłości radzenia sobie ze środowiskiem rozproszonym, które ponadto może składać się z heterogenicznego zestawu komputerów. ORB znajduje obiekt i obsługuje szczegółowe parametry żądania. Jego zadaniem jest zasadniczo zapewnienie przejrzystości lokalizacji i dostępu. Czyni to poprzez interfejsy IDL, jak pokazano. (Nawiasem mówiąc, można zauważyć, że ORB pasuje do naszej definicji obiektu CORBA.) W systemie rozproszonym może być kilka ORBów, każdy zamontowany na innym zestawie komputerów. Klienci wysyłają ich prośby do lokalnego ORB. Załóżmy, że poszukiwany obiekt nie znajduje się na obszarze objętym lokalnym ORB? Nie ma problemu, lokalny ORB po prostu komunikuje się z lokalnym ORBem obiektu

Kolejną zaletą tego podejścia jest to, że różne ORBy mogą znajdować się na platformach sprzętowych i programowych różnych dostawców i być napisane w zupełnie różnych językach, zgodnie z różnymi projektami wewnętrznymi. Wystarczy, że są w stanie zapewnić funkcje CORBA określone w ich interfejsach.