Objectos Distribuidos. Engenharia Informática Instituto Superior de Engenharia do Porto

Transcrição

1 Objectos Distribuidos Siisttemas Diisttriibuiidos Engenharia Informática Instituto Superior de Engenharia do Porto Alexandre Bragança 2000/2001

2 1 Objectos Distribuidos 1.1 Desenvolvimento Cliente/Servidor usando SQL 'puro' 1.2 Groupware e Workflow 1.3 Principais vantagens dos Objectos Distribuidos 1.4 Objectos Distribuidos & Componentes 1.5 Componentes 1.6 Super Componentes 1.7 Objectos de Negócio Alexandre Bragança Pág 2

3 1 Objectos Distribuidos Um objecto distribuido é essencialmente um componente. Isto significa que é um objecto binário inteligente que pode interoperar entre sistemas operativos, redes, linguagens, aplicações, ferramentas e hardware. Os standards actuais são: COM da Microsoft CORBA da OMG 1.1 Desenvolvimento Cliente/Servidor usando SQL 'puro' Problemas no desenvolvimento cliente/servidor utilizando SQL: O SQL é pobre no que diz respeito à gestão de processos O SQL gere processos através de extensões que não são standards e através de linguagens procedimentais. Para além disto um servidor de SQL ou contém a lógica da aplicação numa 'stored procedure' ou numa ferramenta front-end para SQL (ex: Power Builder ). O middleware do SQL não é standard. O SQL não é adequado para gerir dados complexos e ricos. O SQL tende a ser encapsulado por object wrappers (Ex: OLE DB ou o serviço de persistência do CORBA). Novos dados cada vez mais vão adoptar o modelo OO através, por exemplo, das extensões OO do SQL3 ou dos OODBMS. 1.2 Groupware e Workflow O groupware consiste numa colecção de tecnologias que permite que se representem/implementem processos que se baseiam em actividades humanas de teor bastante colaborativo. Alexandre Bragança Pág 3

4 As tecnologias base de suporte são: documentos workflow escalonamento O Workflow é utilizado para de forma automática encaminhar eventos e trabalho de um elemento para outro em ambientes estrutuados ou não estruturados. Alguns workflows podem ser muito pouco estruturados enquanto outros podem ser deterministicos e muito repetitivos. O grande problema destes sistemas actualmente é que não existe um middleware standard e adequado as necessidades actuais (por exemplo é dificil que o groupware actual interligue bem com aplicações antigas 'herdadas'). Os novos sistemas/arquitecturas de objectos distribuidos são adequados para estas situações. 1.3 Principais vantagens dos Objectos Distribuidos Plug-and-play Interoperabilidade Portabilidade Coexistência Entidades auto-geridas Alexandre Bragança Pág 4

5 1.4 Objectos Distribuidos & Componentes "General industry consensus is that the ultimate goal is to have component-based systems capable of operating in distributed heterogeneous computing environments. Loosely bound and highly configurable components will be able to accommodate continous changes such as rapid creation and destruction of virtual enterprises." Richard Barnwel, Architect Software 2000, Inc. (Junho, 1995) Objectos classicos Um objecto classico (por exemplo C++ ou Smalltalk) é um blob com inteligência que encapsula código e dados. Os objectos classicos são óptimos pois permitem reutilização de código através da herança e do encapsulamento. O problema é que estes objectos classicos apenas 'vivem' num único programa. Apenas o compilador da linguagem é que sabe que estes objectos existem. O mundo exterior ao programa não sabe da existência destes objectos nem tem possibilidades de aceder a estes. Um objecto distribuido é um blob inteligente que pode 'viver' em qualquer local numa rede. Os objectos distribuidos são empacotados como pedaços de código independente que podem ser acedidos por clientes remotos através de invocação de métodos, independentemente da linguagem e compilador utilizado para criar o objecto e o cliente. Os clientes também não necessitam de saber aonde reside o objecto nem em que sistema operativo corre, pode ser no mesmo computador ou num computador do outro lado do planeta. Quando se fala de objectos distribuidos estamos a falar de componentes independentes de software. Estes compoentes podem ser utilizados em diversas redes, sistemas operativos e ferramentas de desenvolvimento. Um componente é um objecto que não está ligado a nenhum programa, linguagem ou implementação. Alexandre Bragança Pág 5

6 Assim os objectos distribuidos são os componentes base ideais para desenvolver as novas aplicações distribuidas. "Objects has to be one of the most bastardized, hackneyed, and confusing terms in the computer industry. Everyone claims to have them." Kraig Brockschmidt, Author Inside OLE 2, Second Edition (Microsoft Press, 1995) As metodologias 'tradicionais' tratam as funções e os dados de uma forma separada. As metodologias orientadas para objectos tratam as duas de uma forma integrada. Um objecto descreve tanto o comportamento como a informação associada a uma entidade. Os objectos permitem que 'empacotemos' capacidades do software em unidades mais ricas e uteis. Podemos desenvolver novos objectos à custa de outros já existentes. Eventualmente podemos chegar a criar objectos que representam entidades do 'mundo real' - normalmente designados objectos de negócio. Os conceitos básicos da tecnologia OO são os mesmos independentemente da área: Objectos distribuidos, OOP, OOD, OOA, OODBMS, etc. Os conceitos principais são: encapsulamento, herança e polimorfismo. "Um objecto é um pedaço de código que contem os chamados atributos e providencia serviços via métodos (também designados por operações ou funções). Normalmente os métodos operam em dados privados - também designados por dados de instância ou estado do objecto - que são propriedade do objecto. Uma colecção de objectos 'idênticos' constitui uma classe (também conhecida por tipo). Uma classe é como um template que descreve o comportamento de conjuntos de objectos 'idênticos'. Tecnicamente os objectos são instâncias de uma classe. Um objecto é identificado por um identificador único (também conhecido por referência)." Encapsulamento = o interior de um objecto é privado e este deve ter um interface publico que define como o mundo exterior pode interagir com este. Herança = permite criar novas classes (filhas) através de classes existentes (pais). As filhas herdam os métodos e os dados dos pais. As filhas podem acrescentar novos métodos ou redefinir métodos existente (ou método do pai não é afectado). A herança serve para extender Alexandre Bragança Pág 6

7 Polimorfismo = o mesmo método pode fazer coisas diferentes dependendo da classe que o implementa. 1.5 Componentes Ao contrário dos objectos tradicionais os componentes podem interoperar entre linguagens, ferramentas, sistemas operativos e redes. Os componentes são também fundamentalmente objectos, uma vez que suportam herança, polimorfismo e encapsulamento. Os componentes conhecidos por black box não podem ser extendidos por herança (Ex: OLE/DCOM). Um componente tipo white box é um componente que se comporta como um objecto tradicional (Ex: OpenDoc/CORBA). Porque o termo componente pode ter diferentes interpretações consideramos os seguintes pontos como características fundamentais de um componente: É uma entidade comercializável Não é uma aplicação completa Pode ser utilizada em combinações imprevisíveis Tém um interface bem especificado É um objecto interoperavel É um objecto passivel de extensão 1.6 Super Componentes Quando suporta as seguintes características temos um supercomponente Segurança Licenciamento Versões Gestão de ciclo de vida Suportar ferramentas Eventos de notificação Configuração e gestão de propriedades Scripting (~selft describing + late binding) Metadata Controlo de transacções e de acesso Alexandre Bragança Pág 7

8 Persistência Relações Facilidade de utilização Auto-teste Auto-instalável 1.7 Objectos de Negócio Finalmente podemos atingir os chamados objectos de negócio. Assim, ao nível mais baixo temos o ORB (Object Request Broker) que permite que os objectos interoperem entre espaços de endereçamento, linguagens, sistemas operativos e redes. Tambem permite que os componentes troquem metadados e que se descubram uns aos outros. A seguir na infraestrutura temos os chamados system-level services, como por exemplo, licenciamento, segurança, controlo de versões, persistência, transacções, etc. Finalmente os chamados objectos de negócio. Estes componentes modelam entidades do mundo real num determinado domínio ou área de negócio. Exemplos possíveis são: automóvel, hotel, conta bancária, etc. Alexandre Bragança Pág 8