Universidade do Minho
Conselho de Cursos de Engenharia
Licenciatura em Engenharia de Sistemas e Informática
Disciplina de Opção III
Ano Lectivo de 2004/2005Telemetria Automóvel
Emanuel Sousa, Fátima Santos, José Rodrigues
Fevereiro, 2005
Telemetria Automóvel
Emanuel Sousa, 27607, LESI
Fátima Santos, 30715, LMCC
José Rodrigues, 27626, LESI
Fevereiro, 2005
Data de Recepção
Responsável Avaliação Observações
Agradecimentos
Agradecemos ao Nuno Rodrigues, nosso orientador, por estar sempre disponível para prestar auxílio nos momentos mais difíceis de dúvidas e incertezas durante a realização deste projecto no âmbito da disciplina de Opção III – Projecto.
i
Resumo
A monitorização de veículos torna-se claramente útil na medida em que permite a um utilizador saber em cada momento o estado em que se encontra o seu veículo. É neste âmbito que surge o projecto “Telemetria Automóvel”.
Este projecto consiste na construção de um sistema capaz de monitorizar on-line o comportamento de vários dispositivos automóveis (podendo ser de diferentes marcas e funcionamentos por cada fabricante) e alertar o condutor/agência/etc. para situações de anormalidade, bem como, permitir estudos de comportamento.
Área de Aplicação: Desenho e arquitectura de Sistemas de Bases de Dados, aplicações para
Windows e Web Applications, geração dinâmica de Web Services.
Palavras-Chave: VS .NET, C#, ASP.NET, XML, SQL, Web Services, Stored Procedures,
ii
Índice
Resumo i Índice ii Índice de Figuras iv 1. Introdução 1 1.1. Contextualização 11.2. Apresentação do Caso de Estudo 1
1.3. Motivação e Objectivos 2 1.4. Estrutura do Relatório 3 2. Fundamentos Teóricos 4 2.1. Plataforma .NET 4 2.1.1 A Linguagem C# 6 2.1.2 ADO.NET 8 2.1.3 ASP.NET 10 2.2. Web Services 11 2.3. XML 12 3. Arquitectura Geral 14 3.1. Arquitectura de Suporte 14
3.2. Arquitectura do Protocolo de Comunicação 15
4. Base de Dados 17 4.1. Modelo Lógico 17 4.1.1 Entidade proprietario 17 4.1.2 Entidade contacto 18 4.1.3 Entidade veiculo 18 4.1.4 Entidade modelo 19 4.1.5 Entidade tipos_sensor 19 4.1.6 Entidade sensor_veiculo 20 4.1.7 Entidade logs 20 4.2. Stored Procedures 21 5. Middleware 23 6. Aplicações Desenvolvidas 24 6.1. Windows Application 24 6.1.1 Arquitectura 24
iii
6.1.2 Implementação – Aspectos Relevantes 24 6.2. Web Application 26
6.2.1 Arquitectura 26
6.2.2 Implementação – Aspectos Relevantes 27
7. Web Services 29
7.1. Conceito 29
7.2. Implementação 30
8. Conclusões e Trabalho Futuro 32
Bibliografia 33
Referências WWW 34
iv
Índice de Figuras
Figura 1 – Aspecto geral da arquitectura .NET 4
Figura 2 – Common Language Runtime 5
Figura 3 – Hierarquia de Namespaces 5
Figura 4 – Arquitectura do Sistema 15
Figura 5 – O sistema de comunicação 16
Figura 6 – Tabelas e suas relações 17
Figura 7 – Windows Application Main Menu 25
Figura 8 – Administração dos Contactos 25
Figura 9 – Drag’n’Drop 26
Figura 10 – Inserção dos dados 27
Figura 11 - Aspecto de uma conta pessoal 28
Figura 12 - Form de registo de veiculo. 28
Figura 13 – Aspecto do Web Service 29
Figure 14 – Web Service Generated files 30 Figure 15 – Web Service Dll file 31
1
1. Introdução
Este relatório descreve o projecto realizado no âmbito da disciplina de Opção III da Licenciatura em Engenharia de Sistemas e Informática, projecto esse que consistiu na análise do sistema de informação para suporte à monitorização à distância de veículos automóveis, respectiva modelação e implementação conforme será detalhado posteriormente.
1.1. Contextualização
Os mais recentes avanços tecnológicos no mundo do desenvolvimento de software conduziram à criação/desenvolvimento do mais variado tipo de hardware, bem como ao aparecimento de uma grande variedade de pequenos dispositivos. Com o desenvolvimento tecnológico podemos encontrar microprocessadores nos mais variados dispositivos. Hoje em dia, podemos encontrar estes aparelhos espalhados pelos mais recentes veículos automóveis, permitindo aos seus utilizadores acederem a uma panóplia de funções tais como, por exemplo, saber em que posição geográfica se encontra em dado momento.
Pensando na complexidade de um veículo e na variedade de anomalias que neste podem surgir, torna-se interessante controlar à distância o seu funcionamento recorrendo a pequenos aparelhos, sensores, capazes de monitorizar e comunicar o estado em que este se encontra, reportando esta informação para uma entidade responsável pela gestão do sistema.
É neste contexto que surge o projecto GestCar, uma ferramenta de software capaz de efectuar a gestão do sistema central, interagir com os dispositivos instalados nos veículos, podendo estes a qualquer momento comunicar eventuais anomalias. Neste sistema, é ainda possível, os utilizadores efectuarem a gestão da sua conta pessoal on-line.
1.2. Apresentação do Caso de Estudo
Com vista a desenvolver um sistema capaz de monitorizar on-line o comportamento de vários dispositivos automóveis, através da utilização de sensores instalados nos mesmos, surge todo o carácter do projecto Telemetria Automóvel.
Este sistema, o qual designamos de GestCar, deverá ser capaz de receber e tratar diversa informação proveniente dos veículos, bem como, alertar o condutor/agência para situações de eventuais anomalias, para além de permitir realizar estudos de comportamento.
2
1.3. Motivação e Objectivos
O impacto causado pelas novas tecnologias não foi indiferente ao grupo de desenvolvimento deste projecto. Visto esta ser uma tarefa com carácter inovador, e dado o interesse de aprendizagem de novas plataformas de desenvolvimento de software, tornou-se factor decisivo na escolha deste projecto.
Assim, com este trabalho era pretendido a integração e o contacto com algumas das linguagens actualmente em voga no mundo informático.
Outro factor relevante na escolha deste projecto foi a possível aplicabilidade deste sistema a dispositivos móveis, tais como, telemóveis, pda’s, entre outros que tanto interesse despertam.
A criação de um protocolo genérico de comunicação entre dispositivos era um dos objectivos principais deste projecto. Neste protocolo constariam dois tipos de intervenientes principais, um de carácter central e outro móvel. Os elementos móveis seriam todo o tipo de dispositivos com alguma capacidade de computação, tais como, telemóveis, pocket PC’s, smart
phones, pagers, PDA’s, entre outros. O outro interveniente seria uma central capaz de
comunicar com vários destes dispositivos em simultâneo
Dado as limitações destes dispositivos móveis em termos de capacidade de armazenamento e computação, e dadas as limitações em termos de comunicação entre os dois elementos, seria necessário minimizar ao máximo o limite de dados a transferir entre os dispositivos.
Quando um elemento móvel necessitasse de interagir com uma central enviar-lhe-ia um cartão de visita onde constariam todos os dados relevantes para futuras comunicações, ficando à espera da resposta ao seu pedido, com time-outs específicos assegurando caso haja alguma falha na comunicação. Depois de recebido o pedido, a central submete-o ao sistema, reprogramando-se para futuras chamadas, sendo enviado a resposta de confirmação com a informação necessária para novos contactos. Esta informação seria armazenada no dispositivo e se por algum motivo esta se perdesse, o processo descrito seria reiterado.
Depois destes passos, uma de duas possíveis realidades poderiam ocorrer. Ou a aplicação do dispositivo solícita (ou simplesmente recupera) a informação como concluída uma interacção com a central, e depois o processo itera novamente para voltar a começar; ou precisam de manter a interacção com a central, e o dispositivo móvel continuará interagindo com a central.
Visto tratar-se de um trabalho académico tal protocolo teve de ser minimizado. Neste caso concreto de estudo considerou-se como dispositivos móveis apenas sensores que estariam instalados em veículos automóveis que comunicariam com a central, através de Web Services, com será tratado com mais detalhe nas próximas secções.
3
1.4. Estrutura do Relatório
Nos demais capítulos apresentaremos a aplicação desenvolvida focando os aspectos que foram mencionados no resumo.
Neste capítulo fez-se uma ligeira introdução aos conceitos abordados durante o projecto, que pensamos ser relevante para uma total percepção do ambiente em redor da arquitectura GestCar desenvolvida.
No capítulo 2, é feita uma fundamentação teórica a todos os conceitos envolvidos na realização do projecto.
De seguida, no capítulo 3, é apresentada a arquitectura de suporte do sistema, bem como a arquitectura do protocolo de comunicação.
O capítulo 4 destina-se a apresentar o modelo funcional da base de dados. Para isso, explica-se detalhadamente as tabelas constituintes da base de dados, bem como o seu propósito de utilização e aborda-se os Stored Procedures utilizados.
O capítulo seguinte apresenta a funcionalidade da Middleware neste projecto, bem como uma descrição pormenorizada da mesma.
O capítulo 6 é reservado à apresentação de todas as aplicações desenvolvidas, focando a sua arquitectura e os aspectos relevantes da implementação.
No capítulo 7 são explicados os Web Services, a sua importância no âmbito de desenvolvimento do nosso projecto e é referida ainda a sua implementação.
Por fim o último capítulo destina-se à conclusão e proposta para um possível trabalho futuro.
4
2. Fundamentos Teóricos
2.1. Plataforma .NET
É difícil poder resumir em breves palavras o conceito da plataforma de desenvolvimento de serviços web .NET, mas, de forma algo grosseira, pode-se dizer que é uma plataforma revolucionária, que utiliza protocolos e normas abertas da Internet, e inclui ferramentas e serviços que impulsionam a computação e as comunicações para novos caminhos.
Uma definição mais prática seria que constitui um novo ambiente para desenvolvimento e execução de aplicações, caracterizando-se pela facilidade de desenvolvimento dos serviços
web, a disponibilidade dos serviços de execução padrão de uma variedade de linguagens de
programação, e pela interoperabilidade entre linguagens e sistemas operativos.
A figura que se segue apresenta diversos níveis de abstracção, situando-se nos níveis superiores as linguagens presentes do .NET e, no nível inferior, o sistema operativo.
5
A plataforma .NET é um ambiente de execução, CLR (Common Language Runtime) (Figura 1), e uma plataforma de desenvolvimento, base class library [Figura 2], isto é, um conjunto de classes base sobre a qual se desenvolve.
Figura 2 – Common Language Runtime
As classes da biblioteca base do .NET estão organizadas em namespaces [Figura 3]. Um
namespace é um “espaço de nomes”, ou seja, um contexto de identificação de tipos que
permite organizar o código de forma estruturada (hierárquica) e agrupar logicamente tipos relacionados. Os namespaces são por isso, uma técnica de organizar o código e evitar conflito de nomes.
6
2.1.1 A Linguagem C#
A linguagem C# é a linguagem mais usada no âmbito da plataforma .NET e vai ser utilizada no desenvolvimento do caso de estudo.
O C# é uma linguagem de programação desenvolvida pela Microsoft, baseada em C/C++, e que tem fortes semelhanças com o Java. A Microsoft descreve o C# desta forma:
“C# é uma linguagem simples, moderna, orientada a objectos e segura, derivada do C e do C++. C# (pronuncia-se ‘C sharp') está firmemente implantada na árvore da família do C/C++ e é familiar aos programadores destas duas linguagens. O C# tem por objectivo combinar a alta produtividade e simplicidade do Visual Basic com o potencial do C++”.
O principal objectivo na concepção do C# foi a simplicidade em detrimento da “força bruta”. Esta linguagem permite, de um modo geral, tornar o código mais estável e produtivo.
As principais vantagens desta linguagem são:
Simplicidade: Tudo nesta linguagem, por motivos de simplicidade, é representado por um ‘.’. Quer estejamos perante classes, referências ou qualquer outro tipo de dados, não é necessário preocuparmo-nos com o operador a usar. Outro exemplo de simplicidade prende-se com o tipo de dados a usar. Em C#, um caracter unicode não é mais um wchar_t , mas sim um char como acontecia no C++. Assim, acaba-se com os tipos unsigned char ,
signed char e o wchar_t . Uma terceira prova de simplicidade consiste no facto dos inteiros
não serem usados como booleanos, evitando confusões aquando da utilização dos operadores = e ==. Para tal, o C# separa claramente estes 2 tipos de dados, existindo um tipo de dados bool, que apenas podem assumir os valores true ou false e não podem ser convertidos em nenhum outro tipo de dados.
Consistência: O C# unifica o sistema de tipos fornecendo uma visão de todos os tipos na linguagem como um objecto. Quer estejamos a utilizar uma classe, uma estrutura, um vector ou uma primitiva, temos a possibilidade de tratarmos cada um deles como um objecto. Isto quer dizer que em vez de colocarmos os conhecidos includes do C (includes de sistema – stdlib.h, stdio.h e string.h ) usamos simplesmente uma declaração que nos dá acesso a todos os objectos e classes contidos nele: using System.
Modernidade: Um bom exemplo de modernidade, consiste por exemplo, no mecanismo de garbage collection (colecção de lixo) implementado. Tudo o que não se encontra referenciado é automaticamente removido. Contudo, este tipo de funcionamento tem um preço. Causa problemas em alguns comportamentos de risco (como o caso de
casts não seguros e apontadores estáticos) tornando mais penoso descobrir o erro e
7
implementa tipos de dados seguros para garantir a estabilidade da aplicação. É óbvio que este tipo de dados torna o código mais legível, permitindo que terceiros possam compreender mais facilmente o programa.
Orientação aos objectos: Modelo de orientação a objectos baseado em herança simples de classes com um ancestral comum.
Em C#, as propriedades do encapsulamento, polimorfismo e herança são preservadas. O C# termina com o conceito de funções globais, variáveis e constantes. Em vez disso, podemos criar membros de classes estáticas, fazendo o código C# fácil de ler e menos propenso a conflitos de nomes. Para resolver o problema de se redefinir várias vezes a mesma classe no mesmo código, os métodos na linguagem C# são, por omissão, não-virtuais, requerendo um modificador explícito virtual. Torna-se, por isso, muito mais complicado reescrever um método acidentalmente, sendo fácil disponibilizar versões corrigidas. As classes em C# podem ser definidas como private, protected, public ou
internal. É o programador quem retém o controlo absoluto do encapsulamento do código.
Escalabilidade: O C# está livre das combinações frequentes entre a declaração e a definição dos tipos de dados.
Quando um projecto se torna demasiado grande, normalmente, divide-se o código fonte em ficheiros mais pequenos. Em C#, quando se compila um projecto, é equivalente a proceder à compilação do ficheiro que resulta da concatenação do conjunto de ficheiros fonte do projecto. Não há preocupações com a localização dos cabeçalhos ou das rotinas, o que significa que podemos mover, renomear, dividir ou juntar ficheiros fonte sem parar a compilação.
Suporte de Versão: O C# foi desenvolvido para tornar a actualização de versões mais fácil, retendo a compatibilidade binária com as classes derivadas já existentes.
Quando é introduzido um novo “membro” na classe base que é igual a outro já existente numa classe derivada, não resulta qualquer erro. Contudo, deve-se ter em atenção que a classe deve indicar que o novo método se refere a uma reescrita ou a um novo método que apenas esconde o método anterior.
Compatibilidade: Esta compatibilidade deve-se ao facto da linguagem C# suportar as quatro APIs mais comuns do Windows. Essencialmente, prende-se com a exportação de entidades como por exemplo, as DLLs. Desta forma, torna-se mais fácil a implementação de interfaces através da criação de objectos que sejam uma representação das mesmas.
Flexibilidade: É verdade que o C# e o COM+ criam um ambiente de tipos de dados livres e de gestão. Contudo, também é verdade que algumas das aplicações do mundo real necessitam de “descer “ ao código nativo (código máquina) – por questões de desempenho
8
ou para usarem APIs mais antigas de outros programas. O C# permite a declaração não segura das classes e dos métodos que contêm apontadores, estruturas e vectores estáticos. Esses métodos não serão type-safe mas vão executar dentro do espaço de gestão e, não existindo, por esta razão, necessidade de impor fronteiras entre código seguro e não seguro.
Unificação do sistema de tipos: Em C# todos os valores podem ser atribuídos a uma variável do tipo object.
Os recursos acima fazem do C# uma linguagem fácil de aprender e de usar, robusta e com boa performance. Em conjunto com os demais recursos da arquitetura .NET, o C# é a linguagem ideal para a criação de uma nova categoria de programas que aproveitam as oportunidades trazidas pela Internet.
2.1.2 ADO.NET
Para o acesso à base de dados a plataforma .NET disponiliza o ADO.NET, este fornece um acesso consistente a fontes de dados, como por exemplo o SQL Server, assim como a outras fontes acessíveis via OLE DB, XML ou ODBC. As aplicações podem utilizar o ADO.NET para estabelecer ligações a essas fontes de dados de modo a recuperar, manipular e actualizar dados.
Os resultados obtidos através da execução de um comando através do ADO.NET podem ser processados directamente ou colocados num objecto ADO.NET DataSet. Este tipo de objecto permite efectuar um conjunto de operações tais como combinar dados de múltiplas fontes, estabelecer relações entre tabelas, manipular como um conjunto a estrutura da informação, entre outras funcionalidades.
As classes para trabalhar com o ADO.NET estão no System.Data.xxxx, em que xxxx refere-se à especialização do fornecedor de acesso aos dados (Exemplos de fornecedores: SQL Server .Net Data Provider, OLE DB .Net Data Provider, ODBC .Net Data Provider e outros), ou seja a utilização dos objectos do ADO.NET implica uma importação dos
Namespaces System.Data, System.Data.SqlClient e/ou System.Data.OleDbClient.
O ADO.NET foi criado para trabalhar com colecções de dados desconectados – o que resultará em menos tráfego – e utiliza o XML como formato de transmissão de dados, garantindo à partida a interoperabilidade. O modelo de objectos do ADO.NET evoluiu do modelo disponibilizado pelo ADO, o que se reflecte na existência de alguns objectos comuns (Connection e Command), mas surgem agora no ADO.NET outros objectos totalmente novos (DataReader, DataSet, DataView, DataAdapter).
9 Objectos Connection
Estes objectos irão efectuar a comunicação com a base de dados e continuam a ter propriedades como Data Source, userID, password, etc. Existem dois tipos de objectos nesta categoria: SqlConnection e OleDbConnection. Um deles será utilizado sempre que queiramos aceder a uma base de dados SQL e o outro para aceder a todas as outras, respectivamente.
Objectos Command
Contêm a informação para submeter à base de dados. Um comando pode ser uma chamada a uma Stored Procedure, uma instrução de actualização ou uma instrução que devolverá um conjunto de dados. Existem dois tipos de comandos: SqlCommand e
OleDbCommand.
Objectos DataReader
Estes novos objectos permitem-nos obter uma colecção de dados read only (só de leitura) e forward only (que apenas permite uma navegação simples do primeiro registo ao último elemento, sem possibilidade de retorno ao registo anterior). Esta técnica, bastante leve ao nível do consumo de recursos, será a indicada se pretendermos apenas preencher uma tabela ou mostrar a informação recolhida numa página Web.
Estes objectos são preenchidos após a execução de um comando à base de dados. Aqui existem também dois tipos de DataReaders: SqlDataReader e OleDbDataReader.
Objectos DataSet
Estes objectos representam uma cache de dados com um comportamento similar a uma base de dados. Contêm tipicamente tabelas, colunas, constrangimentos, relações e dados. Estes objectos contêm uma colecção interna de DataTables. A estrutura de um DataSet é sempre genérica, independentemente de ser o resultado de uma interacção com o SQL ou com um OLEDB. A sua implementação é feita através de uma arquitectura de dados desconectados, ao contrário dos DataReaders. O preenchimento destes DataSets é feito através da utilização de um método (Fill) de um outro objecto, o SqlDataAdapter ou
OleDbDataAdapter.
Objectos DataView
O DataView fornece-nos uma view de uma tabela. Podemos considerar um DataView como o equivalente a um RecordSet desconectado. Este tipo de objecto aparecerá sempre associado a uma tabela interna de um DataSet.
Objectos DataAdapter
Este é o último tipo de objecto necessário para manipular dados no ADO.NET. De facto, enquanto os DataSets nos permitem manter em memória informação para a manipulação, os
10
tipo de objecto também existe em dois formatos possíveis: SqlDataAdapter e
OleDbDataAdapter.
Concluindo, o ADO.NET disponibiliza todo um conjunto de classes para trabalhar o acesso às bases de dados.
2.1.3 ASP.NET
ASP.NET é a mais nova tecnologia da Microsoft para aplicações Web, com recursos extremamente poderosos, permitindo o desenvolvimento de aplicações com facilidade e rapidez.
O ASP.NET é uma versão melhorada do ASP (Active Server Pages). Trata-se de uma tecnologia de scripting que funciona do lado do servidor, isto é permite que scripts embebidos nas páginas web sejam executados por um servidor web.
Quando um navegador requer um ficheiro HTML, o servidor retorna o ficheiro. No entanto, quando o navegador requer um ficheiro ASP, o servidor transmite esse pedido ao compilador de ASP, que, por sua vez, lê o ficheiro linha a linha e executa os scripts ASP existentes no ficheiro. Seguidamente, o ficheiro resultante, que é um documento HTML, é retornado para o navegador do utilizador.
Quando se trata de aceder a bases de dados, é esta tecnologia ASP.NET, que é a responsável por comunicar com o servidor de base de dados e retornar a resposta ao pedido feito pelo cliente com os dados solicitados.
Funciona em parceria com o ADO.NET e como tal, possui componentes baseados em XML, tornando-se muito versátil para a prestação de serviços web. Uma grande vantagem do ASP.NET é o facto de usar código compilado e não código interpretado, resultando daí uma maior rapidez de execução. Após a página ter sido requisitada, a framework verifica se esta já foi compilada e, caso não tenha sido, compila só a primeira vez. Sendo assim, nas próximas requisições a página não será compilada, tornando a execução mais rápida.
No ASP.NET tem-se presente o modelo de programação Code Behind permitindo uma total separação do HTML e código, facilitando muito a vida ao programador.
Para o desenvolvimento de todo este projecto foi usado ambiente de trabalho Visual Studio
.NET 2003. Revelou-se interessante, uma vez que este foi o primeiro contacto que tivemos
com estas novas ferramentas. Assim numa primeira fase, a dificuldade de abordar todo um novo grupo de conceitos foi uma barreira que tivemos de ultrapassar.
O projecto foi desenvolvido na linguagem C#, o acesso ás bases de dados recorreu-se a primitivas do ADO.NET e para a implementação da aplicação Web foi utilizada a tecnologia ASP.NET. Todos estes componentes, foram já descritos neste capítulo, uma vez que foram objecto da nossa aprendizagem e investigação ao longo do projecto.
11
2.2. Web Services
Um Web Service pode ser entendido como um Serviço disponível na web que pode ser acedido/utilizado a partir dos protocolos standard.
Web Services são uma maneira padronizada de integrar aplicações baseadas na Web
usando XML, SOAP, WSDL e UDDI padrões sobre um sistema de comunicação que utiliza protocolo Internet. Os Web Services permitem que aplicações diferentes de diversas fontes se comuniquem umas como as outras sem codificações complexas e sem vínculo com qualquer sistema operacional ou linguagem, uma vez que a comunicação ocorre em XML.
Mas expliquemos então melhor estes três conceitos essenciais na arquitectura Web Services:
SOAP- Simple Object Access Protocol
SOAP é o protocolo de comunicação standard para os XML Web Services. Procurando simplificar, podemos dizer que o SOAP é a especificação que define o formato de XML para as mensagens.
Quem começa a utilizar este protocolo confronta-se desde logo com o problema de ter de distinguir a especificação SOAP das suas muitas implementações. Efectivamente, a maioria dos utilizadores de SOAP não escreve as suas mensagens SOAP directamente, limitando-se a utilizar uma ferramenta própria (Microsoft SOAP ToolKit ou Apache ToolKit, por exemplo) para criar e efectuar o parse das suas mensagens SOAP.
Provavelmente a maior vantagem da utilização do SOAP deriva do facto de este protocolo ter sido implementado em muitas plataformas de software e hardware, o que permite que o SOAP seja utilizado para implementar a comunicação entre sistemas diferentes dentro e fora de uma organização.
Uma das razões explicativas para este relativo sucesso tem a ver com a simplicidade. Com efeito, o SOAP revela-se um protocolo muito mais simples e fácil de implementar do que os seus antecessores. O DCE e o CORBA, por exemplo, demoravam anos a implementar, o que se reflecte no pequeno número de versões implementadas que foram disponibilizadas. Já uma implementação do SOAP é um processo muito mais célere, visto que utiliza os parsers de XML existentes e as bibliotecas de HTTP para realizar grande parte do trabalho. Desta forma, o processo de criar uma implementação SOAP poderá ser concluído em poucos meses.
O compromisso que estabelece entre a simplicidade e a funcionalidade é uma das razões do seu êxito.
WSDL - Web Services Description Language
Para facilitar a compreensão do WSDL, podemos afirmar que um ficheiro WSDL é representado por um documento XML que descreve uma série de mensagens SOAP e a forma como funciona a troca/comunicação dessas mensagens. Por outras palavras, o WSDL está para o SOAP como o IDL está para o CORBA ou para o COM.
12
Para mais facilmente aprendermos as vantagens de utilização do WSDL, imaginemos a seguinte situação: necessitamos de passar a utilizar um método SOAP disponibilizado por um dos nossos parceiros. Obviamente, podemos solicitar ao parceiro um exemplo da mensagem SOAP usada na comunicação e, em seguida, utilizar esse exemplo para produzir uma aplicação que utilize e consuma mensagens com o formato disponibilizado. Esta abordagem, no entanto, poderia gerar alguns erros – por exemplo, poderíamos reconhecer na mensagem um atributo ClientID, que teria um valor de 1234 e determinar que esse valor seria do tipo Inteiro quando, na realidade, ele é do tipo String. O WSDL define de forma extremamente clara que tipo e que estrutura de dados (e não só) a mensagem SOAP utiliza, inviabilizando assim a ocorrência de erros de interpretação como o anterior.
Além de descrever o conteúdo das mensagens, o WSDL define também o endereço onde o serviço está disponível e o protocolo que terá de ser utilizado para comunicar com o serviço. Desta forma, o WSDL possui literalmente toda a informação necessária para criar um programa que interaja com o Web Service.
UDDI - Universal Discovery Description Language
O UDDI funciona como as páginas amarelas dos Web Services. Nele podemos procurar empresas que disponibilizem os serviços de que necessitamos, aceder a informação acerca do serviço oferecido e até contactar alguém que nos possa fornecer mais informação.
É evidente que o registo de um Web Service no UDDI não é um procedimento obrigatório. Com efeito, podemos criar os nossos Web Services e não os registar no UDDI. No entanto, se pretendermos atingir um mercado mais extenso, necessitamos do UDDI para que os nossos potenciais clientes nos possam encontrar.
Cada entrada num directório UDDI é um ficheiro XML que descreve uma empresa e os serviços que esta disponibiliza. Existem três partes numa entrada do UDDI: a primeira, conhecida como White Pages, descreve a companhia que oferece o serviço (nome, endereço, contactos, etc.); a segunda, denominada Yellow Pages, inclui categorias industriais baseadas em taxinomias estandardizadas como o NAICS (North American Industry Classification System) e o SIS (Standard Industrial Classification); finalmente a terceira entrada, designada Green
Pages, descreve a interface para o serviço, com um nível de detalhe que permite a qualquer
programador desenvolver uma aplicação que possa usar esse serviço.
2.3. XML
A eXtended Markup Language é um standard que descreve ou codifica a estrutura e conteúdo de informação legível por máquinas.
Foi criada para que, documentos massivamente estruturados pudessem ser usados na
Web, não deixando de ser no entanto, um novo formato de dados universal.
O XML descreve o conteúdo e a estrutura lógica de como o conteúdo se deve agregar, mas não a maneira como é representada (ex.: como aparece num browser).
13
A flexibilidade do XML provém da possibilidade de transportar qualquer tipo de dados (e mantê-los estruturalmente coesos e inteligíveis), como binários ou memo fields por meio da sua estrutura declaradamente markup (<tag>value</tag>). É também assim possível, combinar num mesmo documento, vários objectos com tipos de dados diferentes.
Em traços largos, poder-se-á dizer que o XML fornece informação sobre um conteúdo comum HTML, sendo uma metalinguagem uma linguagem com descrição de linguagem.
É portanto uma eXtensão ao HTML mas, tendo como trunfo não ter um conjunto de <html
tags> específico mas dinâmico, derivando directamente da complexa SGML (Standard Generalized ML) e propondo uma descrição, em termos de meta-dados dos dados que formam
o conteúdo de um documento.
Se bem que tenhamos a tendência de associar e de comparar o XML com a função delegada ao HTML actualmente, como formato de dados na Web, o XML, como formato de dados universal que se quer, ultrapassa largamente o âmbito dos browsers, podendo ter implicações bem mais globais. Assim, exemplos de documentos XML podem ser transacções de e-commerce, grafismos vectoriais, equações matemáticas, API's de servidores, objectos de meta-data e virtualmente, tudo o que tenha representação estruturada.
A grande maioria dos documentos XML devem obedecer a um formato predefinido para serem processados automaticamente por aplicações informáticas.
Esse formato pode ser definido numa linguagem chamada Document Type Definition ou DTD, mas esta linguagem tem várias lacunas importantes, como não serem eles próprios documento XML e ausência de tipo de dados. Por esse motivo foi proposto pelo W3C uma nova linguagem chamada Scheme Definition Language (ou simplesmente Schema) para descrever o formato de documentos XML e cujos ficheiros normalmente utilizam a extensão XSD. Esta linguagem não só está definida ela própria em XML como inclui um conjunto de tipos de dados básicos (inteiro, byte, real, etc.), inclui dados especializados para a Internet (por exemplo, códigos de países e línguas), define tipos de dados complexos, entre outros.
Os documentos XML diz-se válidos se forem bem definidos e cumprirem exactamente as declarações dum Schema ou DTD. Para tal é necessário validar o documento, ou seja analisar se o conteúdo e a estrutura do documento obedecem realmente ao Schema referenciado.
14
3. Arquitectura Geral
3.1. Arquitectura de Suporte
Arquitecturalmente, a solução em Software (GestCar), encontra-se dividida fundamentalmente em 3 camadas;
• Base de Dados; • MiddleWare;
• Aplicações (Windows Application, Web Application, Web Services);
A base de dados é a camada do nível mais baixo onde se encontram todas as tabelas relevantes para solucionar o problema e ainda os Stored Procedures responsáveis pela interacção com a base de dados e com os restantes níveis da arquitectura. Os Stored
Procedures são usados para encapsular um conjunto de queries que posteriormente serão
executadas num servidor de base de dados. Tal facto torna-se muito interessante na medida em que permite isolar da camada de Middleware as operações de gestão da base de dados.
Seguidamente, temos o nível do MiddleWare, camada responsável pelos acessos à base de dados. Nesta encontram-se disponíveis os principais métodos de comunicação da base de dados com as diferentes aplicações. Quando uma camada superior pretende fazer alguma operação envolvendo a base de dados, tal tarefa é dirigida a esta camada, usando-se um desses métodos que por sua vez acederá à base de dados requerendo o que lhe foi solicitado, sendo posteriormente devolvida a resposta ao nível superior. Esta camada permite ao nível aplicacional abstrair-se dos detalhes de acesso a base de dados permitindo reduzir a complexidade e as preocupações dos níveis superiores. Se uma nova aplicação tiver de ser desenvolvida, usando esta camada poderá reaproveitar trabalho que já feito.
Estes dois níveis, bem como a comunicação entre eles, são imperceptíveis aos utilizadores do sistema. Estes interagem com uma camada posicionada no nível acima destas. Nessa camada encontram-se diferentes aplicações: uma Windows Application para ser usada na central e com o objectivo de administrar a base de dados; uma Web Application onde os utilizadores registados podem consultar toda a comunicação referente aos seus dispositivos e um Web Service para comunicação entre dispositivos.
15
Figura 4 – Arquitectura do Sistema
3.2. Arquitectura do Protocolo de Comunicação
O protocolo de comunicação ocorre em dois tipos cenários diferentes, um de carácter móvel e o outro com carácter estático (central). Os elementos de tipo móvel correspondem a dispositivos (sensores) limitados em termos de comunicação e capacidade de armazenamento. Estes dispositivos são identificados por um código e somente capazes de comunicar com a central enquanto que esta poderá comunicar com vários dispositivos diferentes em simultâneo.
Quando um dispositivo móvel necessita de contactar uma central específica para iniciar a interacção com esta, envia-lhe um cartão de visita. Este cartão pode ter formatos diferentes consoante o tipo de sensor e contexto de comunicação, mas todos terão campos obrigatórios, tais como, a sua identificação, o endereço de resposta, o número e tipo de campos a serem enviados. Esta comunicação inicial é efectuada com intervenção humana para fazer chegar à central o protocolo de comunicação associado ao dispositivo. O cartão de visita será um ficheiro XML onde é descrita toda a informação relativa ao sensor e necessária para iniciar futuras comunicações com a central.
Após entregue o cartão de visita, na central é submetido o ficheiro ao sistema, sendo analisado, ou seja, é verificado se o ficheiro XML é valido. Após a validação do ficheiro, caso este esteja de acordo com o formato imposto pelo Schema, será analisado sendo gerado Web
Services prontos a receber informação relevante para futuras chamadas desse tipo de
dispositivo.
Depois de completos estes passos, o sensor poderá enviar o sinal para a central através do Web Service pronto para estabelecer a comunicação.
O processo de comunicação é ilustrado na figura que se segue:
16
17
4. Base de Dados
4.1. Modelo Lógico
Após uma análise detalhada do caso de estudo chegamos ao seguinte modelo conceptual:
Figura 6 – Tabelas e suas relações
Como se pode observar, este modelo é constituído pelas seguintes entidades:
4.1.1 Entidade proprietario
proprietario = {cod_proprietario, bi, nome, data_nasc, rua, localidade, cod_postal, email, login, password}
Esta entidade contempla a informação referente aos proprietários dos veículos. Nesta constam os seguintes atributos:
18
cod_proprietario – chave primária na tabela proprietario é do tipo numeric 9 e refere-se ao código atribuído automaticamente ao utilizador, sendo este único.
bi – o seu tipo é numeric 9 e representa a informação referente ao número do bilhete de
identidade do proprietário.
nome – do tipo varchar 50 atributo representativo do nome do proprietário.
data_nasc – é do tipo char 10 e tal como o nome sugere é neste atributo que se guarda a data
de nascimento do proprietário.
rua – do tipo varchar 50 e serve para guardar o nome da rua onde habita o proprietário. localidade – do tipo char 20 sendo aqui guardada a localidade.
cod_postal – do tipo char 10 armazenamos neste atributo o código postal.
email – do tipo char 30 tal como o nome deste atributo indica aqui é armazenado o endereço
de correio electrónico de cada proprietário.
login – do tipo char 10 campo referente ao nome de utilizador.
password – do tipo char 10 atributo representativo da password de cada proprietário.
4.1.2 Entidade contacto
contacto = {codigo, telefone, cod_proprietario}
A entidade contacto foi criada com o objectivo de armazenar os dados referentes ao contacto de cada proprietário, sendo constituída pelos seguintes atributos:
codigo – chave primária da tabela contacto, o seu tipo é numeric 9 e corresponde ao código do contacto, sendo como é obvio único.
telefone – é do tipo varchar 15 e é neste campo que se guarda o numero de telefone do
proprietário.
cod_proprietario – chave primária na tabela proprietário e chave estrangeira na tabela contacto. É através deste atributo que se relaciona a tabela contacto com a tabela proprietário.
4.1.3 Entidade veiculo
veiculo = {cod_veiculo, matricula, marca, cor, cod_modelo, cod_proprietario}
Esta entidade tem como função armazenar as informações referentes aos veículos e é constituída pelos seguintes atributos:
19
cod_veiculo – chave primária nesta tabela, do tipo numeric 9 e tal como o nome indica serve
para guardar o código do veiculo sendo este único.
matricula – é do tipo char 8 e representa a matricula de cada veiculo. marca – sendo do tipo char 15 representa a marca de cada veiculo.
cor – como o nome sugere é o atributo correspondente à cor do veiculo e é do tipo char 10. cod_modelo – descrito anteriormente sendo nesta tabela chave estrangeira que permite
relacionar o veiculo com o modelo.
cod_proprietario – descrito também anteriormente sendo chave estrangeira nesta tabela e
permitindo relacionar o veiculo com o seu proprietário.
4.1.4 Entidade modelo
modelo = {cod_modelo, designacao, tipo_combustivel, cilindrada, potencia, n_portas, n_lugares}
A entidade modelo permite representar toda a informação relevante de um dado veículo, sendo constituída pelos seguintes atributos:
cod_modelo – chave primária nesta tabela, do tipo numeric 9 representa o código do modelo,
gerada automaticamente e única.
designação – do tipo char 30 representa uma breve descrição do modelo em causa.
tipo_combustivel – tal como o nome indica serve para representar o tipo de combustível
usado por determinado modelo e é do tipo char 10.
cilindrada – do tipo int 4 representa em cm3 a cilindrada do veiculo.
potencia – neste atributo é representada a potencia do veiculo sendo do tipo char 10.
n_portas – serve para armazenar a informação relativa ao numero de portas do veículo sendo
do tipo int 4.
n_lugares – indica o numero de lugares do veiculo e é do tipo int 4.
4.1.5 Entidade tipos_sensor
tipos_sensor = {código, designacao_tipo}
20
codigo – chave primária nesta tabela, representa o código do sensor e é do tipo (char 10). designacao_tipo – do tipo varchar 50 representa uma breve descrição do sensor em causa.
4.1.6 Entidade sensor_veiculo
sensor_veiculo = {cod_sensor, cod_tipo_sensor, fabricante, nserie, cod_veiculo}
A entidade sensor_veiculo é responsável por armazenar os dados de determinado sensor associado a dado veiculo.
cod_sensor – chave primária nesta tabela e serve para indicar o código do sensor, sendo este
obviamente único. É do tipo numeric 9.
cod_tipo_sensor – é chave estrangeira nesta tabela e chave primária na tabela tipos_sensor.
fabricante – é do tipo char 10 e guarda o nome do fabricante do sensor. nserie – do tipo char 25 armazena o número de série do sensor.
cod_veiculo – já descrito acima.
4.1.7 Entidade logs
logs = {cod_log, data, hora, cod_sensor, mensagem}
Esta entidade é responsável por armazenar os dados das chamadas ao sistema feitas pelos diversos sensores.
cod_log – chave primária indicando o código da chamada ao sistema feita por um dado
sensor. É do tipo numeric 9.
data – é um atributo que onde é armazenada a data em que foi efectuado o log.É do tipo char
10.
hora – do tipo char 10 e guarda a hora em que o sensor enviou os campos ao sistema. É do
tipo char 10.
cod_sensor – indica a o código do sensor que enviou a mensagem,e é chave estrangeira
nesta tabela. É do tipo numeric 9.
21
4.2. Stored Procedures
Stored Procedures são um grupo de instruções em SQL que formam uma unidade lógica e
destinam-se a executar uma tarefa particular. Especificamente estes procedimentos são usados para encapsular um conjunto de queries para serem executadas num servidor de base de dados. Tal facto permite-nos obter:
Facilidade de manutenção devido à modularidade. Quando se pretende alterar uma tarefa só é necessário alterar o procedimento não sendo preciso modificar o código que o chama;
Uma execução mais rápida do que se usássemos instruções SQL, visto que após a primeira execução estas encontram-se armazenadas na memória do servidor de base de dados enquanto que se não lá estivessem teriam de ser analisadas a cada chamada; Diminuição do tráfego de comunicação visto não ser necessário enviar instruções SQL para o servidor, uma vez que estas se encontram armazenados na base de dados;
Segurança dos dados mais robusta dado ser possível atribuir permissões aos utilizadores.
Como se pretende aplicações com bom desempenho, foram definimos vários stored
procedures que facultem as operações básicas sobre a base de dados. Estas operações
reúnem-se em quatro grupos (CRUD – Create, Read, Update, Delete): criação, consulta, alteração e remoção de informação na base de dados. Assim, apenas uma invocação ao
stored procedure é suficiente para a execução da querie à base de dados.
Visto estes serem muito idênticos, diferenciando-se apenas nas variáveis, apresenta-se um exemplo de cada uma das operações, previamente citadas, para a tabela veiculo:
• Criação
CREATE PROCEDURE criaVeiculo @matricula char(8), @marca char(15), @cor char(10), @cod_modelo int, @cod_proprietario int AS
INSERT INTO veiculo
( matricula, marca, cor, cod_modelo, cod_proprietario)
VALUES (@matricula, @marca, @cor, @cod_modelo, @cod_proprietario) GO
• Consulta
CREATE PROCEDURE leVeiculo @cod_veiculo int AS
SELECT cod_veiculo, matricula, marca, cor, cod_modelo, cod_proprietario
FROM veiculo
WHERE cod_veiculo = @cod_veiculo GO
22
• Alteração
CREATE PROCEDURE alteraVeiculo @cod_veiculo int, @matricula char(8), @marca char(15), @cor char(10), @cod_modelo int, @cod_proprietario int, @newMatricula char(8), @newMarca char(15), @newCor char(10), @newCod_modelo int, @newCod_proprietario int AS UPDATE veiculo SET
matricula = @newMatricula, marca = @newMarca, cor = @newCor, cod_modelo = @newCod_modelo, cod_proprietario = @newCod_proprietario WHERE
cod_veiculo = @cod_veiculo AND matricula = @matricula AND marca = @marca AND
cor = @cor AND
cod_modelo = @cod_modelo AND
cod_proprietario = @cod_proprietario GO
• Remoção
CREATE PROCEDURE apagaVeiculo @cod_veiculo int, @matricula char(8), @marca char(15), @cor char(10), @cod_modelo int, @cod_proprietario int AS
DELETE FROM veiculo WHERE cod_veiculo = @cod_veiculo AND matricula = @matricula AND marca = @marca AND
cor = @cor AND
cod_modelo = @cod_modelo AND
cod_proprietario = @cod_proprietario GO
23
5. Middleware
Na última década, diversas tecnologias de Middleware foram desenvolvidas com o objectivo de facilitar o desenvolvimento de aplicações, abstraindo detalhes de comunicação, chamadas de procedimentos e métodos, nomes e localização.
O termo Middleware representa uma camada intermédia, tendo como objectivo abstrair a heterogeneidade existente da comunicação, e caracteriza uma camada de software que possibilita comunicação entre aplicaçoes tendo por objectivo diminuir a complexidade e heterogeneidade dos diversos sistemas existentes, provendo serviços que realizam a comunicação entre esta categoria de aplicações de forma transparente às mesmas.
Um ponto a ser destacado na utilização de Middleware é a reduçao na complexidade do sistema, pois, ao utilizar tal camada, o sistema terá sua complexidade reduzida, sendo que este é um dos objectivos principais na utilização desta camada intermediária.
Devido às propriedades dos componentes de um Middleware, os seus serviços não são dependentes de plataforma ou aplicação. O serviço oferecido deve atender às necessidades de uma gama de aplicações de um determinado dominio, não se concentrando apenas em serviços fornecidos para uma aplicação especifica, além de ter implementação independente da plataforma. Esta independência de plataforma é conseguida no momento da implementação dos serviços, quando se busca atingir a portabilidade, o que significa que esta camada poderá ser transferida para outra plataforma com o minimo de esforço.
Os objectivos principais de um Middleware são a integração entre sistemas heterógeneos e a intermediação entre camadas de software.
Neste projecto a camada de Middleware pode esconder da aplicação os detalhes da base de dados, simplificando bastante o desenvolvimento das aplicações e consequentemente reduzindo custos. Mas o uso de aspectos na integração entre aplicação e Middleware possibilita ganhos ainda maiores: o código da aplicação fica isento de qualquer dependência explícita do sistema de Middleware em uso, possibilitando a sua utilização num grande número de contextos diferentes.
No âmbito deste projecto, quando em alguma parte é realizado o acesso à base de dados, este é realizado por intermédio da camada de Middleware. Esta trata de invocar o Stored
Procedure que se encontra no motor de base de dados, seguindo-se a execução das
24
6. Aplicações Desenvolvidas
6.1. Windows Application
6.1.1 Arquitectura
O objectivo principal da criação da Windows Application foi a administração da base de dados.
Um dos aspectos mais relevantes no decorrer da implementação da Windows Application é a utilização da camada intermédia, denominada Middleware. Esta simplificou significativamente a codificação da aplicação GestCar. Desta forma, quando a aplicação necessita de aceder à base de dados, comunicar com a Middleware, esta responsabiliza-se por pela conexão e acesso à base de dados, devolvendo a resposta ao pedido feito pela aplicação.
A aplicação recebe os dados que são submetidos à interface, conforme o pedido que o utilizador fez ao sistema, para depois tratar essa informação. Tudo que envolva informação relativa a base de dados (por exemplo: inserção, actualização, leitura ou remoção), o seu tratamento é da responsabilidade da camada de Middleware, tal como já foi referido. A
Windows Application apenas gere os pedidos do utilizador, sendo estes disponibilizados de
uma forma agradável e organizada.
6.1.2 Implementação – Aspectos Relevantes
A aplicação foi desenvolvida em ambiente .NET, na linguagem C#. Tem como principal funcionalidade, oferecer todo o conjunto de funções necessárias para a gestão do sistema. Do ponto de vista arquitectural permite a total interacção com a base de dados e constitui a ferramenta para o administrador do sistema.
Como a figura 7 indica, a Windows Application intitulada de GestCar, disponibiliza um ambiente de trabalho e uma barra de ferramentas, esta é o atalho para cada um dos sub-menus que permitem inserir, remover ou alterar elementos na base de dados entre outras funcionalidades.
25
Figura 7 – Windows Application Main Menu
As operações de gestão podem ser efectuadas sobre: sensores, proprietários, veículos e contactos. Como já referido serão disponibilizadas várias funcionalidades, mas para cada uma das entidades serão as mesmas, por isso os sub menus são muito idênticos variando apenas no seu aspecto e algumas funcionalidades extra, que se revelaram necessárias. Conforme o exemplo descrito na figura 8, o administrador no caso, poderá inserir, actualizar ou remover um contacto da base de dados, para tal, necessita de seleccionar o contacto a tratar.
Figura 8 – Administração dos Contactos
A janela principal permite abrir novas janelas no seu interior. O objectivo é agrupar todas as tarefas numa principal que é a gestão do sistema principal. É a propriedade MDI (Multiple
26
Document Interface) do ambiente .NET que proporciona tal efeito, na prática a grande
vantagem a possibilidade do administrador executar o programa principal e neste possuir todas as forms necessárias, é permitido abrir mais do que uma ao mesmo tempo o que facilita a consulta de dados e quando a janela principal é fechada todo o sistema é encerrado, o que não permite comportamentos inesperados.
A aplicação desenvolvida permite arrastar e inserir objectos que no caso se tratam de
strings, para isso é utilizada uma propriedade conhecida como drag’n’drop.
A grande vantagem do uso de drag’n’drop de uma janela para a outra, reside no facto de simplificar o preenchimento de campos que nem sempre são intuitivos. Por exemplo, na inserção de um contacto, é pedido o preenchimento dos campos telefone e do código do proprietário, a este código está naturalmente associado um proprietário, como é praticamente impossível de memorizar todos os códigos dos proprietários, através do drag’n’drop podia-se arrastar o código da tabela de proprietários existente no menu de proprietários e desta forma preencher o campo código de proprietário no menu de contactos.
Figura 9 – Drag’n’Drop
6.2. Web Application
6.2.1 Arquitectura
A Web Application foi concebida com o objectivo de disponibilizar aos utilizadores um serviço web onde poderá registar os seus veículos (com os respectivos sensores), bem como consultar toda a informação referente aos dispositivos on-line.
27
Esta aplicação tal como a anterior, visto também necessitar de comunicar com a base de dados, usa como intermediário a camada de Middleware. Deste modo a arquitectura desta aplicação segue a arquitectura da Windows Application.
6.2.2 Implementação – Aspectos Relevantes
Esta aplicação permite ao utilizador registar-se no sistema, inserindo os seus dados pessoais.
Figura 10 – Inserção dos dados
Após inserção dos dados é criada uma conta pessoal, com login e password escolhida pelo utilizador, desde que já não existam no sistema iguais. Caso já existam, a aplicação avisa o utilizador permitindo alterar estes campos de forma a efectuar o seu registo.
Uma vez registado, o utilizador entra na sua conta pessoal onde apenas pode consultar a informação referente aos seus veículos (registados).
28
Figura 11 - Aspecto de uma conta pessoal
Aqui é possível registar ou remover veículos, consultar os veículos registados e ainda consultar todas as chamadas ao sistema feitas pelos veículos (sensores) registados.
29
7. Web Services
7.1. Conceito
Inicialmente pensou-se em criar um protocolo minimalista, cujo funcionamento consistia em criar um web service estático. Neste constavam todos os métodos passíveis de serem utilizados por todos os tipos de sensores. Quando chegasse um pedido de um dado sensor, este seria previamente identificado pelo seu ficheiro descritivo XML, e consoante o seu tipo teria à disposição o conjunto dos métodos que lhe seriam úteis.
Figura 13 – Aspecto do Web Service
No caso concreto deste projecto, o web service deveria ser gerado automaticamente. Tal facto levou a que fosse desenvolvido um módulo de criação automática e dinâmica de web
services.
Simplesmente foi dividida a sua geração em duas partes distintas nomeadamente, a construção de todos os ficheiros necessários para a compilação de um web service e a sua compilação propriamente dita efectuada através do CSC (C sharp Compiler).
30
A geração dos ficheiros constituintes do web service processa-se através de uma classe desenvolvida em C# que escreve em ficheiro os métodos utilizados pelo mesmo. A classe geradora inicialmente cria os ficheiros, posteriormente através de stringBuilder’s e concatenação de strings é preparado ficheiro. A classe principal do web service é criada através de uma classe, intitulada generator na qual, consoante o tipo de sensor que irá aceder aos serviços, são criados diferentes web methods para o efeito. Isto é, cada tipo de sensor terá ao seu dispor diferentes métodos, visto que o tratamento de dados é diferente.
Após a criação de todos os ficheiros, é a própria aplicação que compila as classes criadas e desta forma, o web service encontra-se criado e pronto a usar. A compilação é efectuada pelo CSC, conforme anteriormente referido, mas é importante referir que é usada uma instrução que executa o processo de compilação.
7.2. Implementação
Numa primeira fase, os ficheiros são gerados pela aplicação. O directório de destino é
”c:\InetPub\wwwroot\WebService1”, o qual é o directório por defeito para todos os web services criados.
Foi criado uma classe Generator que é responsável por criar a classe principal do web
service (service1.asmx.cs). Os restantes ficheiros são gerados por uma classe designada por GenAllFiles, existindo apenas um que não é gerado automaticamente, que se trata da solução
(WebService1.sln).
Figure 14 – Web Service Generated files
Desenvolveu-se um método chamado genClass da classe Generator, responsável por escrever o conteúdo do ficheiro. Este vai disponibilizar dois métodos, no caso uma para registar um sensor e outro que permite ao sensor enviar os campos, e após o seu envio o sistema central fica então preparado para tratar a informação recebida.
31
É tendo em conta o ficheiro XML recebido, com o protocolo de comunicação de cada sensor, que a geração automática de Web Services é efectuada. Assim é lido o ficheiro XML do sensor, com a ajuda da XMLDocument disponibilizada pelo C#. Sendo carregado para um
XmlNodeList toda a informação contida no nodo raiz do ficheiro XML.
Dependendo do número de campos de cada sensor, o método gerado será diferente.Por exemplo, se o número de campos descrito no ficheiro XML de um dado sensor for um, então o método do Web Service terá de se preparas para receber apenas um campo.
Uma vez criados todos os ficheiros, o próximo passo é sua compilação. Para o efeito recorre-se ao CSC.
Desta forma encontra-se criado o ficheiro dll, e o Web Service encontra-se pronto para ser executado.
32
8. Conclusões e Trabalho Futuro
Como uma tentativa de aproximação a um sistema de gestão de sensores localizados em veículos, dada a diversidade de tipos de sensores existentes, e sendo a comunicação efectuada por web services, estes gerados automaticamente, surge a solução apresentada.
Apesar do trabalho não incidir apenas na geração automática de web services, estes constituem o carácter inovador de todo o projecto.
Convém salientar o facto de que apesar da geração automática dos web services estar a ser utilizada neste caso particular, esta mesma solução facilmente pode ser adaptada a novos requisitos, como por exemplo novos métodos disponíveis pelo web service para as mais variadas aplicações.
No que diz respeito ao trabalho futuro, poderia ser melhorado o nível de comunicação estabelecido entre os sensores, com o objectivo de estabelecer um diálogo entre dispositivos, de forma a solucionar possíveis avarias detectadas. Foram considerados apenas neste processo, sensores e um sistema central, no futuro seria bem mais interessante o desenvolvimento de um novo sistema pronto a ser aplicado a dispositivos móveis tais como telemóveis, pda’s, etc. Desta forma o utilizador teria conhecimento de toda a informação proveniente do seu veículo de uma forma portátil.
Devido a este projecto decorrer apenas num carácter académico, foi impossível simular na prática a realidade de todo este sistema.
Para ampliar todo este tipo de comunicação a vários dispositivos, era necessário que estes entendessem o nosso protocolo, isto é, possuíssem um software capaz de receber e enviar informação ao nosso sistema.
33
Bibliografia
1. Michael Stiefel, Robert J. Oberg. Application Development Using C# and .NET.
2. G. Andrew Duthie. Microsoft ASP.NET Programming with Microsoft Visual C# .NET
Version 2003 Step by Step.
3. John Sharp and Jon Jagger. Microsoft Visual C# .NET Step by Step - Version 2003.
4. Dino Esposito. Building Web Solutions with ASP.NET and ADO.NET.
5. José Carlos Ramalho, Pedro Henriques. XML & XSL da Teoria à Prática.
34
Referências WWW
[01] www.di.uminho.pt
Página principal do Departamento de Informática da Universidade do Minho. Aqui podemos encontrar informação referente aos membros do departamento, actividades de ensino, projectos de desenvolvimento e de investigação, etc.
[02] www.msdn.com
Página da Microsoft destinada a ajudar os programadores a desenvolver aplicações usando os produtos e as tecnologias da Microsoft.
[03] www.codeproject.com
Página onde se pode encontrar um fórum com soluções em C#, para diversos problemas colocados por utilizadores da linguagem.
[04] www.dotnetspider.com/technology/tutorials/
Tutorial online, destinado para quem estiver a iniciar-se a programação .NET.
[05] www.gotdotnet.com
35
Lista de Siglas e Acrónimos
ADO ActiveX Data ObjectASP Active Server Pages
BD Base de Dados
COM Component Object Model CSC C Sharp Compiler
DLL Dynamic Link Library
DTD Document Type Definition
HTML HyperText Markup Language
ODBC Open DataBase Connectivity
OLEDB Object-Linking-and-Embedding Data Base
OO Orientado a objectos
SGML Standard Generalized ML
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
UDDI Universal Discovery Description Language
XML eXtensible Markup Language
WSDL Web Services Description Language
W3C World Wide Web Consorcium
