CORBA:Umpadroabertoparacomputaodistribudaesua aplicabilidadenareamdica(CORBAmed)

JeronimoVicenteFarias

2004

JeronimoVicenteFarias

CORBA:Introduzindoacomputaodistribudaeverificandosua aplicabilidadenareamdica(CORBAmed)
Monografia submetida disciplina de Projeto Supervisionado, do curso de bacharelado em CinciasdaComputaodaUniversidadeFederalde MatoGrossocomorequisitodeavaliao. Orientador:MscNelcilenoVirgliodeSouza

Bancaexaminadora: Msc.JosdePaulaNevesNeto Msc.JosTelesLopes Msc.NelcilenoVirgliodeSouza

Cuiab MatoGrossoBrasil 2004

Aosmeuspais,JooeElenice, semprepresenteseimportantesemtodosos momentosdaminhavida,quemeimbuiram deperseverananashorasemquemais precisei; Aminhanamoradarika, porseuamorecompreenso;

OFEREO

Talveznotenhamosconseguidofazero melhor,maslutamosparaqueomelhorfosse feito...Nosomosoquedeveramosser,no somosoqueiremosser.Mas,graasaDeus, nosomosoqueramos... MartinLutherKing

Aos familiares, amigos ebons exemplos profissionais, sobretudo aprofessoraEdna AyakoHoshino;

DEDICO

AGRADECIMENTOS

Meussincerosagradecimentosaomeuorientador,SenhorNelcilenoVirgliodeSouza, porsuainabalvelpersistncia,quemepermitiuconcluiratempoestetrabalho,aos senhoresRamonAlfredoMorenoeSrgioShiguemiFuruie,doInstitutodoCorao, Hospital das Clnicas da Universidade de So Paulo, pelas suas contribuies tempestivasquemelevaramdaabstraodemodelosaumaaplicaoespecializada. Igualmente ao Dr. Jorge Risco Becerra, do Laboratrio de Sistemas Abertos, DepartamentodeEngenhariadeComputaoeSistemasDigitasdaEscolaPolitcnica daUSP,quecolaborouprontamentecomvriosartigosquedirecionaramoinciodeste trabalho. AgradeotambmaoSERPROServioFederaldeProcessamentodeDados,porter meproporcionadoaflexibilidadedehorriosnecessriaaconcluso,nosdeste,como detodoomeutrabalhoacadmiconodecorrerdestesquasequatroanosemeio.

Sumrio
Resumo.............................................................................................................................ix 1Introduo.......................................................................................................................1 1.1Omotivodotrabalho..............................................................................................1 1.2Estruturadotrabalho...............................................................................................2 1.3Metodologiautilizada.............................................................................................2 2AevoluoapartirdosSistemasOperacionaisDistribudos.........................................3 2.1Contextohistrico...................................................................................................3 2.2DefiniodeSistemasDistribudos........................................................................5 2.3CaractristicasgeraisdosSistemasDistribudos....................................................6 2.3.1Vantagens........................................................................................................6 2.3.2Desvantagens...................................................................................................8 2.4ContextualizaodosSDs.....................................................................................10 2.4.1SistemasOperacionaisdeRede.....................................................................10 2.4.2SistemasdeCompartilhamentodeTempoMultiprocessados.......................11 2.4.3SistemasVerdadeiramenteDistribudos.......................................................12 2.5DiretrizesdeprojetodosSDs...............................................................................14 2.5.1Transparncia................................................................................................14 2.5.2Flexibilidade..................................................................................................15 2.5.3Confiabilidade...............................................................................................17 2.5.4Desempenho..................................................................................................18 2.5.5Escalabilidade................................................................................................19 2.6Concluso.............................................................................................................20 3AespecificaoCORBAenquantomiddleware...........................................................22 3.1Definindomiddlewares.........................................................................................22

3.2ACommonObjectRequestBrokerArchiteture(CORBA)..................................25 3.2.1DefinindoCORBAenquantomiddleware....................................................25 3.2.2AarquiteturaCORBAnoObjectManagementArchiteture(OMA)............26 3.3OfuncionamentodaCORBA...............................................................................29 3.3.1OncleoORB...............................................................................................32 3.3.2Alinguagemdedefiniodeinterfaces(LDI)..............................................35 3.3.2.1TiposdedadossuportadospelaLDI.....................................................36 3.3.2.2Heranadeinterfaces.............................................................................37 3.3.3Mapeamentosdelinguagens.........................................................................39 3.3.4RepositriodeInterfaces...............................................................................40 3.3.5DefinindoStubseSkeletons.........................................................................42 3.3.6Invocaoeencaminhamentodinmico........................................................42 3.3.6.1Interfacedeinvocaodinmica...........................................................43 3.3.6.2Interfacedeencaminhamentodinmico................................................45 3.3.7ProtocoloInterORB(PIO)...........................................................................45 3.3.8Osadaptadoresdeobjeto(AO).....................................................................47 3.3.8.1FuncionalidadedoAO...........................................................................49 3.3.8.2AdaptadorBsicodeObjeto(ABO)......................................................50 3.3.8.3AdaptadordeObjetoPortvel(AOP)....................................................51 3.4Concluso..............................................................................................................55 4ContribuiesCORBAparareamdica....................................................................56 4.1Motivaoparaaadoodepadresnareamdica...........................................56 4.2ApresentaodostrabalhosdaHealthDomainTaskForce(HDTF)...................57 4.2.1ComootrabalhopromovidopelasDomainTaskForces(DTF)juntoa OMG.......................................................................................................................57 4.3AsespecificaesCORBAparaodomniodeSade...........................................58 4.4AplicaodasespecificaesdefinidasnoCORBAmed......................................59 4.4.1 Apresentao do grupo de Pesquisa e Desenvolvimento da Diviso de InformticadoInCor..............................................................................................59

4.4.2AnlisedautilizaodeespecificaesCORBAmedpeloInCor.................60 4.4.3OpiniodogrupoP&DdoInCorsobreCORBAeCORBAmed.................64 4.5Concluso..............................................................................................................66 RefernciasBibliogrficas...............................................................................................67

LISTADEABREVIATURASESIGLAS

ix

ListadeTabelas
Tabela1EvoluodosprocessadoresIntel(TANENBAUM,2001,p.18)....................4 Tabela2VantagensdosSDs...........................................................................................8 Tabela3DesvantagensdosSDs......................................................................................9 Tabela4Classificaogeraldossistemas....................................................................13 Tabela5ComparativoentreORBs(FOREMAN;WALLNAU,1997).........................35 Tabela6TiposdedadosLDI,extradade(VINOSKI,1997;OMG,2004a)..............37 Tabela7EspecificaesCORBAmed...........................................................................58

ListadeFiguras
Figura1Esquemadekernelmonolticoemicrokernel(TANENBAUM,1995)..........16 Figura2EsquemadaOMA............................................................................................26 Figura3EsquemaCORBA............................................................................................30 Figura4ExemplodedefinioLDI(VINOSKI,1997).................................................36 Figura5ExemplodedefinioLDI(VINOSKI,1997).................................................38 Figura6Papeldeumadaptadordeobjeto.....................................................................48 Figura7ExemplodedefinioLDI(VINOSKI,1997).................................................53 Figura8ArquiteturadoprojetoPACSHC...................................................................61 Figura9EsquemadeimplementaoCIAS...................................................................63 Figura10MdulosdoVisualizadorContextual............................................................64

xi

Resumo
As tecnologias envolvidas comainformticaevoluem independentementeumas das outras.Aadoodenovasopestecnolgicas,noentanto,noimplicanoabandono deantigassolues. Estaformadeavanotemtornadoosambientescomputacionais modernosbastanteheterogneos.Onvelatualdeheterogeneidadetemsemostradoum grande obstculo a integrao de recursos existentes, implicando muitas vezes na subutilizaoderecursos.Pensandonisso,frentesdepesquisavoltaramseusesforos para especificao de solues capazes de integrar equipamentos, redes e sistemas. Dentreosresultadosdestaspesquisas,sobressaiseaespecificaodaCommonObject RequestBrokerArchitecture,CORBA.Frutodotrabalhodediversasempresasdoramo detecnologiaedegrandesclientespotenciais,aCORBAtemsemostradoumasoluo consistenteparaoproblemadeinteroperabilidade.AespecificaoCORBA,enquanto opoparaintegraodeambientesdistribudos,otemadestetrabalhoqueprope, tambm,demonstrarcomoaCORBApodeseraplicadaareamdica,contandocom experinciapromovidapeloInstitutodoCoraodoHospitaldasClnicasdaFaculdade deMedicinadaUSP(InCorHC.FMUSP).

xii

CaptuloI
1Introduo
1.1Omotivodotrabalho
Grande parte da evoluo humana atribuida a habilidade de comunicarse. Notadamente,talhabilidademostrouseigualmenteimportantenareacomputacional, interconectando equipamentos e permitindo a troca da to preciosa informao. O marco evolutivo na adoo de ambientes baseados na integrao foi a mudana do antigoparadigmacentralizadodecomputao,baseadoemcomputaodegrandeporte, os mainframes,paraamicrocomputaoemambientesdistribudos.Estemovimento ficou amplamente conhecido pelo termo downsizing. Os ambientes baseados na computao remota, compartilhada por equipamentos conectados de alguma forma, ficaramconhecidosporsistemasdistribudos,SDs. Nocenriodeadoodacomputaodepequenoportesurge,noinciodadcadade90, umainovadorapropostadeintegraopromovidaporumconceituadogrupodembito mundial,o ObjectManagementGroup,OMG. Talpropostaconsistiudeumpadro capaz de integrar elementos computacionais linguagens de programao, sistemas operacionais, arquiteturas de computadores, etc por mais heterogneos que estes fossem. O trabalho conduzido pelo OMG foi ento batizado de Common Object RequestBrokerArchitecture,ousimplesmenteCORBA. AabrangnciadapropostaCORBA,assimcomooambientedecolaboraonoqualela 1

foiconstrudatornamseuestudorecompensador.Poressesmotivosocenrionoqual foiconstrudaaespecificaoCORBA,elaprpriaesuaaplicaoprticasotema destetrabalho.

1.2Estruturadotrabalho
EstetrabalhodeconclusodecursodegraduaoapresentaaespecificaoCORBA comoopodeintegraodeambientesheterogneoseasuaimportnciaparaarea mdica.Paraissootrabalhofoidivididoemtrscaptulos,sendooprimeirodedicado aosprimeirosestudoscomsistemasdistribudos,osegundoaapresentaodaCORBA eoltimodoscaptulosapresentaaaplicaodaCORBAnareamdica.

1.3Metodologiautilizada
A pesquisa efetuada neste trabalho foi focada para profissionais que possuam a demanda de integrar ambientes caracterizados por diversidade de plataformas de software,hardwareerede.Alinguagemutilizadonotrabalhopressupequeosleitores possuam conhecimentos bsicos de redes, sistemas operacionais e engenharia de sistemas. A metodologia utilizada para construo deste texto foi a de reviso bibliogrfica, associada a interao com a equipe de Pesquisa e Desenvovimento do Instituto do CoraodoHospitaldasClnicasdaFaculdadedeMedicinadaUniversidadedeSo PauloquecolaboroucomrelatossobreaexperinciadelanautilizaodaCORBAem projetos pertinentes a rea mdica. Com o propsito de avaliar a usabilidade de solues de baixo custo baseadas em CORBA, foram promovidos alguns testes baseadosno middleware JacORB,verso2.0,enalinguagemJava,comoSunJDK 2

1.4.2.

CaptuloII
2SistemasDistribudos
2.1Contextohistrico
(TANENBAUM, 1995) introduziu Sistemas Distribudos, SDs, relacionandoos com uminevitvelpontonalinhaevolutivadacomputaomoderna.Sobretudonosmeados da dcada de 80, quando os avanos tecnolgicos revolucionaram o estado da arte vigentecomodesenvolvimentodepoderososmicroprocessadoreseosurgimentode redesdecomputadoresdealtavelocidade. Tamanho foi o avano nestas duas reas, tal que outras indstrias jamais o experimentaram. Naesferadosmicroprocessadores,aindaem1965,GordonMoore, cofundadoreexdiretordaIntelenunciouarelaoondeprediziaqueacada18meses onmerodetransistoresintegradosemumchipdobraria.Talprevisoficouconhecida algumtempodepoispor leideMoore1 (verTabela1),dadoqueelavinhaevemse confirmandoatosdiasdehoje.(TANENBAUM,2001)Destarte,ocustoassociadoaos microprocessadoressofreuquedainversamenteproporcionalaoaumentonacapacidade deprocessamento.Mquinascujocustoerade10milhesdedlaresedesempenhode 1 instruo por segundo, foram dando lugar a outras com custo de 1000 dlares e desempenho de 10 milhes de instrues por segundo. Um ganho na relao
1 Apesardeconhecidacomotal,a leideMoore nosetratadeumalei,naacepodapalavra. Oenunciado baseiase na verdade em uma observao emprica do estado da arte relacionado a fabricao de circuitos integradoseaumaprevisodequeambascontinuariamevoluindonamesmarazo.(TANENBAUM,2001)

preo/desempenhodaordemde1011.(TANENBAUM,1995)

Tabela1EvoluodosprocessadoresIntel(TANENBAUM,2001,p.18)
Chip 4004 8008 8080 8086 8088 80286 80386 80486 Pentium PentimPro PentiumII Data Apr/71 Apr/72 Apr/74 Jun/78 Jun/79 Feb/82 Oct/85 Apr/89 Mar/93 Mar/95 May/97 MHz 0.11 0.18 2 510 58 812 1633 25100 60233 150200 233400 Transistores 2,300 3,500 6,000 29,000 29,000 134,000 275,000 1,200,000 3,100,000 5,500,000 7,500,000 Memria 640 16KB 64KB 1MB 1MB 16MB 4GB 4GB 4GB 4GB 4GB Notas Primeiroprocessadoremumnicochip Primeiromicroprocessadorde8bits Primeiroprocessadordepropsitogeralemumchip Primeiroprocessadorde16bitsemumchip UsadonoPCdaIBM Chipcomproteodememria Primeiroprocessadorde32bits Memriacachede8Knochip Dois pipelines; modelos posteriores tinham suporte para processamentoMMX Memriacachededoisnveisnochip PentiumProcomsuporteparaprocessamentoMMX

Quasesimultaneamenteocorreramasevoluesdosmicroprocessadoreseredes. No casodasredes,oavanoocorridopermitiuqueacomputaosassedeumcenriode computadoresisoladosunsdosoutrosparaocenriocontemporneodeconectividade entremquinasespalhadaspelomundotodo.Asignificativaevoluodasredesnose deu apenas sob o aspecto de abrangncia entre mquinas interligadas, mas tambm

sobreodavelocidade.Atualmentedadostrafegamsobreredesaoredordomundoa velocidades que variam da ordem de kilobites por segundo (Kbps), a gigabites por segundo (as velocidades de Gbps so alcanadas em algumas redes experimentais avanadas).(TANENBAUM1995) Aassociaodosavanosmencionadostornoupossvelatarefadecolocarumgrande nmerodecomputadorestrabalhandosobreredesdealtavelocidade. Estecontexto passouaserchamadodeSistemasDistribudos,contrastandoseaomodeloanteriorde SistemasCentralizados(ousistemasdeprocessadornico),compostosporumanica unidadecentraldeprocessamento,UCPmaismemria,perifricosealgunsterminais. (TANENBAUM,1995) Noprimeiromomento,apesardeexistircondiesfsicasparaconexodedispositivos, afaltadeprogramasadequados materializousecomoumsrioproblema.Sobretudo sentiusefaltadesistemas operacionais quesuportassemnovasnecessidades. Desta forma,arealidadeque,nocomeo,ainfraestruturafsicaencontravaseprontapara promoverosSDsmas,osoftware,apartelgicaresponsvelpelogerenciamentodo novo ambiente, ainda estava em estgio embrionrio. (TANENBAUM, 1995; SILBERSCHATZet.al.,2000) A necessidade de adaptar programas a cooperarem sobre um ambiente de rede convergiu para si grande esforo da comunidade cientfica do mundo todo. Os primeiros resultados destes esforos vieram incorporados a novos sistemas operacionais. sobreaadaptaodossistemasoperacionaisparatrabalharemsobre redesquetrataestecaptulo.

2.2DefiniodeSistemasDistribudos
AidealizaodoqueseriamosSDsserviudenorteparaaevoluodoscomponentes que compunham este sistema. Como acontece com os paradigmas emergentes, de maneirageral,surgiumaisdeumadefinioparaosSDse,comotempo,algumas deram lugar a outras. Para Tanenbaum (1995, p. 2. traduo nossa) um sistema distribudoumacoleodecomputadoresindependentesqueaousurioapresentamse comoumnicocomputador.. Outra definio proposta por Silberschatz, Galvin e Gagne (2000, pg 333), quando comparadaadeTanenbaum,mostraaindefiniodealgunsaspectossobreosSDs.Eis a definio dada pelos autores: Um Sistema Distribudo uma coleo de processadoresfracamenteacopladosinterconectadosporumarededecomunicao.. PercebesenitidamentequeaproposiofeitaporSilberschatz,GalvineGagnelimita seadefinirapenasainteraoentreoscomponentesdoambientecomputacional,no contemplando a preocupao de tornar este ambiente transparente ao usurio. Conformedemonstradoadiante,apremissadequeatransparnciaaousuriopea chavedosSDsacabouprevalecendo.

2.3CaractristicasgeraisdosSistemasDistribudos
Paraqueasubstituiodoparadigmadecomputaocentralizadapelodecomputao distribuda fosse proveitosa, foi necessrio ponderar certos pontos que envolviam o projetodeumSD. Algumasvezes,fatoresenvolvidosnosproblemaspertinentesaos ambientes desencorajavam a adoo destes sistemas, conforme lembra Tanenbaum (1995).Porestemotivo,seguemasvantagensedesvantagensidentificadasnaadoo

dosSDs.

2.3.1Vantagens
At a revoluo proporcionada pelos microprocessadores, organizaes dispendiam tudooquepodiamparaadquirirumanicamquinademaiorpodercomputacional possvel.IstopodeserilustradoatravsdoenunciadoporHerbGrosch,conhecidopor leideGrosch:OpodercomputacionaldeumaUCPproporcionalaoquadradodoseu preo,(TANENBAUM,1995,pg3,traduonossa). DesdeosmicroprocessadoresaleideGroschjnopodesermaisaplicada.Nosdias dehoje,porumaquantiainferioramildlarespodeseadquirirumaUCPcompoderde execuo, em intrues por segundo, maior do que o dos maiores mainframes encontradosnadcadade80.Mesmoqueaquantiainvestidasejadobrada,temseque provavelmente, a mesma UCP ser adquirida, contudo, com um clock de maior velocidade.(TANENBAUM,1995) Tanenbaum(1995)alertaqueprecipitaoaqirirmuitasmquinascasonotenhase emmentefazlascooperaremobjetivoscomuns.Proverumamquinaacadausurio e mantla independente do resto do ambiente deixa margem alternativas que implicamemgrandereduodecustos,porexemplo,ocompartilhamentodeperifricos e/oudados. A necessidade iminente de tornar a troca de informao, a comunicao, o mais eficientepossvel,constituioutroimportantepontoaserconsideradonasorganizaes emgeral. Tanenbaum(1995,pg6)exemplificaaimportnciadeumacomunicao eficientecomaadoodacorrespondnciaeletrnica.Aocomparlacomoutrosmeios de comunicao, ela sobressaise sobre a correspondncia convencional por sua 8

velocidade,aotelefoneporsuadisponibilidadeeaoFAXpelasuaflexibilidade. As caractersticasvelocidade,dispobilidadeeflexibilidadetemdesersatisfatriasparaque um meio de comunicao seja considerado eficiente. Os SDs objetivam uma comunicaoeficienteeaoferecemcomovantagemaosqueosadotam. UmaltimavantagemapontadaaflexibilidadeproporcionadapelosSDs.Amedida queousodasUCPsintegrantesdoSDracionalizada,osistemaofereceflexibilidade ao usurio. Como j proposto, a aquisio de computadores, em geral, dada basicamente em funo da sua relao capacidade de processamento em relao ao preo. Nadamaissensato,portanto,doqueaproveitaraomximoadisponibilidade desterecurso.AracionalizaoproporcionadapelosSDsamedidaemqueelesfazem balanceamento de carga entre as UCPs disponveis e tambm procuram destinar processamentosdiferenciadosparaUCPsespecializadasparaamanipulodestes. A Tabela2resumeasvantagensdosSDs. As vantagens apresentadas convertemse em significativa econmia proporcionada pelosSDs.Estaeconmia,defato,ograndemotivadorparaaadooemmassado paradigmadecomputaodistribuda.

Tabela2VantagensdosSDs
Item Compartilhamentodedados Compartilhamentodedispositivos Comunicao Flexibilidade Descrio Permitevriosacessosaumabasededadoscomum Permite muitos usurios compartilharem perifricos caros, como impressoras lasercoloridas Tornamaisfcilacomunicaoentrepessoas,porexemplo,atravsdeemail. Divideacargadeprocessamentoentreasmquinasdisponveisdeacordocom ocustomaisvivel

2.3.2Desvantagens
AgrandedesvantagemapontadanaadoodeSDsafaltadeprogramasadeqadosas necessidadesdestesambientes.Estadesvantagemmaterializasedediversasformasno SD, sendo que problemas decorrentes desta desvantagem podem anular as demais vantagensjapontadas.Paratornarclaraaltimaproposio,imagineseumalojana qualtodovendedoracesseumanicabasecomdadosdeestoquedemercadoria.Caso noexistaumprogramacapazdesincronizarasvisualizaesdosvendedores,umavez que qualquer um deles pode promover uma alterao na base, poder ocorrer um indesejvelimpasse. Oqueimpediriaqueumvendedorvendessemaisprodutosdos queosdisponveis,umavezqueumoutrovendedorpoderiatercomercializadoalguns destesmesmositens,semqueoprimeirosoubesse?Asmesmasconsideraes,relativas aimpasseseinconsistncias,poderiamserfeitascomrelaoaocompartilhamentode perifricos e demais recursos. Grande parte da impropriedade dos programas em funcionarcomosSDsdseporqueelesnoconseguemmanteraconsistnciadeestado ou tratar situaes onde exista concorrncia pelo recurso. (TANENBAUM, 1995; SILBERSCHATZet.al.,2000) MesmoexistindoalgunsprogramasadaptadosatrabalharemSDs,estescostumamser

10

complexosdemais,transferindooproblemadainadequaoaosadministradoresque precisamconfigurlos.Pelasdificuldadesexpostasquepesquisadoresempenhama seemtornaracomputaodistribudaumarealidadetoacessvelquantoosprprios microcomputadores se tornaram mas, o problema com software no pode ser subestimado.(TANENBAUM,1995) OutradesvantagemencontradanosSDsasuadependnciadomeiodetransporte,da rede.Problemascomoodeperdasdemensagens,oudedeterioraodedesempenhoda rede, podem comprometer o sucesso de um SD. Felizmente ambos problemas so passveisdetratamento. Oproblemacomperdademensagenspodesercontornadocomaadoodeprogramas que gerenciem o trfego destas mensagens, evitando e tratando perdas. (TANENBAUM,1995) ParaoscasosemqueoSDafetadopeladeterioraododesempenhoderede,aadio de uma nova rede, com o intuito de fazerse um rebalanceamento de carga, pode mostrasesatisfatria. Os Casos mais severos de sobrecarga da rede, com queda brusca do desempenho, requeremumamudanadeparadigma.Estamudana,amaiorpartedasvezes,mostra semuitodispendiosa.Emalgunscasoselaenvolveatrocadosmeiosfsicos,incluindo placasderede,roteadores,switches,etc.Foraocustodesubstituiodecomponentes fsicos, outros so esperados pela contratao de pessoal especializado para configurao de novos programas. Todos os fatores referentes a rede devem ser cuidadosamentepensados,poisaineficinciadestapodenegarmuitasdasvantagens inicialmentepropostaspelosSDs.(TANENBAUM,1995)

11

Uma ltima desvantagem a ser considerada na adoo de SDs a manuteno da segurana. Esta desvantagem advm, diretamente, do fato da informao estar compartilhada, portanto, disponvel de tal forma que no estaria em um ambiente centralizado. A segurana fsica que era suficiente, a maioria das vezes, para os ambientescentralizadospassouatotalineficinciaquandonosSDs.OsSDspressupe querecursospossamseracessadosremotamente,portanto,requerendoummodelode seguranalgicaeficienteeglobal. Atabela3relacionaasprincipaisdesvantagensdosSDs.
Tabela3DesvantagensdosSDs
Item Software Rede Segurana Descrio PoucossoossoftwaresprpriosparaSistemasDistribudos Aredepodesaturarseouserprotagonistadeoutrosproblemas Oacessofacilitadotambmaplicveladadosconfidenciais

2.4ProgramasparaSDs
OsprogramasadaptadosaosSDsutilizadosatualmentemuitosebasearamemtcnicas utilizadaspordiferentestiposdesistemasoperacionais.Porestemotivoimportanteo estudodosaspectos destes sistemas quefundamentaramastcnicas empregadas em programasdistribudoscontemporneos. ParaoestudoefetuadonestetrabalhoserutilizadaadivisopropostaporTanenbaum (1995),quedividiuossistemasoperacionaiseohardware(quenoobjetodiretodeste estudo)emdoistipos:osfracamenteacopladoseosfortementeacoplados. Aclassificaodesoftwareehardwarequantoaoacoplamentoimplica,quantomaioro seuvalor,emmaiorinterdependnciaentreoscomponentesenvolvidos.Destaforma,

12

software e hardware fracamente acoplado permitem que usurios mantenhamse, razoavelmente,independentes,amedidaemqueumcertograudeinterao,desejvel, preservado. Mesmo sendo este tpico sobre programas, a idia de analisarse a associao do sistemaoperacionalcomhardwaremuitobemvinda,umavezqueestarelaofaz partedasdiretivasdeprojetodebonsSDs. Trstiposdesistemas,comcaractersticasbempeculiares,devemserestudadosparao entendimento da proposta distribuda, so eles: Sistemas Operacionais de Rede, SistemasdeCompartilhamentodeTempoMultiprocessadoeSistemasVerdadeiramente Distribudos.(TANENBAUM,1995)

2.4.1SistemasOperacionaisdeRede
OsSistemasOperacionaisdeRedecaracterizamsepelofracoacoplamentodesoftware e fracoacoplamento de hardware. Esta configurao esta bastante presente nas organizaes. Basicamente caracterizada por estaes e servidores, cada qual possuindoseuprpriosistemaoperacional,sendoqueestesltimosnoprecisamserem iguais.Orequisitomnimoparaqueoobjetivodossistemasoperacionaisderedeseja alcanadoqueexistaumaconcordnciaquantoaoformatoesignificadodealgumas mensagensparaqueelaspossamsertrocadas.Assim,SistemasOperacionaisdeRede so aqueles que permitem que mquinas interajam entre si, com um alto grau de autonomiaepoucasrestriesquantoautilizaodeoutrosprogramas.Onmerode serviosdistribudosoferecidoporestessistemasumtantorestrito,umavezqueeles foramaprimeiratentativadeinterligarmquinascomcapacidadedeprocessamento. (TANENBAUM,1995) 13

2.4.2SistemasdeCompartilhamentodeTempoMultiprocessados
OssistemasconhecidosporSistemasdeCompartilhamentodeTempoMultiprocessados so responsveis por importantes conhecimentos relacionados ao processamento distribudo.AconfiguraotpicadestessistemasadevriasUCPshospedadasem ummesmobarramento,operadasporumsistemadecompartilhamentodetempoUnix. Esta configurao faz com que os Sistemas de Compartilhamento de Tempo Multiprocessados tenham software justamenteacoplado rodando sobre hardware justamenteacoplado. A principal vantagem advinda do justoacoplamento que o poderdeprocessamentoalcanadocostumaserbemprximoaodosomatriodasUCPs envolvidas.(TANENBAUM,1995) A principal caracterstica da classe de Sistema de Compartilhamento de Tempo Multiprocessadoapresenadeumanicafiladeexecuo:umalistadetodosos processosnosistemaqueestologicamentedesbloqueadoseprontospararodar.Esta listaapresentasecomoumaestruturadedadosnamemriacompartilhadaportodasas UCPs. Paragerenciaroacessoaregiescrticasdememria,frequentemente,dedicaseum dos processadores do conjunto a executar, exclusivamente, o sistema operacional. (TANENBAUM,1995) Outra caracteristica peculiar destes sistemas que seu sistema de arquivos normalmenteincluiumnicocachedeblocounificado. Osrecursosenvolvidosna soluomultiprocessada:filasdeexecuoecachedeblocosssofuncionaisseo intervalo de acesso a eles pelas UCPs for muito baixo. No atual estado da arte, dependerdainfraestruturaderedeparaconduzirrequisiesaestesrecursosinvivel.

14

(TANENBAUM,1995)

2.4.3SistemasVerdadeiramenteDistribudos
Tanenbaum(1995)conceituaosSistemasOperacionaisVerdadeiramenteDistribudos comoumprximopassoevolutivoparasistemasdecomputadores.Ascaractersticas que definem este ambiente so a de que ele funciona sobre software justamente acoplado e hardware fracamenteacoplado. O objetivo maior para estes sistemas parecer ao usurio como um sistema nico de compartilhamento de tempo, independentedeoutrasmquinasestaremenvolvidasemumdadomomento. Alguns autores chamam esta propriedade de imagem de sistemanico, enquanto outros preferemdizlacomoumacoleodecomputadoresinterconectadosemredequeagem comoumprocessadorvirtualnico. OsSistemasVerdadeiramenteDistribudossosustentadosporumrgidoesquemade comunicao interprocessos. Este mecanismo age da mesma forma em mquinas diferentesetambmdamesmaformaquandoutilizadolocalouremotamente.Umavez queasoperaesenvolvendoprocessossobemdefinidas,porexemplo:criar,destruir, iniciar e parar no admissvel que cada mquina trate destas operaes particularmente. Desta forma, mais do que esperar que as mquinas troquem mensagenscomsuasintenes,queelasasfaamobedecendoaumprotocolonicona redeecomfunesadequadasaoambientedistribudo.(TANENBAUM,1995) Comofocoemumainterfaceconsistentecomousurio,bonsSistemasOperacionais Verdadeiramente Distribudos procuram tratar seus sistemas de arquivos uniformemente.Noimportaemqualquerlugardaredeelesestejam.Istoparaqueno ocorram transtornos como o de diferentes restries para tamanho de nomes de 15

arquivos,diferentescaracteresseparadoresdediretrios,etcquepodemcomprometer aimagemdesistemanico.(TANENBAUM,1995) Tanto para o sistema de arquivos quanto para os processos envolvidos, fazse necessrio, tambm, um esquema de segurana eficente. Conforme descrito, os SistemasOperacionaisVerdadeiramenteDistribudosprocuramdisporaousurioum recursoremotocomoseesteestivesselocalizadonaestaodesteusurio. Assim,a idiadeseguranafsicadeacessoaocomputadorquearmazenaosdadoseprocessosj nosuficiente,porissoumesquemadeproteoglobal,paraosistemadearquivose processos,providopelosSistemasOperacionaisVerdadeiramenteDistribudospara contornarestesproblemas.(TANENBAUM,1995) Uma ltima considerao de que os Sistemas Operacionais Verdadeiramente Distribudos preservam a autonomia das estaes para executar certas atividades. Paginao, swap,oagendamentodemltiplos processos,etcsogerenciadospela UCPdaqualfazemparte.Emcontrapartida,semprequehouvernecessidadedeeleger seumlocalparaexecutarumprocesso,havercooperaoentreasUCPsenvolvidas paradefiniodeondeecomoencaminhartalexecuo.(TANENBAUM,1995) A tabela 4 relaciona as configuraes propostas sob alguns dos aspectos mais importantes.

Tabela4Classificaogeraldossistemas

16

Item Apresentasecomoumnicoprocessador virtual? necessrioquetodosrodemummesmo sistemaoperacional? Quantascpiasdosistemaoperacional existem? Comoacomunicaoimplementada? necessriaaconformidadecomprotocolos derede? Hapenasumanicafiladeexecuo? Compartilhamentodearquivostem semnticabemdefinida?

Sistema OperacionaldeRede no no N Arquivoscompartilhados sim no Geralmenteno

Sistema Verdadeiramente Distribudo sim sim N Mensagens sim no sim

Sistemade Compartilhamentode TempoMultiprocessado sim sim 1 Memriacompartilhada no sim sim

2.5DiretrizesdeprojetodosSDs
Em qualquer campo do conhecimento so estabelecidos princpios que devem ser observados,duranteoprojeto, paragarantirquedeterminado produto enquadresea umadadanecessidade.AssimtambmacontececomosSDs. As questes de projeto podem ser vista com radicalidade. Muitas delas possuem interdependnciae,paraqueumresultadosatisfatriosejaalcanado,necessriousar de parcimnia. A seguir esto relacionadas as diretrizes para o projeto de SDs, respeitadosuaordemdeprecedncia.

2.5.1Transparncia
A tarefa de ocultar do usurio a complexidade envolvida na soluo, dandolhe a impressodeumsistemanico,baseadonocompartilhamentodetempo,conhecido porprincipiodetransparncia. 17

Tanenbaum(1995)relacionaduasmaneirasdealcanarseatransparncia.Aprimeira, emaisfcil,aplicaratransparnciaanveldeusurios.Asegundatentarescondera distribuiodoprogramadoratravsdeumainterface,baseadaemchamadasdesistema, queencapsuleaexistnciadeoutrosprocessadores. Emqualquerdasduasformasvistasanteriormente,atransparnciapodeserestudada sobre diferentes aspectos. De fato, um sistema distribudo pode evidenciar sua existnciadediversasmaneirase,paratodaselas,deveserbuscadaumainterfaceque proteja o usurio da complexidade envolvida. Portanto, os SDs devem prover tranparnciaparaosseguintesaspectos:

Migrao:osrecursosdevempossuirliberdadedealteraremsualocalizao semquetenhamsuasrefernciasalteradas.Quandoumarquivoformigradode um servidor para outro o usurio no deve ter dificuldades em acesslo, devendofazlodamesmaformaquefaziaantesdamigrao.Casoeletenha deespecificaronovoservidorquehospedaoarquivoparapoderutilizareste, nofoialcanadaatransparnciamigrao.(TANENBAUM,1995)

Replicao: no cabe aos usurios saberem quantas cpias existem de determinadorecurso,comoeseelasestosincronizadas.Areplicaouma estratgiaqueconfere aoSDmaior disponibilidade, sendomuito desejvel. Almdadisponibilidade,elapodeaumentarodesempenhoglobaldosistema, porexemplo,disponibilizandoumarplicadorecursoalvoprximaaousurio, sem que a utilizao do recurso cause grande trfego de rede. (SIBERSCHATZ;GALVIN;GAGNE,2000).

Concorrncia:aexistnciadevriosusuriosutilizandoummesmorecurso deveficaroculta para cada um deles. O SD devergarantir este nvel de 18

transparncia zelando para que o estado de um recurso no se torne inconsistente2. Ele tambm dever cuidar para que um usurio no fique demasiadamenteimpedidodetrabalhar,casohajaumoutrousurioutilizando sedorecursoprimeiramente.(TANENBAUM,1995)

Paralelismo:onmerodeUCPsenvolvidasnaexecuodeumatarefano deveserpercebidopelousurio.Umerronaexecuodeumafraodetarefa, quetenhaocorridoemumadeterminadaUCP,deversertratadoparaqueno comprometaaexecuodatarefa,mantendoousuriolivredestapreocupao.

2.5.2Flexibilidade
A diretriz flexibilidade desejvel a medida que novos recursos, ou reedies de recursosantigos,possamserincorporadasasoluocomoumtodo.Oatualestadoda arteapontaaadoodemicrokernelscomomelhorpropostaparaconferirflexibilidade aossistemas. Estaabordagem,diferentedasuapredecesora,ade kernel monoltico, resumeseaprover,basicamente,quatroservios:ummecanismodecomunicaointer processo, algum gerenciamento de memria, um pouco de gerenciamento e agendamentodeprocessosdebaixonveleentradaesadaabaixonvel. Osdemais servios, costumeiramente encontrados nos kernels monolticos, so, geralmente, implementadosanveldeserviosaousuriofinal.Afigura1ilustraasduasopesde implementaoparakernels:

Ainconsistncia,estadoemqueainformaoobtidadeumrecursonoconfivel,consideradamuitasvezes maisperigosadoqueaprpriaindisponibilidade. Estudossobreainconsistnciapodemserencontradosna literaturadesistemasoperacionais(ebancodedados.

19

Usurio
Kernel monoltico

Usurio
Microkernel

Servidor de Arquivos Microkernel

Servidor de Diretrio
Microkernel

Servidor de Processos
Microkernel

Inclui gerenciamento de arquivos, diretrio e processos

rede

(a)

(b)

Figura1Esquemadekernelmonolticoemicrokernel(TANENBAUM,1995)

O fato de servios, como o gerenciamento de sistemas de arquivo, por exemplo, rodaremsobreumkernelenocomopartedele,confereaoSDflexibilidade.Deoutra forma,quandoosserviosestoembutidosnokernel,comonaabordagemmonoltica, possveisalteraes,quesefizessemnecessriasnosistemadearquivos,porexemplo, aolongodotempo,poderiamimplicaremsriasalteraesemoutraspartesdokernel. Destacamsecomobenefciosadvindosdaflexibilidadeafacilidadededepuraodos compontenteeamaiordisponibilidadedoSD. Noprimeirocaso,temos queoSD flexvelcompostoporporesmenoresemelhordefinidasdesoftware,quesomais fceisdeseremtestadas,tornandomaisprodutivootrabalhodedesenvolvimentopara estessistemas.Quantoaoincrementonadisponibilidade,aflexibilidadealcanadacom microkernels podeevitarqueosistematenhadeserreiniciadoquandodainterveno emalgumdosseuscomponentes.Mesmoparecendopequenootemponecessriopara umreinciodesistemaelepodeimplicaremgrandesprejuzos,quandoporexemplo, tratarse de um sistema de comrcio eletrnico a ser reiniciado no auge das suas transaes.

20

2.5.3Confiabilidade
Ofatodepodercontarcomumdeterminadorecursoportodotempo,ouporboaparte dele, confere a este recurso o quesito confiabilidade. A maneira mais cmoda de alcanar a confiabilidade atravs da redundncia de recursos. A redundncia de recursos proporciona disponibilidade e esta relacionase diretamente com a confiabilidade.(TANENBAUM,1995;SILBERSCHATZet.al.,2000). Matematicamentedefinimosadisponibilidadedaseguinteforma: SeconsiderarmosP(r)aprobabilidadedeumainstnciadorecursorestar indisponivel,temosqueotempototaldedisponibilidadedorecurso,Dtotal(r), serdadoemfunodeumaconexolgicaOUentreasprobabilidades paracadainstnciadasQ(r)existentes.Verequao1.

Dtotal(r)=1P(r)Q(r)
Equao1DisponibilidadeparaQ(r)recursos

Oincrementonadisponibilidadeproporcionadopelaredundnciapodeserverificado comoexemplodemonstradonafigura2.

21

suporocasodeumdadorecursopossuirtrsinstnciassendequeofator defalhadecadainstnciade0,006. Q(r)=3 P(r)=0,006 Dtotal(r)=2,16x107

Figura2Disponibilidadeemfunodonmeroderplicas

Constataseapartirdoexemplodafigura2que,paraocasodeumanicainstnciado recurso r,acada1000hdedisponibilidade esperase6hdeinterrupo. Quando o nmero de instncias do recurso aumenta para 3, verificase que o tempo de indiponibilidade doconjunto caipara2,16x107. Estevalorequivaleadizerque, aproximadamente,acada528anosoconjuntoficarindisponvelpelotempode1h3. Contudo,osnmerossugeridospeloexemplodadonodevemserinterpretadoscom extremismos. Umgrandenmerodecpiasdeumrecursotornadifcilatarefade mantlas,todas,utilizveis.Osprincipaisproblemasenvolvidossoamanutenoda consistnciaedasegurana. Quantomais frequentesforemasatualizaes parao recursomaiorserachancedehaverumacpiainconsistente,ouseja,divergindoda instnciaatualizada. Jasegurana,paraocasodevriascpiasdeveserreforada, poisquequalquerumadelasestiverdesprotegida,todasasoutrasestaroameaadas. Arecomendaofinal,paraqueosistemagozedeconfiabilidade,queelenoesteja funcionandoemregimedeestressequandoemcondiesnormais. Istoparaqueno casodeumafalhainesperadahajafolgaosuficienteparaabsorodacargadon,ou nsemcolapso,atqueoregimedecontingnciarestabeleaacondiopadrode funcionamento.

Isto se considerarse que ao longo deste tempo a fator de indisponibilidade individual no varie, o que improvvel.

22

2.5.4Desempenho
O desempenhoumacaractersticaperseguidaportodasasreasdoconhecimento. Ponderadasasdemaiscaractersticasvistasataqui,odesempenhotambmalmejado pelosSDs.ApesardenosertofcilaferirodesempenhodeSDs,algumasmtricas comootempoderesposta,avazo,autilizaodesistemaeaquantidadedecapacidade deredeconsumidapodemserutilizadas.Contudo,mesmocomastcnicasapontadas, asanlisesnemsempretemresultadosmuitoconclusivos.Istoporqueocorremcasos tendenciosos, onde o ambiente estudado particular demais para concluses gerais sobre a soluo. Tanenbaum (1995) exemplifica a dificuldade em avaliar casos particularescomparandoocasoemqueumproblemacomputacionalexecutadopor vriasUCPs,trabalhandoparalelamenteeocasodavarreduradeumgrandearquivo, por uma UCP, a procura de um determinado padro. Se para o primeiro caso o desempenhodeveestarrelacionadoaopoderdeprocessamentodasUCPsenvolvidas, nosegundocasoeledeveestarvinculadoavazodeentradaesadadedispositivosde memria,oudaprpriarede,dependendodeondeoarquivoestarmazenado.Assim sendo,verificasequeestastarefas,assimcomooutras,sodistintasosuficientepara queestabeleamosumparaleloentreseusosdesempenhos. Asponderaesacercadoquesitodesempenho,paraosSDs,freqentementerecaem sobre o alto custo envolvido no trfego de mensagens pela topologia de rede e a necessidadedetrocarmensagensparaenvolvermaisnsnaexecuodeproblemas. Estas ponderaessomaterializadas emalgoritmos capazes deavaliaremamelhor estratgiaparaexecuodeumdadoproblemaemfunodanaturezaedotamanho deste. A partir destes critrios, os algoritmos devem apontar para uma execuo distribuda ou local. Quando a escolha recair sobre a primeira opo, caber ao

23

algoritimodeterminarquantosnsestaroenvolvidosnoprocessamento.

2.5.5Escalabilidade
Porltimo,desejvelqueoSDpossaincorporarnovosns,amedidadonecessrio, sem requerer grande esforo. Este atributo, chamado escalabilidade, permite que projetosadequemseaexplosesdedemandaqueimpliquemnaabsorodeinmeros novosnsnosistema. Ofatodaescalabilidadeestarrelacionadaporltimonalistadeprioridadesnodeveser interpretado como se elefosse uma caracterstica de pouca importncia. Casoseja relegadaadevidaatenoaestadiretriz,problemasoriundosdeumafalsaprevisoou umaexplosodedemandapodemlevaroSDaumaaposentadoriaprecoce.Devidoaos altoscustosenvolvidosemadaptaraspressasumambiente,ounopiorcaso,substitu lo,recomendaseprimarporsistemasfacilmenteescalveis.

24

2.6Concluso
EstudosconsistenteseaprofundadosarespeitodoprojetodeSDssoantigos. Eles remontam desde que a interconexo de computadores se tornou realidade. A interdiciplinariedadeenvolvida,indodaconstruodesoftwares,doconhecimentode hardwareederedesconstituiumdesafioparapesquisadoresnomundotodo.Muitas vezesavanosmaissignificativossolimitadospeloestadodaartedeumadestastrs reas,maisfrequentemente,daconstruodesoftwares. De fato, no faz muito tempo que os SDs, que contemplam satisfatoriamente as diretrizes de projeto estudadas, surgiram. Mesmo assim, o entusiasmo de diversos ramosdenegcio,almdodapesquisaacadmica,vemacelerandomuitooseuavano. Assoluesexistentesatualmentespossuemumforteapeloeconmicoetemfeitoque empresasasadotem.Assim,anecessidadededistribuiotornouse,hoje,irrevogvel. Contudo, se outrora o foco da distribuio esteve sobre os sistemas operacionais, atualmenteelefoimudadoparaosmiddlewares. Os middlewares so programas que propese a intermediar transaes, conforme sugereadecomposiodonomeemingls: middle= meio/intermedirio + ware = artigo/produto. Eles funcionam em uma camada acima dos sistemas operacionais, ensejandoaflexibilidade,talcomoquandodaescolhadosmicrokernelsemdetrimento doskernelsmonolticos. Vrias empresas apostaram em construir middlewares para suportar ambientes distribudos.AsmaisnotveissooDistributedComponentObjectModel(DCOM),da Microsoft4, o Distributed Computing Environment (DCE), da Open Software

Maioresinformaesem(SEI,2001).

25

Foundation5 e o Java/Remote Method Invocation (Java/RMI), da Sun6. Uma outra alternativa a estes middlewares tem conquistado bastante espao, a Comon Object Request Broker Architeture (CORBA), do Object Management Group (OMG). O prximo captulo trata de middlewares e mais especificamente da especificao CORBA,cujopadroconfundesebastantecomaprpriadefiniodemiddleware.

5 6

Maioresinformaesem(CA;TRW,1997c;DCEDOCUMENTATION). Maioresinformaesem(WALDO;WOLLRATH)

26

CaptuloIII
3AespecificaoCORBAenquantomiddleware
3.1Definindomiddlewares
Na dcada de 90 foi desenvolvida uma tecnologia cujo intuito era o de prover interoperabilidade paradarsuporta amigrao queocorria de aplicaes de grande porte para aplicaes cliente/servidor. Esta tecnologia passou a ser conhecida por middleware e foi definida assim por Eckerson (1995 apud BRAY, 1997, traduo nossa):
Middlewareumsoftwaredeconectividadequeconsistedeumconjuntode servios que permitem mltiplos processos rodando em uma ou mais mquinasinteragiratravsdeumarede. Middlewareessecialparamigrar aplicaes de mainframes para aplicaes cliente/servidor e para prover comunicaoatravsdeplataformasheterogneas.

Destaforma,os middlewares configuramsecomoAPIs7 queagementreossistemas operacionaiseasredes,deformaapermitirqueaplicaessejamcapazesde:

7

localizaroutrosserviosouaplicaes,transparentemente,atravsdarede; seremindependentesdosserviosderede; seremconfiveisedisponveis; serem escalveis sem perderem funo (SCHREIBER, 1995 apud BRAY,

API(ApplicationProgramInterface)umconjuntonormalizadoderotinasechamadasdesoftwarequepodem serreferenciadasporumprogramaaplicativoparaacessarserviosessenciaisdeumadadodomniodeaplicao.

27

1997) Porestascaracteristicas,senoprimeiromomentoos middlewares surgiramcomoum ferramentalparaodownsizing8,antesmesmodestamigraotersidoconcludaelesj ocupavamumimportanteespaonocenriotecnolgico.SchimidteVinoski(2004,p. 5) ressaltam que a maturidade dos middlewares permitiu aos desenvolvedores concentrarem seus esforos na programao de funcionalidades especficas das aplicaes,nolugardesepreocuparemcomcomplexidadesinerentesdainfraestrutura distribuda. Osautoresatribuemestaconquistaaodesacoplamento,dalgicaedas funcionalidades especficas da aplicao, das complexidades de infraestrutura mencionadas. Foiporestesmotivosquegrandesempresaseconsrciosinvestiram seusesforosparaconstruodemiddlewares,ouespecificaesdestes.Dasiniciativas maispopularesressaltamadaOpenSoftwareFoundation,comoDCE,adaMicrosoft comoDCOM,adaSuncomoJava/RMIeadaOMGcomaCORBA. As implementaes destes middlewares foramrealizadas utilizando diferentes meios tecnolgicos,sendoestesosprincipais: Monitores de Processamento Transacional que provm ferramentas e um ambienteparadesenvolvimentoedistribuiodeaplicaesdistribudas9; RemoteProcedureCall (RPC),quetornadisponvel algica paraqueuma aplicaosejadistribudaatravsdarede.Assim,algicadeprogramaemum sistema remoto passaaestaracessvel comoseemumachamadaderotina

Termo consagrado em ingls que referese a migrao de aplicaes de grande porte para arquitetura cliente/servidor. Maioresinformaesem(GTE,1997)

28

local10.

MessageOriented Middleware (MOM), que prove o intercmbio de dados

programaprograma,tornandopossvelacriaodeaplicaesdistribudas. MOManlogoacorrespondnciaeletrnica,nosentidoqueassncronoe requererumrecipienteapropriadoparaasmensagens,capazdeinterpretaro significadodelasetomaraaoapropriada11. ObjectRequestBroker(ORB),quetornapossvelaosobjetosquecompeuma aplicaoseremdistribudosecompartilhadosatravsderedesheterogneas. Contudo,seaadoodosmiddlewaresmotivadaporvriasvantagenstrazidas,muitas vezeselaescondeperigosasvariveis.Aprincipaldelasadequeaadoodealguns middlewares tornam as aplicaes interoperveis entre si mas, por outro lado, dependentesdaimplementaoproprietriado middleware utilizado. Outravarivel muitas vezes nolevada em conta a danecessidade desecustomizar um grande nmerodeservios.Algumasvezesestadificuldadeconfigurasecomoumabarreiraao administradormenosfamiliarizado,incapazdedefinirumconjuntoestreitodeservios quesatisfaamanecessidadedoseuambiente.Altimavarivelaserconsideradaa de que o middleware aumenta o nvel de abstrao da programao de aplicaes distribudasmas,deixatambmoprogramadorcomescolhasdifceisaseremfeitas, como por exemplo, que funcionalidades dispor dos lados cliente e servidor. (BERNSTEIN,1996apudBRAY,1997) Paracontornarasdificuldadesinerentesautilizaodosmiddlewareseusufruirdesuas benesses,osadministradores tmdecompreendercomplentamenteosdoisextremos
10 Maioresinformaesem(CA;TRW,1997b) 11 Maioresinformaesem(CA;TRW,1997a)

29

envolvidos:oproblemadaaplicaoeosserviosdomiddlewarequetornampossveis adistribuiodaaplicao.Ento,paradefinirquaisostiposdeserviosnecessrios,o administradordeverdefinirquaisfuncionalidadesserorequeridas,quepodemestar nasseguintesclasses: 1. Serviosdesistemadistribudo,queincluemcomunicaescrticas,programa aprograma e servios de gerenciamento de dados. Este tipo de servios incluemRPCs,MOMseORBs; 2. Servios quedoacesso aos servios distribudos e a rede subjacente. Os monitoresdetransaosoincludosnestetipodeservio. 3. Servios degerenciamento demiddlewarequehabilitam as aplicaes e as funes de sistema a serem continuamente monitoradas para assegurar o desempenhotimadoambientedistribudo.(SCHREIBER,1995apudBRAY, 1997)

3.2ACommonObjectRequestBrokerArchiteture(CORBA) 3.2.1DefinindoCORBAenquantomiddleware
CORBAumacrnimoparaCommonObjectRequestBrokerArchitecture,quenomina umprodutointelectualdesenvolvidoporumconsrciodediversasempresasdareade tecnologiaeoutrastantasgrandesempresasnacondiodeusurias.Esteconsrcio conhecido por OMG, que tambm um acrnimo que para a entidade Object ManagementGroup. A OMG um consrcio que no possui fins lucrativos, de livre associo 12 e foi
12 AssimcomoocorrecomadefiniodeSoftwareLivre,adefiniodelivreassociaolevamuitaspessoasa entendlacomogratuita. Esteentendimentonoocorreto.Emambososcasos,otermolivrereferesea

30

fundado para criar e manter especificaes para interoperabilidade em aplicaes empresariais.Atualmentesomaisde800empresasqueintegramaOMG,dentreelas grandesnomescomoIBM,Apple,Sun,DECetantosoutrosdareadetecnologiae grandesusurioscomoCiticorp,AmericanAirlines,BritishTelecomemaisoutros tantostambm.(OMG,2004a) Definidacomoprodutointelectual,aarquiteturaCORBAnoautoutilizvel.Desta forma,elaespecificaumaarquitetura, sugerindoboasprticas,restringindo outras e adotando alguns padres. O material constante na especificao CORBA serve de subsdio para que fabricantes de programas construam implementaes em conformidadecomestepadro. Umavezconstrudos middlewares emconformidade com o padro CORBA, estes devem ser capazes de intermediar requisies entre programasdepraticamentequalquerfabricante,rodandosobreumagrandegama de sistemasoperacionais,emigualmentegrandevariedadedecomputadores.(CORBA,ca. 2004) Osestudosquehojedefinemaverso3.0.3daCORBAforampublicadospelaprimeira vezem1991naverso1.1.Entretanto,foiscomaverso2.0,publicadaemmeados de 1995, com o protocolo IIOP, Internet InterOrb Protocoll, que a promessa de conectividadefoicumprida.Atestaatualizao,apenasacomunicaoentreobjetos deummesmofornecedorerapossvelnocontextodedistribuio. Acapacidadede integrar objetos de diferentes fornecedures, conseguida a partir da verso 2.0, foi bastantesalutarparaosucessodaespecifiao.EstefeitotrouxeapropostadaCORBA deencontrocomapropostadeummiddlewareideal,eacolocouemdestaqueentreos

inexistnciadediscriminao. InexistnciadeDiscriminao,paraoprimeirocaso,comrelaoaoacessoa cdigosfontesenosegundo,comrelaoaquempodeassociarseaentidade.

31

middlewaresexistentes.(VINOSK,1997)

3.2.2AarquiteturaCORBAnoObjectManagementArchiteture(OMA)
AespecificaoCORBAapenaspartedeumapropostaaindamaior,aOMA.Dentre oscomponentesdaOMA,aCORBApossuiimportantepapel. Nelaestadefinidoo Object Request Broker (ORB), responsvel pela comunicao entre os demais componentes.AinterrelaodoselementosdaOMAmostradanafigura2.

Interfacesde Aplicao

InterfacesdeDomnio

FacilidadesComuns

ORB ObjectRequestBroker

Serviosdeobjetos
Figura3EsquemadaOMA

Vinoski(1997)descreveassimoscomponentesdaarquitetura: Ncleo CORBA/ORB O Object Request Broker (ORB) o componente responsvel,principalmente,pelafacilidadeentreacomunicaoentreclientes eobjetos;

32

ServiosdeObjetosointerfacesindependentesdedomnio13,conhecidadas por facilidades horizontais, que so usadas por muitos programas objeto distribudos.Exemplosdeobjetosqueexercemestepapelso:

O servio de nomeao: que permite aos clientes encontrarem objetos baseadosnosnomesdeles14; O servio de negociao: que permite aos clientes encontrarem objetos baseadosnassuaspropriedades; Outrosserviosdeobjetosoosrelacionadosaogerenciamentodociclode vida,segurana,transaes,notificaodeeventos,entretantos.

Facilidades Comuns so tambm facilidades horizontais, assim como os serviosdeobjeto,ouseja,nosoconcebidasparadomniosdeterminados. Noentanto, aocontrrio dos servios deobjeto, as facilidades comuns so concebidasparautilizaoemaplicaesparaousuriofinal.O Distributed DocumentComponentFacility(DDCF),umfacilitadorbaseadonoOpenDoc15 umbomexemplo defacilitador comum. Elepermiteaapresentaoeo intercmbio de objetos entre modelos de documentos, como uma relatrio, criadoporumeditordetextos,quepossuiumlinkparaumgrfico,criadopor umaplanilha;

Interfaces de Domnio As interfaces so facilidades, assim como as facilidades comuns e os servios de objeto, mas, que so utilizadas por domniosespecficos.Umdosprimeirosdomniosasercontempladoporuma

13 Domnioumtermoassociadoaramosdenegcio.Destaforma,podemosdizerqueumaaplicaoespecfica paraumdomnioseelaatendenecessidadesparticularesdesteramodenegcio.Exemplosdegrandesdomnios so:odetelecomunicaes,odefinancias,omdico,etc. 14 Maioresinformaesem(VINOSKI,2003). 15 OpendDocumamarcaregistradadaAppleComputer,Inc.

33

interfacededomniofoiodemanufaturas,atravsdeumaOMGRPF16. Esta RPFversavasobreProductDataManagement(PDM)Enablers17egerouuma primeirainterfaceparaodomnioindustrial.Deformasemelhanteoutrasreas de negcio como a mdica, de telecomunicaes e financeira tem suas particularidadespadronizadasnaformadeinterfacesdedomnio;

Interfaces de Aplicao: So interfaces para aplicaes especficas, casos particularesquenofazempartedeumdomniomas,simdomododenegcio deumadadaempresa. Lembrandoque aOMGnoproduzaplicaesmas, especificaes, o nvel de liberdade grande para a construo destes componentes. AOMAapenasprevaexistnciadestasinterfacesparaque estaspossaminteragircomseusdemaiscompontentes. Noentanto,quando casosdesucessoparaumadadainterfacedeaplicaoganhamstatusemum domnio,aOMGpodeinclulosemumafuturainterfaceparaestedomnio.

Apreocupaonaseparaoderesponsabilidades,quepodeserobservadanaOMAe nosdemaisprojetosdaOMG,confereextremaflexibilidadeaostrabalhospublicados. Estaflexibilidadeaproveitadapelosdiversoscomits,mantidossobacoordenaodo OMG,quevisamestabelecerpatterns18especializadoparareasdenegcioespecficas, conhecidas por domnios. Existem comits constitudos para rea mdica (CORBAmed),parareadesegurana(CORBAsec),entreoutras.

16 RPFRequestsForProposals,ouemportugus,pedidosparapropostas:DocumentonoqualaOMGsolicitaa colaboraodeseusmembroscomtecnologiaeidiasparaaconstituiodeumpadro. 17 Enabler um termo derivado dos princpios de Gerenciamento em Qualidade Total. Ele apenas define qualquercoisa,comoumprogramadecomutadorouatividadehumana,queprovousuporteumprocessode negcioabstrato. 18 Pattern(termoconsagradoemingls)=padro: Cadapadroumaregradetrspartes,queexpressauma relaoentreumcertocontexto,umproblemaeumasoluo.(Alexander,CristopherAPatternLanguage)

34

3.3 O funcionamento da CORBA

Conformevisto,entreoscomponentesdaOMAoORBdesempenhaoimportantepapel de intermediar a comunicao entre os demais componentes da arquitetura. Na CORBA, ele tambm o foco da especificao ORB mas, os outros elementos necessriosaoseufuncionamentotambmestoespecificadosnela.Arelaodetodos esteselementosaseguinte: NcleoCORBA; Linguagemdedefiniodeinterfaces(LDI);

Repositriodeinterfaces(RI);
Mapeamentosdelinguagens;

StubseSkeletons
Invocaoeencaminhamentodinmicos; Adaptadoresdeobjeto(AO); ProtocoloInterORB(PIO); Afigura3ilustraorelacionamentodestescompontentes.

35

Figura4EsquemaCORBA

ParacompreenderarelaoentreositensconstantesdaCORBApertinenteumabreve introduo a terminologia utilizada. Vinoski e Schmidt escreveram um consagrado artigo para a revista SIGS C++ Report, em outubro de 1997, entitulado Object Interconnections onde os principais termos so definidos. A estes termos foram acrescidosalgunsoutrosjulgadosigualmenteimportantesaoentendimentodoassunto. Segueesteimportanteglossrio.

ObjetoCORBA:UmaentidadevirtualcapazdeserlocalizadaporumORB edereceberrequisiesdeclientesentreguesaela.Esteobjetoidentificado, localizadoeendereadoporsuarefernciadeobjeto. Nocontextodeuma requisio de invocao, um objeto CORBA para o qual seja enviada uma requisiochamadodeobjetoalvo.(SCHIMIDT;VINOSKI,1997)

Servant(empregado):umaentidadedeumalinguagemdeprogramaoque existenocontextodeumservidoreimplementaumobjetoCORBA. Para linguagens que no so orientada a objetos, um servant consiste de um 36

conjuntodefunesquemanipulamdadosquerepresentamoestadodeum objetoCORBA(e.g.umainstnciadeumregistroouestrutura).(SHIMIDTe VINOSKI,1997) ArelaoentreoobjetoCORBAeoseuservantcorrespondentedeextrema importncia.UmobjetoCORBAconsideradovirtualpornoexistirporsi s.Oprocessamentodasrequisiesdefatoexecutadopeloservant,ficando o primeiro com a tarefa de intermediar a negociao entre o segundo e o cliente.(SHIMIDTeVINOSKI,1997) UmfatoaserconsideradoqueumobjetoCORBAcomumentetemumestado definido, podendo este estado ser serializado19 e mantido em um banco de dados. Por outro lado, um servant, no necessariamente compreende um estado.Istofcilmenteperceptvelseconsiderarmosqueosservantspodem ser bibliotecas de funes, oriundas de linguagens no orientadasobjeto. Assim,sapartefuncionalestariadefinidanoprprioservantnohavendoum estadoaserarmazenado.(SHIMIDTeVINOSKI,1997)

ID de objeto: Um identificador definido pelo usurio ou pelo sistema que nomeiaumobjetodentrodoescopodoAOdele. Portanto,osIDsdeobjeto nosoglobalmentenicos.Arestrioexistentedequeelesejanicopara oOAondeelecriadoouregistrado.(SHIMIDTeVINOSKI,1997)

Ativao: o ato de iniciar um objeto CORBA, permitindo a ele receber requisies. UmavezqueaativaotornaoobjetoCORBAaptoareceber requisiesdeclientes,umaprviaassociaocomoservantespecficojdeve tersido definida. Valelembrarqueaativaodeum objeto CORBA no implicanasuacriao.Assim,umobjetoCORBAspoderserativadosesua

19 Serializado=termoutilizadoparaindicarqueoestadodeumobjetopersistido.

37

criaotiverocorridoanteriormenteaesteintento.Contudo,aativaodeum objetoCORBApodeimplicarnacriaodeum servant,seistosemostrar necessrio.

Desativao:oopostodaativao,ouseja,apartirdestemomentooobjeto CORBA no poder mais receber requisies. A quebra do vnculo entre objetoCORBAeseurespectivo(s) servant(s) condioindispensvelpara desativao do primeiro. De forma anloga ao que acontece quando da ativao, adesativaodestruiroobjetoCORBA,quepoderserreativado futuramente para receber novas requisies. Ainda de forma anloga, o servant envolvido poder ser destrudo se nenhum outro objeto CORBA referirseaele.Istoporqueumservantpodeserreferenciadopormaisdeum objeto CORBA, da mesma forma que um objeto CORBA pode referenciar maisdeumservant.

Encarnao: Uma vez que consideramos o objeto CORBA virtual, a encarnaoseriaoatodaassociaodelecomumservantcapazdematerializar asaescompromissadasporsuainterface.

Eterializao:Oopostodaencarnao,ouseja,aquebradovnculoentreo objetoCORBAeseu(s)servant(s).

Mapadeativaodeobjeto:Umatabelamantidaporumadaptadordeobjetos quemapeiaobjetosCORBAativosaosseusrespectivos servants. Vinoskie Shimidt (1997) destacam que a denominao objeto ativo muitas vezes imprpria,umavezqueos servants noprecisamimplementaro pattern de objetosativos. Istopodetornaracompreensomaisdifcilaosiniciantesna tecnologia.

38

3.3.1OncleoORB
UmORBumatecnologiademiddlewarequegerenciaacomunicaoeointercmbio dedadosentreobjetos. OORBtornapossvelqueusuriosmontemsuasaplicaes associandoobjetos,quepodemserdediferentesfabricantes,estaremhospedadosem diferentessistemasoperacionaisediferentesarquiteturasdehardware.Dissociandodas aplicaesosdetalhesdoambiente,oORBtornamaisfcilaconstruoemanuteno delas. Despreocupado dos detalhes relativos ao ambiente, ocultados pelo ORB, programadorespodemdirecionarseusesforosparatornaremasaplicaesmelhores. (VINOSKI,1997;FOREMAN;WALLNAU,1997) As informaes so portanto ocultadas para que se alcance a transparncia, diretriz chaveparaprojetosdistribudos.Sovriososnveisdetransparnciabuscados.Cada umdeleseatingidoocultandoseasseguintesinformaes(VINOSKI,1997): Localizaodoobjeto: nodeveimportaraoclienteseoobjetoalvodesua requisio esta na sua prpria mquina, dentro do mesmo processo ou em diferentesprocessos,emoutraestaodaredelocal,ouaindadistribudoem algumaoutraredeaoredordomundo; Implementaodoobjeto:nodeveimportaraoclientealinguagemnaqualo objeto fo implementado, nem tampouco para que sistema operacional ou arquiteturadehardwareelefoiconcebido; Estadodeexecuodoobjeto:nocabeaoclientepreocuparseseoobjetoalvo estounoprontopararecebersuasrequisies,seeleestativo.OORBdeve preparartalobjeto,quandofornecessrio,eentoentregararequisioaele; Mecanismodecomunicaodoobjeto:oclientenoprecisasaberquaismeios

39

soutilizadosparaqueosobjetoscomuniquemseentresiecomele.AoORB cabegerenciarseacomunicaosedporTCP/IP,memriacompartilhada, chamadademtodolocal,ouqualqueroutromeio. O cliente dever especificar qual o objeto alvo para sua requisio utilizando uma refernciadeobjeto. QuandoumobjetoCORBAcriado,umarefernciaparaele tambmpassaaexistir. Paraocliente,estarefernciaapontarparaomesmoobjeto todootempoqueesteobjetoexistir.Arefernciaaoobjetoopacaaousurio,ouseja, apenasoORBconheceainformaoencapsuladanela. Oclientenopodealteraro contedodestareferncia.(VINOSKI,1997) Algumasvezesoformatoderefernciaspadronizado,comonocasodoProtocolo Internet InterORB,PIIO,edo Distributed Computing Environment Common Inter ORBProtocolmas,haindaformatosproprietrios.(VINOSKI,1997) Umarefernciaparaumobjetopodeserobtidaporoutrosmeiosquenoodacriao. Estas maneiras so atravs de um servio de diretrio ou da recuperao de uma refernciaapartirdeumastring.Segueumaprofundamentosobreestesdoismtodos (VINOSKI,1997): Serviodediretrio:atravsdesteserviooclientepoderequererquelheseja devolvidaumarefernciaparaoobjetodeacordocomalgunsparmetros.Esta consulta inside em uma tabela de objetos que podem estar catalogados por nomeouporsuaspropriedades,porexemplo.Osdoisserviosquecatalogama informao por nome e por propriedades so o Naming e o Trading, respectivamente; Converso stringrefernciaerefernciastring: umaaplicaopodesolicitar

40

queoORBconvertaumarefernciadeobjetoparaumastringe,emseguida, armazenaresta string emumamdiaqualquer. Damesmaformaaaplicao podeobterastringdamdiaemqueelaforaarmazenadaesolicitarqueestaseja convertidaemreferncianovamente. Casooobjetoapontadopelareferncia aindaexista,suautilizaovaidarsenormalmente. importantelembrarqueoORBnodisponibilizaqualquermtodoparacriaode objetos. Para executar esta operao necessria a invocao de objetos fbrica (Factory).Aquestochavepassaasercomoobterarefernciaparaumobjetofbrica. ParaissooORBprovumserviopequenoesimplificadodeobtenodereferncia, umserviodeNaminge/ouTrading.FrequentementeaimplementaodoORBpossui ummtodo resolve_initial_references, querecebeumnomeeretornaa refernciaparaoobjeto solicitado. Estarefernciainicial podeserparaumobjeto fbriaouparaumserviodeNaming. Costuma identificar oserviode Naming a palavraNameService.(VINOSKI,1997) Aopopornoterummtodoquecrieobjetosfazpartedadecisodemanteroncleo ORBmnimoedividirasresponsabilidadescomoutroscomponentesdaOMA,comoos servios de objeto eos facilitadores comuns. Portanto deve caber ao ORB apenas simplificaracomunicaoeainfraestruturadeativaoparaaplicaesdistribudas. (VINOSKI,1997) OutrasempresaseconsrciosespecificamORBsalmdaOMG,comaCORBA.Das iniciativasquedespontamcomopossveisconcorrentesaomodeloOMGressaltamse (FOREMAN;WALLNAU,1997): ComponenteObjectModel(COM);daMicrosoft;

41

 Java/RMI,daSun; Atabela5mostraumacomparaoentreestasduasopeseadaOMG.

Tabela5ComparativoentreORBs(FOREMAN;WALLNAU,1997) ORB COM/ DCOM Disponibilidadede plataforma originalmentepara plataformaPC,masest sendodisponibilizadopara outrasplataformas Aplicvela Arquiteturasde sistemas distribudos baseadaemPCs Mecanismo APIsparasistema proprietrio Nde implementaes uma

CORBA

independentedeplataforma arquiteturasde ecominteroperabilidade sistemas entreplataformas distribudosem geral arquiteturade sistemas distribudosem geral,baseadasem WebeIntranets

especificaode tecnologiade distribuiode objetos

muitas

Java/RMI qualquerplataformaque suporteamquinavirtual Java

implementaode vrias tecnologiade distribuiode objetos

3.3.2Alinguagemdedefiniodeinterfaces(LDI)
A definioconstante daespecificaoem(OMG,2004a),definea OMGInterface DefinitionLanguage (LDI) como alinguagemusadaparadescreverasinterfacesque objetosclientespodemchamare,emcontrapartida,asinterfacesqueasimplementaes deobjetoprovm. AsinterfacessosimilaresasclassesC++einterfacesJava.Umexemplodedefinio

42

deinterfaceLDImostradonafigura3.Nelaencontramosumainterfacedenominada Factory quesuportaapenasomtodocreate.Estemtodonoexigeparmetrose retornaumarefernciaparaumobjetodetipo Object.Depossedeumareferncia para um objeto que implemente esta interface, um cliente pode executar o mtodo createeassimcriarumnovoobjetoCORBA.(VINOSKI,1997)

// Definio de uma interface Factory // responsvel por criar novos objetos // e devolver uma referncia para eles interface Factory{ Object create(); }; Figura5ExemplodedefinioLDI(VINOSKI,1997)

Uma definio de interface escrita em LDI define completamente a interface e as especificaes de cada parmetro envolvido na operao. Contudo no correto imaginarqueosobjetosclientessejamescritosemLDI.Sendoapenasdescritiva,esta linguagemnopossuiestruturasnecessriasaimplementao.Defato,elasspossui os devidos mapeamentos paraalguma linguagem comum, como: C++, Java, Cobol, Python,etc. importantelembrarquetaismapeamentosdarseosempredeacordo com as facilidades suportadas pela linguagem cliente. Por exemplo, o conceito de excesses,quepodesermapeadodiretamenteparaalinguagemJava,nopodeslo feitodamesmaformaparaalinguagemCOBOL,quenosuportatalrecurso. AdescriodagramticaLDIusaumanotaodesintaxesimilaraExtendedBackus NaurFormat(EBNF)epodeserencontradaem(CORBA,2004).

43

3.3.2.1TiposdedadossuportadospelaLDI
AespecificaoLDIprovumavariedadedetiposdedadasbastantesemelhanteaos oferecidos por muitas das linguagens existentes. A tabela 5 relaciona os tipos suportadoseassociaasinformaesimportantesreferentesacadaumdeles.

Tabela6TiposdedadosLDI,extradade(VINOSKI,1997;OMG,2004a) Classe
Tipoprimitivo

Tipo
long(comesem sinal) longlong(come semsinal) short(comesem sinal) float,doublee longdouble charewchar boolean octet enum any

Tamanho Observaes
32bits 64bits 16bits cf.IEEE 7541985 8bits 1bit 8bits 232 elementos NA NA NA NA umtipo,identificadoporumatag,quepodeconterovalordequalquer umdostiposLDI,incluindotiposprimitivosedefinidospelousurio. estruturacompostaeheterognea, similarao record emPascalou structemC. umtipoconstrudoapartirdeumdescriminadoredeumvalor,que serdotipodefinidopelaavaliaododiscriminador. estestipossoformadosporsequenciamentodecharouwchar, respectivamente.elespodemounotertamanhosdefinidos.para definirseumtamanho,fixo,segueseaspalavrasreservadas,stringou wstring,dosinalmenor(<),donmeroquerepresentaotamanho edosinalmaior(>).exemplo:string<10> umcontainerlinearparadeterminadotipodedados.otamanhodo containerpodeounoserdeterminado.asintaxegeral sequence<[tipo_de_dado][,tamanho]>.exemplo: sequence<string, 10>ousequence<Factory> umvalordecimalcompontofixoquenodeveexceder31dgitos significativos.exemplo:fixed<8,3>representaumnmerocom precisode5dgitoseduascasasdecimais.

Tipoconstrudo

struct union

Tiposprdefinidos

stringewstring

sequence

NA

fixed

NA

44

Todos os tipos bsicos CORBA tem seus tamanhos definidos para assegurar interoperabilidadeatravsdediferentesplataformasdehardware.(VINOSKI,1997)

3.3.2.2Heranadeinterfaces
AheranadeinterfacesumimportanterecursosuportadopelaLDI. Esterecurso aindamaispoderosoporpermitirqueumainterfaceherdecaractersticasapartirde maisdeumainterfacepai. Talcapacidadepotencializaareutilizaodeinterfaces quandonovosserviossodefinidos,conferindovantagenscomodiminuiodore trabalho,minimizaodoserroseaumentodamodularidade.(VINOSKI,1997)Estas caractersticasvodeencontroaoprincpioabertofechado,quediz:
Entidades de software (classes, mdulos, funes, etc) devem manterse abertosparaextensomas,fechadosparamodificaes.(MEYER,1988apud MARTIN,1996,traduonossa)

Quando uma interface deriva um contrato de sua interface pai, com o intuito de estendlo,aopassoqueestainterfacepaipermaneceinalterada,estsendoaplicadoo princpioabertofechado.(MARTIN,1996) Aheranadeinterfacestemsintaxebastantesimples.Umexemplodecomoherdara partirdeinterfacesmostradonafigura3.

45

// Definio de uma interface Factory // responsvel por criar novos objetos // e devolver uma referncia para eles interface Factory{ Object create(); }; // declarao forward de SpreadSheet // a interface no mostrada em sua // totalidade no exemplo. interface SpreadSheet; // SpreadSheetFactory deriva a partir // de Factory interface SpreadSheetFactory: Factory { SpreadSheet create_spreadsheet(); }; Figura6ExemplodedefinioLDI(VINOSKI,1997)

Uma classe que implemente a interface SpreadSheetFactory dever servir os seguintesmtodos: create,herdadodeFactory; create_spreadsheet,definidoemSpreadSheetFactory. Deformaimplcita,todaintefacederivaapartirdainterface Object. Destaforma, implementando qualquer interface, um objeto estar comprometendose a prover tratamento para importantes mtodos definidos na interface Object. A aplicao prticadestefatosermelhorvistomaisadiante,nosdemaistpicossobreoassunto.

3.3.3Mapeamentosdelinguagens
Conformeadefinio,aLDIumalinguagemdeclarativa,quenocapazdegerar cdigo executvel. Desta forma, os mtodos definidos atravs dela devem ser mapeados para um linguagem que implemente o cdigo necessrio a execuo das operaes.(VINOSKI,1997)

46

Omapeamentodelinguagenspossuiumoutroaspectoimportante:omapeamentoda interface do ORB e de outros pseudoobjetos. Estas interfaces constantes na especificao CORBA no derivam implicitamente de Object, como fazem as interfacesLDI.OprprioORBnoderivadeObjecteprovsuasprpriasinterfaces. Destaforma,pseudoobjetosnopodemserconsideradosobjetosCORBAreais. No entanto, especificando suas interfaces como fazem os objetos normais, os pseudo objetospermitemqueasaplicaesutilizemoORBdemaneiramuitoparecidacoma qualelasutilizamobjetosCORBA. Existem especificaes que fazem o mapeamento LDI para uma grande gama de linguagens.Mesmoassim,esforosparamapearvriasoutrasdevemestarocorrendoe, to logo sejam submetidas ao OMG devem ser publicadas. Oficialmente, a OMG publicapadresdemapeamentoparaasseguinteslinguagens20: Ada JavatoLDI C Lisp C++ PL_I COBOL Python CORBAScriptingLanguage
20 Alistadaslinguagensmapeadas,bemcomoasespecificaesdemapeamento,podemserobtidasapartirdostio daOMGem:<http://www.omg.org/technology/documents/formal/corba_language_mapping_specs.htm>. Conformeacessofeitoem02/04/2004.

47

 Smalltalk LDItoJava Comopodeseperceber,atravsdaslinguagensenumeradas,existemmapeamentospara linguagensquesuportamobjetoseparalinguagensquenoofazem.Destaformaos mapeamentos,entreobjetosdalinguagemdeimplementaoeobjetosCORBA,so feitosquandopossvel.Assim,linguagenscomoSmalltalk,C++eJavatemseusobjetos mapeados diretamente para objetos CORBA. Para linguagens procedurais, como COBOL,porexemplo,freqentementeumaestruturaabstratadedadoseumconjunto defunessomapeadosparaumobjetoCORBA.Destaforma,aestruturaabstratade dados armazenar os atributos do objeto enquanto as funes definiro o seu comportamento.(VINOSKI,1997) Por ltimo, as especificaes dos mapeamentos de linguagens sofrem peridicas revisesparaadequaremseaoestadodaartedaslinguagensdeprogramao.Istopara que programadores no sintam desconforto ao utilizar determinada linguagem com limitaesimpostaspeloseumapeamentoparatecnologiaCORBA.

3.3.4RepositriodeInterfaces
De acordo com o contedo abordado no ltimo tpico, a uniformizao do acesso atravsdeinterfacesumgrandetrunfonaCORBA.Istoimplicaquetodaaplicao baseadaemCORBArequeraacessoaosistemadetiposLDIquandoestexecutando. Esta exigncia necessria porque o cliente deve saber que valores passar como parmetros deumarequisio e,em contrapartida, aaplicaoterquesaberquais interfacesoobjetoalvosuporta.

48

Muitasdasaplicaessobaseadasapenasemconhecimentoestticodasinterfaces, utilizadoparainvocaesestticas,quebaseadonainteraoentrestubseskeletons geradosporumcompiladorLDI.Umavezqueoconhecimentoarespeitodasintefaces fixadoduranteacompilao,umaalteraoposterioremumdosobjetosenvolvidos implicananecessidadedeumanovacompilao.OexemplodeumobjetoFactory (umobjetoquecriaoutrosobjetoseretornaumarefernciaaeles),queteveseumtodo de criao alterado de novo_objeto para cria_objeto. Neste caso, a

aplicaoclientedonossoobjeto Factory terdesofrernovacompilaoparaque suasrequisiessejamagoramapeadasparaonovonomedemtodo.(VINOSKI,1997) Algumasaplicaes,noentanto,nopodemdependerdeumconhecimentoprviodo sistemadetiposLDIdaOMGparaexerceremsuastarefas.Umaaplicao,queilustra esteexemploadeumobjetoGateway(queintermediaoacessodepara)quepermiteo acessodeobjetosresidentesemumsistemasecundrio(comoaplicaesbaseadasno modelo objetocomponente (COM), da Microsoft) acessarem objetos CORBA. A necessidadederecompilaodoGatewayacadanovainclusodeintefaceLDItornaria muitodifcilamanutenoegernciadoproblema.Asoluoparaoimpassequeo Gateway possa descobrir, dinamicamente, as informaes necessrias e utilizlas. (VINOSKI,1997) Para solucionar problemas como o do Gateway, o modelo CORBA especifica o repositriodeinterfaces,RI, quepodeseracessadoeescritoprogramaticamenteem tempodeexecuo. OIRtambmumobjetoCORBAcujasoperaespodemser invocadasexatamentecomoasdequalqueroutroobjetoCORBA.Usandoainterface RI,aplicaespodematravessarhierarquiasinteirasdeinformaoLDI.Porexemplo, umaaplicaopodeiniciaremumescopodemaisaltonveldoRIeiterarsobretodas

49

definiesdemdulosneleexistente.Quandoummduloapropriadoforencontrado,a aplicaopoderentoabrireiterardemaneirasemelhantesobretodasasdefinies existentesdentrodomdolo.(VINOSKI,1997) OutraformapossveletalvezmaiseficientedeacessarinformaesexisitentesnoRI atravsdarefernciaaumobjeto InterfaceDef. Estarefernciapodeser obtida atravsdeumachamadaaomtodoget_interface() quedefinidonainterface CORBA::Object. Uma vez que todas interfaces derivam de CORBA:Object, conforme visto em herana de interfaces, todo objeto suporta o mtodo

get_interface().Destamaneira,umobjetoInterfaceDefpodeserobtidosemque qualqueroutroconhecimentoprviodoobjetosejanecessrio.(VINOSKI,1997).

3.3.5DefinindoStubseSkeletons
Os skeletons soentidadesdelinguagemdeprogramaoqueconectamum servant a umAO,permitindoqueesteencaminherequisiesaoservant.EmC,umskeleton umconjuntodeponteirosparafunesespecficasdoservant.EmC++,umskeleton, uma classe base da qual o servant deriva. Para o caso de invocaes estticas, freqentementeumskeletonapropriadogeradopelocompiladorLDI.Contudo,existe tambmnaCORBAosuporte aDynamicSkeletonInterface, (DSI),quehabilitaum servidoramanusearrequisiesparaobjetosquenotmumskeletonestticodefinido. (SHIMIDTeVINOSKI,1997) Osstubsatuamdeformasemelhanteaosskeletons,contudo,doladocliente.Osstubs sogeradospelocompiladorLDIefazemaponteentreaimplementaoexistenteeo formatosuportadopeloprotocoloInterORB,IOP.Osstubstemconhecimentoprvio dasinterfacesemtempodecompilao,assimcomoos skeletons. Porm,paracasos 50

ondedifcildeterminarasinterfacesdoobjetoqueestarsendomanipulando,existea opopelautilizaodaDynamicInvocationInterface(DII).(VINOSKI,1997)

3.3.6Invocaoeencaminhamentodinmico
Realacionadaaopapeldestubseskeletons,ainvocaoeoencaminhamentodinmico sosuportadosporduasinterfaces:

Interfacedeinvocaodinmica(IID)quesuportarequisiesdeinvocao dinmicasnaporocliente;

Interfacedeencaminhamentodinmico(IED)queprovexpediodinmica paraobjetos.(VINOSKI,1997)

Tantoa DIIquantoaDSIpodemservistas,respectivamente,como stubs e skeletons genricos. Cadaumadestas interfacesprovidadiretamente peloORBeemnada dependedasinterfacesLDIdosobjetosasereminvocados(VINOSKI,1997).

3.3.6.1Interfacedeinvocaodinmica
ParailustraranecessidadedeSeconsiderarmosaaplicaoqueatuacomo Gateway, conformevistonotpicosobreorepositriodeinterfaces,quandoumainvocaofor recebida,oGatewaydevertornarestainvocaoemumarequisioexpedidaparao objetoCORBAdesejado. Relembrando,arecompilaoLDIparageraodenovos stubs noumaboamaneiradetratarmosocaso. Damesmaforma,ocenriode navegadoresinternet,queobtmosvaloresnecessriosparapreencherosargumentos deoperaesdeobjetoapartirdousurio,podealcanarbonsresultadoscomaIID. (VINOSKI,1997)

51

 atravs da operao

create_request(), provida pela interface

CORBA:Object, que aplicaes criam requisies pseudoobjeto. Sendo toda interfacederivadaapartirdeCORBA:Object,todoobjetoaptoainvocaromtodo create_request().porumachamadaaestemtodosobrearefernciadeum objetoalvoqueumaaplicaocriaumarequisiodinmicaparaaqueleobjeto. No repositrio de interfaces, RI, os tipos para os valores de argumento so obtidos. (VINOSKI,1997)Umavezpreenchidososparmetrosdefinidosnainterfaceobtida,a invocaopoderprosseguirutilizandoumdostrsmtodosaseguir:

InvocaosncronaOcliente,quandoinvocararequisio,ficarbloqueado at que a resposta chegue. Na perspectiva cliente, esta abordagem essencialmenteequivalenteaocomportamentoRPC.Ainvocaosncronao meiomaiscomumdeinvocao.Istoporsersuportadapelosstubsestticos. (VINOSKI,1997)

Invocao sncrona deferida O cliente invoca a requisio e continua processando,atquemaistarde,elecoletaaresposta.Estaabordagemmostra se a mais indicada se vrios servios de longo tempo de execuo e independentes precisam ser invocados. Ao contrrio de esperar por cada resposta, serialmente, o cliente receber, cada uma delas, a medida que os servidores,dasquaistaisrespostasdependam,foremdispondoas.(VINOSKI, 1997)

Invocao de nica via O cliente invoca a requisio e continua o processamento.Istopornohaverrespostaparasolicitaofeita.Estaforma deinvocaoconhecidatambmpelotermo,emingls,fireandforget,ou seja,dispareeesquea.(VINOSKI,1997)

52

O caso da invocao sncrona deferida, atualmente, obriga o cliente a utilizar IID. Apenas a IID suporta este tipo de invocao atualmente, apesar dos esforos para padronizao de um servio de mensagens assncrono j mostrarem resultados consistentes.AlgunsORBscomooOrbix2000,verso2,daIONAjimplementamo servioassncronodemensagens. Vinoski(1997)advertequeoprogramadortendeaacharqueaestratgiadeutilizarDII, emdetrimentodosstubsestticos,sempreamelhor.DefatoousodeDIIprovmaior flexibilidade ao projeto mas, devese ter em mente o custo, muitas vezes oculto, envolvido nesta opo. Uma requisio DII criada para que o ORB acesse, transparentemente,oRIparaobterinformaessobreostiposdeargumentosevalores deretorno.SendooRIumobjetoCORBA,cadarequisiofeitaaeledefatouma invocaoremota. Destaforma,umanicarequisio DII podeimplicaremmuitas invocaesremotas,fazendodestaopoumaalternativamuitasvezesmaiscaradoque adeusodestubsestticos.Istoporqueosstubsjarmazenamainformaonecessria desdeomomentodacompilaoLDI(VINOSKI,1997).

3.3.6.2Interfacedeencaminhamentodinmico
Para exemplificar a necessidade das IEDs, o exemplo do Gateway, utilizado outras vezes at aqui, ser novamente til. Se este Gateway tiver de atuar de maneira bidirecional, ora como cliente ora como servidor, ele dever ter problemas com a compilaodenovosskeletonsacadanovamudana.Esteproblemasemelhanteao resolvidopelaIID,deproverumstubgenricoparaqueclientesfaamsuasrequisies emprvioconhecimento dasinterfacesdosservidoresalvo. Omesmoprincpio utilizadoatravsdasIEDs,noentanto,naporoclientedaaplicao. Diferenteda 53

maioriadosoutroscomponentesCORBA,queforampartedaespecificaoinicial,o IEDfoiintroduzidoapenascomaverso2.0daarquitetura.Aprincipalrazoparaque esterecursofosseincorporadoanovaversodopadrofoianecessidadedegateways queconectassemORBsutilizandodiferentesprotocolosdecomunicao.Comopode sever,casossemelhantesaocitadocomoexemplomotivaramaespecificaoIEDea mantmnecessriamesmonosdiasdehoje.(VINOSKI,1997).

3.3.7ProtocoloInterORB(PIO)
AintegraoentreORBsdediferentesfornecedoresnoerapossvelataverso2.0 daCORBA. AsIEDs,disponveisnaverso2.0,tornarampossvelaconstruode aplicaes que atuassem como gateways entre ORBs diferentes, contornando o problema.Contudo,nestamesmaversodaCORBAtambmconstavaaesepecificao doprotocoloInterORB,asoluodefinitivaparaintegraoentreORBs.Aadoodo Assim, os gateways foram cumprindoseupapelatqueaadoodoPIOestivesse consolidada. A velocidade com que o PIO deveria ser adotado foi um fator considerado pela OMG. Dentre as diretrizes de projeto para o protocolo constam facilidadeebaixocusto,naadequaoemanutenodeORBsquenosuportavamo PIO(OMG,2004a).MesmosendooPIOasoluooficialparaconectarORBs aIED permaneceucomoumboaescolhaparacasosparticulares.Especialmenteparapontes entreORBseparaaplicaesqueservemdeponteparasistemasCORBAeserviosou implementaesnoCORBA.(VINOSKI,1997) AtoCORBA2.0nohaviaqualquerobrigatoriedadeouconvenoqueregulasseo formato dos dados ou protocolos para comunicaes ORB. A falta de interoperabilidadeentreosORBs,cadaqualcomasuamaneiraderepresentarascoisas,

54

figuravaentreasmaioresqueixasentreosusuriosdatecnologia.Mesmonasverses anterioresaesperadaCORBA2.0jeradeconhecimentodaOMGanecessidadede especificarseumprotocolodecomunicao.Pormesteprotocolonofoiconsiderado prioridadenaquelemomento.(VINOSKI,1997) Desde meados de 1995, a especificao CORBA definia como deveria se dar a interoperabilidadediretaentreORBsetambminteroperabilidadebaseadaempontes, tambm umanecessidade,comovistonoprlogodestettulo. Ainteroperabilidade diretatornousepossveldesdequecertasconsideraesfossemobservadas: osdoisORBsaseremintegradosdevemresidiremummesmodomnioem outraspalavras,elesdevementenderasmesmasrefernciasdeobjeto; osORBsaseremintegradosdevemcompartilharomesmosistemadetiposLDI e,algumasvezes,compartilharinformaodesegurana. ParaaintegraodeORBsdediferentesdomnios,cadaqualcomsuasinformaes especficas,adefiniobaseadaempontesdeveserutilizada. Naverdade,oprotocoloresponsvelpelaintegrao,tonecessria,temumnomeum poucomaisespecficodoquePIO:ProtocoloGenricoInterORB,PGIO.Neleesto definidasassintaxesparatransfernciaeumconjuntopadrodeformatosdemensagens para comunicao interORB sobre qualquer veculo orientado a conexo. Isto mantendonveisdesejveisdeescalabilidadeedesempenho.(VINOSKI,1997;OMG, 2004a) AescolhaparaopadrodeprotocoloqueserviriadesubstratoparaoPGIOrecaiusobre oTCP/IP.Osmotivosparatantosobastantebvios.OprotocoloTCP/IPconstituise

55

comopadroporsis21.DestaformasurgiuoProtocoloInternetInterORB,PIIO,que especificacomoumPGIOconstrudosobreTCP/IP.AssimcomoumainterfaceLDI estparaumaimplementao,oPGIOestparaoPIIO.oPIIOqueespecificacomo implementar,utilizandooTCP/IP,oscontratosestabelecidospeloPGIO. OsORBs queatendamaespecificaoCORBA2.0tmdeobrigatoriamentesuportaroPIIO e PGIO.(VINOSKI,1997;OMG,2004a) ParaaespecificaodoPGIO,anecessidadedepadronizarseosformatosdereferncia aobjetosfoiumanecessidade. Apesardenoseremtransparentesparaaplicao,as refernciasaobjetossoutilizadasparaajudarosORBsadirecionarrequisiesaestes objetos. A CORBA 2.0 especifica um padro chamado Referncia de Objeto Interopervel,ROI. NoROI estoencapsuladasasinformaesnecessriaspara se localizarumobjetoeestabeleceracomunicaocomele,sobreumoumaisprotocolos derede.ParaumROIquecontenhainformaesPIIO,porexemplo,estasinformaes soonomedohosteonmerodeportaTCP/IP.(VINOSKI,1997) AscaractersticasgeraisdeprojetodoPGIOsoasseguintes:

3.3.8Osadaptadoresdeobjeto(AO)
SchimidteVinoski(1997,pg.2)definiramassimosAO: Um adaptador de objeto CORBA a materializao do padro Adaptador, uma vez que ele adapta os conceitos das linguagens de programao dos servants para os conceitos CORBAdeobjetos.(traduonossa)

21 Umestudoaprofundadosobreprotocolospodeserencontradoem(TANENBAUM,1997).

56

Opadrodeadaptadordescreveumadaptadordeobjetocomoumobjetoqueadaptea interface de algum outro objeto a interface esperada pelo chamador. Portanto, os adaptadoresCORBAsoossubcomponentesdaarquiteturaquefazemainterligao entreasimplementaesdeobjetoeoORB.Assim,temosquediferentesadaptadores suportamdiferentesestilosdeimplementaode servants. O OrbixObjectDatabase Framework, da IONA, um bom exemplo da funo de adaptao. Atravs dele, objetosimplementadosusandoumobjetodebancodedadospodemserusadoscomo servants paraobjetosCORBA. OutroexemplooAOparatemporealprovidopelo TAO.Afigura5ilustraafunodoAO. (SCHIMIDT;VINOSKI,1997;VINOSKI, 1997)

interfaceA

interfaceX

chamador

adaptador deobjeto

objeto

Chamador(esperauma interfaceA)

AO(adaptaainterfaceXparaa interfaceA)

Objeto(implementa ainterfaceX)

Figura7Papeldeumadaptadordeobjeto

Conformevistonotpicoapropriado,identificadoresdeobjetoexistemnoescopode adaptadoresdeobjeto.Estadefiniopodelevaraperguntadoporqueosregistrosde objetosnoseremfeitosdiretamentecomoncleoORB.Arespostaparaestapergunta dadaemfunodeumaopodeprojetoquelevaemconsideraoos seguintes fatoresquantoacaractersticadoORB:

Inchassoexcessivo:UmaabordagemquerequeradoncleoORBosuportea 57

mltiplas interfaces e servios para suportar mltiplos estilos de implementaodeservantstambmotornariagrande,lentoedemasiadamente complicado para a maioria das aplicaes. A adoo desta estratgia certamente comprometeria aplicaes que no se valeriam dos recursos incorporados mas, ainda assim, estariam sujeitas ao peso do ncleo ORB inchado.(VINOSKI,1997)

Perdadeflexibilidade:Outraalternativaparadispensarmososadaptadoresde objetopoderiaserimporumarestrionaqualtodosasimplementaesde servants deveriam seguir um mesmo estilo. Uma estratgia para impor tal restriopoderiaserforlosaderivarsempreapartirdeumaclassebase. ContudoestaopolimitariaautilidadedoncleoORBenquantoferramenta deintegrao,caractersticaprimordialquepermitequeelenegociecomuma grandevariedadedelinguagensdeprogramao,sistemaslegadoseestilosde projetodesoftware.(VINOSKI,1997)

Portanto,asconsideraesapontamqueumaboaescolhaisolaroncleoORBde minciasparticularesacadacaso.JustificaseentoosAOs.

3.3.8.1FuncionalidadedoAO
Para manterem o ncleo ORB mnimo, os AOs foram projetados para suportar as seguintesfuncionalidades:

Demultiplexao de requisies: O AO demultiplexa cada requisio encaminhandoaparaoservantadequado.Istoequivaleadizerqueseoncleo ORBrecebeumrequisio,elecooperacomoAOatravsdeumainterface privada(i.e,nopadronizada)paragarantirquearequisioalcanceoservant 58

apropriado.(SHIMIDT;VINOSKI,1997)

Expedio de operaes: Desde que o AO localize o servant alvo, ele despachaaoperaorequisitada. Nestepontoum skeleton utilizado para conversodosparmetrosdarequisioparavaloresdeargumentospasados paraaoperaodoservant.(SHIMIDT;VINOSKI,1997)

Ativao e desativao: Os AO podem ativar objetos CORBA e, conseqentemente,encarnarosservantsparaqueeleslidemcomasrequisies quelesobjetos. DeformaanlogaosAOtambmpodemdesativarobjetos CORBAeeterelizar servants comrelativotempodeinatividade.(SHIMIDT; VINOSKI,1997)

Geraoderefernciasdeobjeto:AoAOcabetambmaresponsabilidadede gerar referncias para os objetos registrados com ele. Estas referncias identificamoobjetoeotornamalcanavelemumsistemadistribudo.Desta maneira cabe tambm aos AO cooperarem com as camadas adjacentes do sistemaoperacionaleosfacilitadoresdecomunicaoconstrudosdentrodo ORB para assegurarse que a informao necessria para alcanar o objeto estejapresentenarefernciadoobjeto.(SHIMIDT;VINOSKI,1997)

3.3.8.2AdaptadorBsicodeObjeto(ABO)
AprimeiraespecificaoCORBAdefiniaoAdaptadorBsicodeObjeto(ABO).Este adaptadorfoiconcebidoparadarsuporteamltiplosestilosde servants. Segundoos projetistas,comaadoodoABOdeveriarestarumapequenalacunaparaqueAOs especficospreenchessem,comoparabancodedados,porexemplo.OABOdeveria

59

sersuficienteparamaioriadasaplicaes.(SHIMIDT;VINOSKI,1997) A especificao do ABO deixou importantes lacunas que apontaram como melhor escolhasuasubstituioporumanovaespecificao.Estalacunasforam: Nodefinirumcaminhoportvelparaassociarskeletonscomservantsnoh na especificaoABO definies parao aspecto de skeleton nem tampouco como estes devem associarse aos servants. Sem estas diretrizes, programadores tinham de resolver por si os problemas que impedissem a portabilidade;(SHIMIDT;VINOSKI,1997) No descrever a contento como deveria ser o registro de servants: As implementaes do ABO permitem, freqentemente, que servants sejam registradosimplicita(atrvesdeumconstrutor,porexemplo)ouexplicitamente (atravsdachamadaaummtododoBOA).SemdefinirasAPIsenvolvidas,a tendnciafoiadequecadaimplementaoORBadotasseoestilodeAPIque lheconviesse;(SHIMIDT;VINOSKI,1997) Ignorar completamente a necessidade de diretrizes para implementao de processos servidores multitarefa: ACORBA 2.0nodefineosparmetros paraasimplementaesmultitarefadoORB.Asnecessidadesdeparalelismo para atividades de longo tempo de durao imperativa e levou os implementadoresdeORBadesenvolveremtcnicasdeprocessamentomulti tarefaparticulares.(SHIMIDT;VINOSKI,1997) No definir precisamente as funes requeridas para um servidor ouvir requisies:OsABOsprovmduasoperaesqueparecemfazeroservidor iniciar o processamento de requisies: impl_is_ready e

obj_is_ready.Aespecificaotrazqueasduasfunesdeativaodevam 60

serusadasemfunodaescolhadomodelodeativao.Contudo,sendomuito vagaeconfusa,estaespecificaofezcomquediferentesfornecedoresdeORB utilizassemcadaumadestasfunesparadiferentesfinalidades.(SHIMIDT; VINOSKI,1997) As falhas apontadas quase comprometeram a portabilidade, do lado servidor das aplicaes,entrediferentesimplementaesORB.PoressemotivoaOMGpromoveu uma nova RFP para corrigir os problemas diagnosticados no ABO. (SHIMIDT; VINOSKI,1997)

3.3.8.3AdaptadordeObjetoPortvel(AOP)
Foiemmarode1997queaRFPcomasdiretrizesparacorreodasinconsistncias ABOfoisubmetidaapadronizaodaOMG.Surgiuento,emsubstituioaoABO,o AdaptadordeObjetoPortvel,AOP,quenoscorrigiaosproblemasdoseuantecessor comotambmpossuianovosrecursos.(SHIMIDT;VINOSKI,1997) OsnovosrecursostrazidospelaespecificaoAOPtornaramagernciadosobjetos aindamaisfceis.ShimidteVinoski(1997)destamosseguintes: indentificadoresdeobjetoprovidosparaosistemaouparausurios objetospersistentesetransientes; mapeamentodemltiplosservantsparaumobjetoCORBA; controletotaldaaplicaosobreocomportamentoeexistnciadeobjetos;

servantsestticosedinmicos.
Entreosnovosrecursos,existnciadeobjetospersistentesetransientesconferiuum 61

outronveldeflexibilidadeaoORBeaoAOP. Agora,asaplicaesquepossuissem objetos CORBA que no necessitassem que o seu estado fossem mantido entre ativaespoderiamcriloscomotransientes.Comestacaracterstica,asobrecargaque recaiasobreoAOPeoORBparaorastreiodoestadodeobjetospdeserdiminuida considervelmente.(SHIMIDT;VINOSKI,1997) O esquema de ativao utilizado pelo AOP mudou o foco que antes estava nos processosnosquaisosobjetosseinseriamparaaativaoeencarnaode servants. Destaforma,paraoAOPexistemquatrotiposdeativaopossveis: Ativaoexplcita:Oprogramadordaaplicaoservidoraregistraos servants comchamadasdiretasaoAOP;(SHIMIDT;VINOSKI,1997) Ativao sob demanda: o programador da aplicao servidora registra um gerente para servants que ir ficar ativo esperando por soliciataes (SHIMIDT; VINOSKI, 1997). Uma das operaes a seguir pode ser desencadeadaquandoumarequisiochegaaogerente: Ogerenteencarnao servant necessrioeoregistracomoAOPqueir encaminhararequisioaesteservant;(SHIMIDT;VINOSKI,1997) Ogerentegeraumaexcesso ForwardRequest (defiiadanomdulo PortableServer)paraquearequisiosejaenviadaaoutroobjeto. Esta excesso contm a referncia para o objeto ao qual ser feito o redirecionamento. Este recurso permite que sejam implementadas as estratgiasdeexecuoemlocalespecficoebalanceamentodecarga,por exemplo;(SHIMIDT;VINOSKI,1997) O gerente gera uma excesso CORBA::OBJECT_NOT_EXIST para indicarqueoobjetoCORBAfoidestrudo.(SHIMIDT;VINOSKI,1997) Ativao implcita: uma ao em um servant resulta na ativao sem que chamadasexplcitassejamfeitasaoAOP.Porexemplo,nomapeamentoLDI

62

paraalinguagemC++,aativaoimplcitadeumservantemumAOP,comas polticas apropriadas, podeserobtidainvocandoseomtodo _this deste servant;(SHIMIDT;VINOSKI,1997)

Servantpadro:aaplicaoregistraumservantpadroqueserusadoquando
umarequisiochegarparaumobjetoCORBAquenoestaativadoequeno possuiumgerenteparaservantsassociado.Esterecursomuitoprticopara aplicaesbaseadasemservidoresIED,permitindoqueumnicoservantIED encarne todos os objetos CORBA sem que outras intervenes sejam necessrias.(SHIMIDT;VINOSKI,1997) Ocdigoapresentadonafigura6mostraumcasodeutilizaoAOP.

63

int main (int arc, char *argv[]) { using namespace CORBA; using namespace PortableServer; // inicializando o ORB ORB_var orb = ORB_init (argc, argv); // obtendo um referncia de objeto para // o AOP raiz Object_var obj = orb->resolve_inital_references(RootPOA); POA_var poa = POA::_narrow(obj); // encarna um servant My_servant_Impl servant; // registra implicitamente o servant com // a raiz AOP obj = servant._this(); // inicia o monitoramento de requisies // do AOP poa->the_POAManager()->activate(); // executa o loop de eventos do ORB orb->run(); // ... } Figura8ExemplodedefinioLDI(VINOSKI,1997)

NocasoapresentadooORBprimeiramenteinicializadoeapartirdeleumareferncia ao AOP raiz obtida. A partir da ele cria uma instncia de uma classe servant My_Servant_Impl e invoca o mtodo _this dela. Esta ativao implcita registra o servantjuntoaoAOPraizeretornaumarefernciaparaonovoobjetoCORBAcriado. DeacordocomapolticapadroobtidaapartirdaraizAOP,definidanaEspecificao dePortabilidadeAvanada,onovoobjetoCORBAserdotipotransiente.Ogerente AOP ento ativado para que possa tratar as requisies. Por ltimo, a operao ORB::run chamada para o loop de eventos principal da aplicao. (SHIMIDT; VINOSKI,1997) Atravsdocontedoedoexemplodado,vsequeaespecificaoAOPdefineuma 64

faixaabrangentedepolticasquepermitemaosdesenvolvedoresintegraremdiferentes casosdeusodesuasaplicaesaoscomportamentosdosORBs.Pesanoentantoofato dosfornecedoresdeORBspromoveremextensesproprietriasaespecificaoAOP. Autilizaodetaisrecursoscomprometeainteroperabilidadeparaqualfoipropostaa novaespecificao. AOMGrecomendaqueosfornecedoresquejulguemquesuas extensessonecessriasqueassubmetamaogrupoparanormatizao. (SHIMIDT; VINOSKI,1997)

65

3.4Concluso

66

CaptuloIV
4ContribuiesCORBAparareamdica
4.1Motivaoparaaadoodepadresnareamdica
Osgrandeshospitaistmemsuasestruturadiversossubsistemas,cadaqualadequadoa umdepartamentoespecficomas,incapazesdeagiremdeformaintegradaentresi.De umamaneiraampla,compeocontextodossistemasdeinformaohospitalaresmuitos sistemaslegados,sistemasmodernosqueincorporamnovastecnologiaseprovmnovos serviosesistemasembarcadosemequipamentosmdicos. Natentativadediminuiraincompatibilidadeentretodoselementoscomputacionaisda reamdicaforamcriadosalgunspadres,promovidosporcertasinstituiescomoa OpenEHR, o HL7 e a National Electrical Manufacturers Association (NEMA). A situaoidealizadaadeumsistemadeinformaescapazdefornecertodainformao relativaaumpaciente,ondequerqueelaesteja,aumapessoaautorizada,ondequerque elaesteja. OElectronicHealthRecord (EHR)seriaosistemaidealquecontemplaria estecenrio.ParatornaroEHRpossvel,esforostmsidoempregadossobrepadres comooCORBAmed,oHL7Verso3eo GoodElectronicHealtRecord (GEHR). Contudo tornar o EHR uma realidade ainda esta distante de acontecer. (FURUIE;MORENO,ca.2001) A utilizao de padres e especificaes visam promover uma soluo que proveja independnciadefornecedoreseja apta asuportarfuturos requisitos em termos de 67

segurana, tipo de intercmbio de dados e recuperao de informao. (FURUIE;MORENO,ca.2001)

4.2ApresentaodostrabalhosdaHealthDomainTaskForce(HDTF) 4.2.1ComootrabalhopromovidopelasDomainTaskForces(DTF) juntoaOMG

Existem diversas aplicaes que so pertinentes a ramos de negcio especficos, denominadosdomnios.OOMG,paraatenderasnecessidadesparticularesdosgrandes domnios existentes, constituiu grupos, conhecidos por Domain Task Forces, que promovemoestudodesoluesespecficasnassuasreasdenegcio. Osestudos promovidos por estas foras tarefas so balizados pela arquitetura OMA, tambm mantida pela OMG conforme j mencionado neste trabalho. To logo um DTF cristalize o estudo sobre algum tema, submeteo a aprovao do OMG. Uma vez aprovado,otrabalhoserpublicadocomoumaespecificaoformal22,endossadapelo OMG.(OMG,1999) AsforastarefasdedomniosubordinamseaoOMGeasespecificaesproduzidaspor elassoagrupadassobonomeCORBAseguidopelonomedoramodenegcioao qualsedestinam.Estasespecificaescostumamdefinirintefacesparaodomnioalvo, talcomoprevaOMAnoseucomponente InterfacesdeDomnio. Estasinterfaces visam promover a interoperabilidade entre uma variedade de plataformas, sistemas operacionais,linguagensdeprogramaoeaplicaes,sendoesteoobjetivomaiordo OMG.
22 Algunsestudosacabamconstituindoseempadres,defato,mesmoantesdeseremaprovadoseformalizados peloOMG.EsteocasodoClinicalImageAccessService(CIAS)quejpossuigrandestatusmesmosemter sidopublicadoformalmente

68

Constamem(OMG,1999)ostrabalhosdosseguintesgrupos: Paraareadenegcios:CORBABusiness; Paraareadecomrcioeletrnico:CORBAElectronicCommerce; Paraareafinanceira:CORBAFinance; Paraareadecinciasbiolgicas:CORBALifesciences; Paraareademanufatura:CORBAManufacturing; Paraareadetelecomunicaes:CORBATelecoms; Paraareadetransportes:CORBATransportation; Paraareadesadefoiinstitudoumaforatarefadenominada HealthDomainTask Force (HDTF). Dentre os trabalhos promovidos por ela constam alguns j homologados pelo OMG. A coleo de especificaes, temos a compilao de especificaesCORBAmed,objetodeestudodestecaptulo.

4.3AsespecificaesCORBAparaodomniodeSade
Os esforos da Health Domain Task Force (HDTF) resultaram na especificao de cincopadres.Estascontemplamasprincipaisnecessidadesidentificadasatopresente momentoparaodomnioproposto.Estasespecificaesconstamnatabela7.

Tabela7EspecificaesCORBAmed
Especificao CIAS(ClinicalImageAccessService)
23

Descrio
Oserviodeacessoaimagensclnicasumconjuntodeinterfaceseestruturasde dadoscomasquaisumservidorpodefornecerimagensclnicas.

23 NoexisteaindaespecificaoformalparaoCIAS. Odocumentoreferenciadotratasenaverdadedeuma submissofinal,contudo,aindanoaprovadapeloOMG.Maioresinformaesem(OMG,2001d)

69

Especificao COAS(ClinicalObservationsAccessService)24 LexiconQueryService25 PIDS(PersonIdentificationService)26 RAD(ResourceAccessDecision)27

Descrio
Oserviodeacessoaobjervaesclnicasumconjuntodeinterfaceseestruturasde dadoscomasquaisumservidorpodefornecerobservaesclnicas O servio de consulta lxica especifica um conjunto de mtodos genricos, com suporte apenas a leitura, para o acesso ao contedo de sistemas com terminologia mdica. Oserviodeidentificaopessoasdefineinterfacesqueorganizamogerenciamento deidentificaodepessoas,funcionalmenteparaasnecessidadesdareadesade. Ofacilitadorrecursoadecisodeacessoummecanismoparaobtenodedicises deautorizoeadministraodaspolticasdedecisodeacesso.Eleforneceummeio paraqueaplicaesrequisitemerecebamumdecisodeautorizao.Estefacilitador utilizadoportantocomoumcomponentedeseguranaparaaplicaes.

As especificaes relacionadas na tabela 7 so compostas de uma variedade de diagramasdeclassequedefinemomodeloproposto,acompanhadosdasconsideraes quejustificamasopesadotadas. Maisadianteserodetalhadasasespecificaesquefizerampartadaexperinciado InstitutodoCorao,partedoHospitaldasClnicasdaFaculdadedeMedicinadaUSP (InCorHCFMUSP).

4.4AplicaodasespecificaesdefinidasnoCORBAmed
Este tpico destinase a avaliao da eficcia da aplicao das especificaes CORBAmedemumcenriomdicoreal. OInCorHCFMUSPpossuiumdoscasos mais completos de aplicao da tecnologia CORBA e suas especificaes para o domnio mdico. Suportado pelos artigos publicados pelo grupo de Pesquisa e Desenvolvimento de Informtica do InCor, esta seo apresentadas as variveis
24 Maioresinformaesem(OMG,2001b) 25 Maioresinformaesem(OMG,2000) 26 Maioresinformaesem(OMG,2001a) 27 Maioresinformaesem(OMG,2001c)

70

envolvidas na experincia deaplicao depadres paraareamdica, sobretudo a CORBAmed.

4.4.1ApresentaodogrupodePesquisaeDesenvolvimentodaDiviso deInformticadoInCor
Desdesuacriao,em1976,ogrupodePesquisaeDesenvolvimento,P&E,daDiviso de Informtica do Instituto do Corao do Hospital das Clnicas da Faculdade de Medicina da USP (InCorHC.FMUSP), executa pesquisa, desenvolvimento e implementaodesistemasdeinformaoparareamdica.Durantesuaexistncia,o grupoP&Dveminvestindoeminfraestrutura,bemcomoaformaodepesquisadores emprocessamentodigitaldesinaisbiolgicos,imagensmdicaseontrastecnologiasde informao. EstasiniciativastmcolocadooInCorentreasinstituiescommaior experincianopasparaasreasdeprocessamentodesinaiseimagensmdicas,tendo desenvolvidoinmerossistemascomputadorizadosdeusocotidiano. DuranteosltimosanosogrupoP&Dtemdedicadograndeesforoparaintegratodas as informaes clnicas, focando a implementao de um sistema de registro de pacientes eletrnico. Nestes trabalhos esto evolvidos candidatos aos ttulos de mestrado e Ph.D., graduandos, psgraduandos e estagirios de diferentes reas do conhecimento.

4.4.2AnlisedautilizaodeespecificaesCORBAmedpeloInCor
OInCor,assimcomooutrosgrandeshospitaisespalhadospelomundo,temcomouma das principais metas a disponibilizao de um sistema de pronturio eletrnico, preferivelmente baseado em web, que integre todas as informaes relevantes de

71

pacientes. CombasenestanecessidaaequipedoServiodeInformticadoInCor HC.FMUSPdesenvolveu,nosltimosquatroanos,umprojetoparaadefiniodeum modelodeambientedistribuidoparaatransmisso,arquivamento,processamento e visualizaodeimagensmdicas,integrandoasaosistemadeinformaesdoHospital das Clnicas (HC) da Faculdade de Medicina da USP, em geral, e do InCor, em particular.Osucessodoprojetoconsisteemdisponibilizaraousurioimagensmdicas apartirdeseusatributos,quepodemserdemogrficos,relativosaoequipamentode aquisiooupartedocorpo.(FURUIE;REBELOet.al.ca.2001) Entre os desafios identificados na definio do projeto consta a implementao de visualizadores contextuais para otimizar, automaticamente, as propriedades de visualizao(comoresoluoespacial,velocidade)scaractersticasdomonitornoqual as imagens estejam sendovisualizadas eaos atributos daprpriaimagem. Mesmo dispondodoscomponentestecnolgicosnecessriosaaquisio,aoarmazenamento,a transmissoeavisualizaodedadosdeimagememumambientedistribudo,ainda existiram importantes entraves ao progresso do trabalho. Entre estes entraves destacavamse a manipulao de volumes de dados demasiadamente grandes em procedimentos debusca,processamentoevisualizaoemumambiente distribudo. (FURUIE;REBELOet.al.ca.2001) Contemplandotodasasfasesdociclodevidadosoftware,oprojetodogrupodeP&D do InCor compreendeu o levantamento de requisitos, a modelagem, implantao de infraestrutura e a implementao de diversos mdulos que compunham o projeto. (FURUIE;REBELOet.al.ca.2001) O projeto descrito acima fora batizado de Picture Archiving and Communication System PACSHC e previa a utilizao de trs padres: interfaces CORBAmed, 72

implementao GEHR e intercmbio de mensagens HL7. O desenvolvimento do projetocompreendeuaimplementaodasinterfacesPIDS,COASeCIAS. Aopo pelaadoodospadresCORBAmedfoifeitaemfunodestespadrespermitiremque consultascomplexassejamexecutadasosbreosdadosarmazenadosemumbancode dadosrelacional.(FURUIE;MORENO;FIALES,ca.2001)Aarquiteturadoprojeto podeservistanafigura7.(FURUIE;REBELOet.al.ca.2001)

cliente

cliente

cliente

CORBA

Serviode Identificaode Pacientes

Serviode Acessoa Observaes Clnicas

Serviode Acessoa ImagensMdicas

Figura9ArquiteturadoprojetoPACSHC

O ambiente de trabalho utilizado para as implementaes das especificaes CIAS, COASePIDSfoibaseadoemJavasobaIDEdoInpriseJbuider5.0.Forautilizadoa verso 1.2.2 do JDK associado ao ORB Inprise Visibroker, verso 3.3 para o desenvolvimentodoPIDS.ParaodesenvolvimentodoCOASedoCIASutilizousea verso1.4doJDKassociadoaocompiladorIDLJeoORBDquefazempartedoJDK28.
28 Em ( FURUIE;MORENO, ca. 2001) foi encontrado referncia a utilizao do ORB JacORB 1.4 para o desenvolvimentodoCIASeCOAS. Neleconstaaindaqueosmotivosqueembasaramaadoodoreferido

73

(FURUIE;REBELOet.al.ca.2001) ApesardasinformaessobrepacientesrecomendadaspelaOMGderivaremdedois padres: orecomendadopelaHL7eoadotadopeloscartesVisaeMastercardo grupoP&D optouporadotarumaversomais adequadaaocontextonacional. A melhor alternativa encontrada para esta opo foi implementar as informaes padronizadaspeloComitdePadronizaodoRegistroClnico(PRC),quemostrouse uma deciso acertada pois, permitiu o intercmbio de informaes entre PIDS implementadosporoutrasinstituiessemquequalquerimplementaoadicionalfosse necessria.(FURUIE;REBELOet.al.ca.2001) A publicao dos resultados das consultas feitas ao COAS foram padronizadas em XML,conformerecomendaaespecificao.OCOASfoiprojetadoparasercapazde interagircomdiferentesservidoreseapresentarsuarespostaemformatodedocumentos XMLaocliente.(FURUIE;REBELOet.al.ca.2001) ParaoCIASfoiadotadoumacpiaparcialdeumbancodeimagensDICOMquej existia.OservidorDICOMpersisteasimagensrecebidasemdiscoealimentatabelas emumbancodedadoscomasinformaesmaisrelevantes. Estasinformaesso utilizadaspelasinterfacesCIASpararecuperaodaimagem.Oesquemaapresentado nafigura8.(FURUIE;REBELOet.al.ca.2001)

ORBforamosuporteaosrecursoCORBASecurityaliadosaofatodeserumORBlivre.Osautoresapontamque outroORBpoderiaseradotadosemmaioresprejuzosaopropsitoestudado.

74

Figura10EsquemadeimplementaoCIAS
ClienteDICOM

Bancodedados SQL

ClienteDICOM

ServidorDICOM

ClienteDICOM

discorgido

Implementao CIAS InterfaceCIAS

SQL

ORB
InterfaceCIAS ClienteCIAS InterfaceCIAS ClienteCIAS

Foiimplementadotambm,emJava,umprottipodoservidordecontroledeacessoe autenticao,afimdesuportarasinterfacesdoCORBASecurityServiceedoRAD Facility respectivamente. Estas interfaces so disponbeis atravs do servidor CORBA/Visibroker, sendo que as autorizaes, papis, representao dos recursos protegidoseusuriossoarmazenadaosemumserviodediretrioshierarquizado,cujo acessoeesquemasdedescriodedadossopadronizadosatravsdoprotocoloLDAP (LightweightDirectoryAccessProtocol). A ltima etapadoprojeto foi aimplementao deum VisualizadorContextual. O esquemacomosmdulosquecompeovisualizadorpodeservistonafigura9. O mdulo contextual consiste, basicamente, de uma instncia da classe contexto (o contextoraiz)comseussubcontextosgeradosdeacordocomamquina,ousurioeas opes selecionadas em tempo de execuo. O mdulo CORBA compreende os sistemasdeautenticao,oCOAS,CIASEPIDS,sendotodosacessadosviaCORBA. 75

o mdulo DICOM compreende a comunicao com entidades remotas atravs do protocoloDICOM. OmduloIOrealizademaniratranparentealeituradeimagens locaiseastornamdisponveisparaogerenciadordeinterface.Omdulogerenciador deinterfaceresponsvelpelogerneciamentodainterfaceedefiniodequalViewer serselecionadoparadeterminadotipodeimagemouinformao.(FURUIE;REBELO et.al.ca.2001)

Figura11MdulosdoVisualizadorContextual

Da maneira com que foi implementado o visualizador permite a apresentao de imagensdediversosformatos,modalidadeseemdiversosinstantesdetempo.Otipoda imagemirdeterminarasoperaespossveissobreela.(FURUIE;REBELOet.al.ca. 2001)

76

4.4.3OpiniodogrupoP&DdoInCorsobreCORBAeCORBAmed
Autilizaodespadresabertos,assimcomoCORBAeCORBAmed,conferiramao projeto PACSHC, em todas as etapas do desenvolvimeto, robustez e flexibilidade. Aferiusequeosprottipos desenvolvidos duranteoprojetopodemserintegradosa outros sistemas de forma transparente. Muito embora a proposta inical fosse a de modelardadosdeimagensmdicas,omodeloresultante doprojeto,bemcomosua infraestrutura,acabaramsendomaisamplosepermitemaapresentaodequalquer dadooudocumentomdico.(FURUIE;REBELOet.al.ca.2001) Dois mdulos, dentre os projetados, encontramse em funcionamento em carter de produo: o servidor DICOM desenvolvido em Java, que utilizado para armazenamentoetransmissodeimagensdoPACSInCoreosistemdecontrolede acesso,utilizadoparaacessoaoPronturioEletrnico. (FURUIE;REBELOet.al.ca. 2001) ApesardaadoodasespecificaesCORBAofereceremindependnciadeplataforma, detectouse a falta de outro padro capaz de suprir a falta de interoperabilidade semntica e a dificuldade da especificao para implementao. O grupo de P&D apontaaindaqueestasfalhaspossivelmentejustifiquemabaixavelocidadecomque empresasdodomniodasadeadotamaCORBAmed.(FURUIE;MORENO,ca.2001)

77

4.5Concluso

78

RefernciasBibliogrficas
[BERNSTEIN,1996]BERNSTEIN,PhilipA.Middleware:AModelfor DistributedServices.CommunicationsoftheACM39,2(February1996):86 97. [BRAY,1997]BRAY,Mike.Middleware.CarnegieMellonUniversity,availiable in<http://www.sei.cmu.edu/str/descriptions/middleware_body.html>,1997. Acessadoem03/04/2004. [CA;TRW,1997a]CA,RedondoB.;TRW,CoryV.MessageOriented Middleware.CarnegieMellonUniversity,availiablein <http://www.sei.cmu.edu/str/descriptions/momt.html>,1997a.Acessadoem 03/04/2004. [CA;TRW,1997b]CA,RedondoB.;TRW,CoryV.RemoteProcedureCall. CarnegieMellonUniversity,availiablein <http://www.sei.cmu.edu/str/descriptions/rpc.html>,1997b.Acessadoem 03/04/2004. [CA;TRW,1997c]CA,RedondoB.;TRW,CoryV.DistributedComputing Environment.CarnegieMellonUniversity,availiablein <http://www.sei.cmu.edu/str/descriptions/dce.html>,1997c.Acessadoem 03/04/2004. [CORBA,ca.2004]CORBA,Basics.Disponvelem: <http://www.omg.org/gettingstarted/corbafaq.htm>.[ca.2004].Acessadoem: 02/01/2004. [DCE]DCE,Documentation.PublicationsCatalog.Disponvelem <http://www.opengroup.org/pubs/catalog/dz.htm>.Acessadoem02/04/2004. [ECKERSON,1995]ECKERSON,WayneW.ThreeTierClient/Server Architecture:AchievingScalability,Performance,andEfficiencyinClient ServerApplications.OpenInformationSystems10,1(January1995):3(20). [FURUIE;MORENO,ca.2001]FURUIE,Srgio;MORENO,Ramon.Framework fortheDevelopmentoftehClinicalImageAccessServiceusingJava.ca. 2001,HeartInstitute(InCor),UniversityofSoPaulo,Brazil

79

[FURUIE;MORENO;FIALES,ca.2001]FURUIE,Srgio;MORENO,Ramon; FIALES,Vivian.CIASachievinginteroperabilityusingCORBA.ca.2001, InstitutodoCoraoHCFMUSP,EscolaPolitcnica,UniversidadedeSoPaulo [FURUIE;REBELOet.al,ca.2001]FURUIE,Srgio;REBELO,Marina; MORENO,Ramon;NARDON,Fabiane;MOTTA,Gustavo.Pronturio EletrnicoemAmbienteDistribudoeHetergeneo:aExperinciado InCor.ca.2001,ServiodeInformtica,InstitutodoCoraoHCFMUSP, DeptodeEngenhariaEltricaEscolaPolitcnicaUSP,Depto.deInformtica UniversidadeFederaldaParaba [GTE,1997]GTE,DavideS.TransactionProcessingMonitorTechnology. CarnegieMellonUniversity,availiablein <http://www.sei.cmu.edu/str/descriptions/tpmt.html>,1997.Acessadoem 03/04/2004. [MARTIN,1996]MARTIN,RichardC.TheOpenClosedPrinciple.C++Report, vol.8,Jan.1996. [MEYER,1988]MEYER,Bertrand.ObjectOrientedSoftwareConstruction, PrenticeHall,1988,p.23 [OMG,1999]OMG.CORBAMed:HealthcareDomainSpecifications.1999, Version1.0,availablein<http://www.omg.org/cgibin/doc?formal/990301>. Acessadoem06/04/2004. [OMG,2000]OMG.LexiconQuerySpecification.June2000,Version1.0, availablein<http://www.omg.org/cgibin/doc?formal/20000631>.Acessado em06/04/2004. [OMG,2001a]OMG.PersonIdentificationService(PIDS)Specification.April 2001,Version1.0,availablein <http://www.omg.org/cgibin/doc?formal/20010404>.Acessadoem 06/04/2004. [OMG,2001b]OMG.ClinicalObservationsAccessServiceSpecification.April 2001,Version1.1,availablein <http://www.omg.org/gettingstarted/gettingstartedindex.htm>.Acessadoem 06/04/2004. [OMG,2001c]OMG.ResourceAccessDecisionFacilitySpecification.April 2001,Version1.0,availablein<http://www.omg.org/cgibin/doc?formal/2001 0401>.Acessadoem06/04/2004. 80

[OMG,2001d]OMG.ClinicalImageAccessServiceSpecification.August2001, availablein<http://www.omg.org/cgibin/apps/do_doc?dtc/010801.pdf>. Acessadoem06/04/2004. [OMG,2004a]OMG.CommonObjectRequestBrokerArchitecture:Core Specification.March,2004,Version3.0.3,availablein <http://www.omg.org/technology/documents/corba_spec_catalog.htm>. Acessadoem03/04/2004. [OMG,ca2004b]OMG.AbouttheObjectManagementGroup(OMG). 2004,availablein<http://www.omg.org/gettingstarted/gettingstartedindex.htm>. Acessadoem06/04/2004. [SCHIMIDTeVINOSKI,1997]SCHIMIDT,DouglasC.andVINOSKI,Steve. ObjectInterconnectionsObjectAdapters:ConceptsandTerminology. SIGSC++Reportmagazine,column11,October1997. [SCHIMIDTeVINOSKI,2004]SCHIMIDT,DouglasC.andVINOSKI,Steve. TheCORBAComponentModel:Part1,EvolvingTowardsComponent. C/C++UsersJournal,February2004.1997. [SCHREIBER,1995]SCHREIBER,Richard.MiddlewareDemystified. Datanation41,6(April1,1995):4145. [SEIK.;SEIJ.,1997]SEI,JonhF.andSEI,KurtW.ObjectRequestBroker, CarnegieMellonUniversity,aCORBAMed:HealthcareDomain Specificationsvailiablein <http://www.sei.cmu.edu/str/descriptions/orby_body.html>,1997.Acessadoem 03/04/2004. [SEI,2001]SEI,SantiagoC.ComponentObjectModel(COM),DCOM,and RelatedCapabilities.CarnegieMellonUniversity,availiablein <http://www.sei.cmu.edu/str/descriptions/com.html>,2001.Acessadoem 03/04/2004. [SIEGEL,1998]SIEGEL,Jon.OMGOverview:CORBAandtheOMAin EnterpriseComputing.CommunicationsoftheACM,Vol.41,N10,October 1998. [TANENBAUM,2001]TANENBAUM,AndrewS.OrganizaoEstruturada deComputadores.LivrosTcnicoseCientficosEditoraS/A,2001,4edio, ISBN8521612532.

81

[TANENBAUM,1995]TANENBAUM,AndrewS.DistributedOperating Systems.PrenticeHall,1995,ISBN0132199084. [TANENBAUM,1997]TANENBAUM,AndrewS.RedesdeComputadores. EditoraCampus,1997,3edio,ISBN8535201572. [TANENBAUM,2003]TANENBAUM,AndrewS.SistemasOperacionais Modernos.PrenticeHall,2003,2edio. [VINOSKI,1997]VINOSKI,Steve.CORBA:IntegratingDiverseApplications WithinDistributedHeterogeneousEnviroments.IEEECommunications Magazine,Vol.35,N2,February1997. [VINOSKI,2003]VINOSKI,Steve.ServiceDiscovery.ColumnfromIEEE InternetComputing,JanFeb2003,n.1,p.6971. [WALDO;WOLLRATH]WALDO,Ann;WOLLRATH,Jin.Trail:RMI. Disponvelem:<http://java.sun.com/docs/books/tutorial/rmi/index.html>. Acessadoem:02/04/2004.

82