Perguntas Frequentes
O padrão CORBA - Common Object Request Broker - do grupo OMG (Object Management
Group) propõe uma arquitetura de software para suportar distribuição e garantir a
interoperabilidade entre diferentes plataformas de hardware e sistemas operacionais.
Resumidamente, o padrão CORBA possibilita a comunicação entre aplicações
independentemente de sua localização ou ambiente. A especificação CORBA 1.1 foi
proposta em 1991 e definiu a linguagem de definição de interfaces IDL
(Interface Definition Language) e as Interfaces Programáveis de Aplicações - API
(Application Programming Interfaces) que possibilitam a interação cliente-servidor
via objetos com uma implementação específica de um ORB (Object Request Broker). A
implementação Corba 2.0, adotada em dezembro de 1994, define a verdadeira
interoperabilidade através da especificação de como ORBs de diferentes
fornecedores de software podem interoperar.
O ORB é o middleware que estabelece os relacionamentos cliente-servidor entre os objetos.
Utilizando um ORB, um cliente pode invocar transparentemente um método de um objeto no
servidor, que pode estar na mesma máquina ou em qualquer ponto da rede. O ORB intercepta
a chamada por parte do cliente e tem a responsabilidade: localizar o objeto que
implementa a chamada,passar os parâmetros necessários a este objeto, fazer a
chamada dos métodos e retornar dos resultados. O cliente, por sua vez, não precisa
preocupar-se com a localização do objeto que está sendo invocado, na que
linguagem que o mesmo foi programado ou, mesmo, no sistema operacional que está sendo
utilizado. Para o cliente a única coisa que importa é a interface. Ao realizar esta
tarefa, o ORB oferece uma solução para a interoperabilidade entre aplicações em
máquinas diferentes em ambientes distribuídos e heterogêneos, ao mesmo tempo que
interconecta múltiplos sistemas baseados em objetos.
O segredo desta arquitetura reside na definição das interfaces, ou seja, na forma
como os objetos vão interagir entre si e que serviços (métodos) estarão disponíveis.
A correta definição das interfaces é, sem dúvida, o maior desafio desta arquitetura.
Geralmente, nas aplicações cliente-servidor clássicas, os desenvolvedores
utilizam um protocolo próprio ou reconhecem um protocolo padrão para estabelecer a
comunicação entre módulos. A definição do protocolo depende da linguagem de
implementação, do protocolo da rede e uma dezena de outros fatores. ORBs simplificam
este processo. No caso do ORB, o protocolo é definido através da aplicação de
interfaces através da IDL - Interface Definition Language uma implementação linguagem
independente. O ORB na realidade oferece flexibilidade. Desenvolvedores tem a liberdade de
escolher o sistema operacional, o ambiente de desenvolvimento e execução de cada um dos
componentes que está sendo desenvolvido. Mais do que isto, através da utilização de
ORBs é possível a integração de componentes já existentes.
O OMAG - Object Management Architecture Guide descreve os objetivos técnicos,
terminologias e infraestrutura conceitual que suportam a aquitetura. Estas
especificações podem ser encontradas no site da OMG .
2. O que são componentes de software?
Um componente de software é qualquer subsistema que possa ser separado e que possui uma interface reusável e potencialmente padronizável.
Os exemplos mais frequentes são: Controls do Windows (botão, campo de edição,
listbox, etc), componentes Delphi 3.0, Controls do Visual Basic (grid, table, etc),
Controls OCX, JavaBeans, etc.
Eles aparecem na barra de ferramentas dos sistemas de desenvolvimento. Ex: Access, Excel,
Visual Basic, Delphi, Power Builder, Visual Cafe,
São Unidades de Padronização
São Unidades de Substituição
3. Quais as vantagens de se trabalhar com componentes de software?
Um programa montado com componentes é uma composição de partes. Cada parte (componente) pode ser substituída para atualização ou correção, sem precisar alterar ou recompilar a aplicação.
As partes podem ser reutilizadas em outras aplicações. Funciona
como as peças de um carro. Eu posso substituir o carburador ou colocar um turbo no motor
do carro sem ser necessario levar o carro de novo para a linha de montagem.
A pesar de ser um conceito muito antigo na industria, só agora esta
sendo possível de implementar em software.
O conceito básico que esta por trás é a padronização. As
substituições podem ser realizadas sempre e quando existam padrões que regulem as
características externas das peças.
Este é o objetivo do consórcio. Chegar a padrões consensuais a
respeito das peças que serão trocadas.
Uma outra vantagem é o encapsulamento de conhecimento. Continuando
com a analogia do motor, meu mecânico não precisa conhecer o coeficiente de isolação
elétrico da porcelana para substituir uma vela.
Isto facilita muito o desenvolvimento de novas aplicações, pois quem
integra componentes pode se especializar na correta integração das partes sem se
preocupar com os detalhes da implemetação delas.
Resumindo as vantagens :
-
Padronização
-
Manutenção
-
Reuso
4. Preciso ser membro do consórcio para enviar sugestões?
Não é preciso ser membro do consórcio para enviar sugestões. Todos podem e devem participar em qualquer ponto dos processo - quer seja enviando respostas as solictações de propostas e solicitações de informações, quer seja comentando aspectos específicos de respostas que já tiverem sido enviadas.
Os membros fundadores do CCS-SIS formam o Conselho Técnico do consórcio. Novos membros estão se inscrevendo diariamente. Favor consultar aqui.
Copyright © 1997 by UNIFESP
Centro de Informática em Saúde