Evolu¸c˜ao e limita¸c˜oes da arquitectura

A arquitectura proposta baseia-se em normas como o HTTP ou o SOAP, o SSL ou o TLS, o XML, o XML Signature, o BASE64 e o X509v3. Assim, ´e importante analisar at´e que ponto quaisquer futuras evolu¸c˜oes destas normas afectam a funcionalidade da arquitectura e com que facilidade ela pode beneficiar dessas mesmas evolu¸c˜oes. A primeira considera¸c˜ao a fazer ´e a de que as tecnologias referidas s˜ao de uso generalizado e, consequentemente, eleg´ıveis para importantes inova¸c˜oes mas, simultaneamente, pouco suscept´ıveis a grandes roturas. Se a retro-compatibilidade for assegurada, a adop¸c˜ao de normas melhoradas n˜ao dever´a ter quaisquer consequˆencias relevantes para a funcionalidade da arquitectura. Se n˜ao, o esfor¸co de remodela¸c˜ao dos sistemas dever´a poder ser contido no ˆambito de requerentes e prestadores, n˜ao devendo implicar a altera¸c˜ao dos sistemas locais das entidades. A ser este o caso, o custo de reformula¸c˜ao depende essencialmente da modularidade desses componentes e, assim, ´e essencialmente um problema de engenharia de software.

De qualquer forma, o modelo que baseia a arquitectura proposta parece poder permanecer v´alido independentemente das tecnologias que sejam utilizadas para o implementar. Este ´e seguramente o caso da plataforma Web Services e, nomeadamente, da norma WS Security. Note-se, a este prop´osito, que o protocolo UDDI pode ser utilizado para permitir que os reposit´orios de servi¸cos sejam automaticamente descobertos, tanto por requerentes como por prestadores. Existem v´arias outras tecnologias cuja utiliza¸c˜ao no ˆambito do modelo que baseia a arquitectura proposta merece ainda ser avaliada: o SAML e o XACML, ao n´ıvel da seguran¸ca; o BPEL, o BPML e o WSCI, ao n´ıvel do suporte da coordena¸c˜ao de servi¸cos e da integra¸c˜ao de processos; o RDF, o RDF-S e o OWL, ao n´ıvel da normaliza¸c˜ao de formul´arios, anexos e resultados; e o OWL-S e o WSML, ao n´ıvel do suporte da composi¸c˜ao dinˆamica de servi¸cos.

Note-se ainda que, devido `a sua natureza intrinsecamente distribu´ıda, a arquitectura n˜ao imp˜oe a existˆencia de um conhecimento centralizado sobre o fluxo total dos processos que correspondem `as solicita¸c˜oes dos utilizadores. Assim, esse conhecimento pode ser distribu´ıdo pelas diferentes entidades intervenientes no processo: uma entidade de front-office e v´arias entidades de back-office, no caso da composi¸c˜ao de servi¸cos; e v´arias entidades de back-office, no caso da integra¸c˜ao de processos. Embora a informa¸c˜ao sobre o estado de satisfa¸c˜ao de um pedido possa sempre ser

obtida recorrendo `a emiss˜ao de relat´orios, esta situa¸c˜ao configura uma limita¸c˜ao da arquitectura no que respeita `as possibilidades de monitoriza¸c˜ao dos processos.

A arquitectura proposta segue a abordagem da integra¸c˜ao de processos em detrimento da abor- dagem da integra¸c˜ao de informa¸c˜ao. Consequentemente, ela n˜ao responde a quest˜oes como, por exemplo, a procura de documentos, a manipula¸c˜ao remota de dados ou a realiza¸c˜ao de pesquisas ad hoc. Embora a composi¸c˜ao dinˆamica de servi¸cos possa ser suportada, a arquitectura proposta ´e especialmente adequada para suportar processos bem estruturados e pr´e-definidos. Uma vez que a arquitectura depende do estabelecimento de redes de confian¸ca entre entidades, ela ´e tamb´em mais adequada para utiliza¸c˜ao no ˆambito de grupos est´aveis de entidades do que em parcerias abertas. Note-se ainda que, tal como proposta, a arquitectura n˜ao suporta conex˜oes ass´ıncronas.

5.7

Conclus˜ao

A arquitectura proposta estabelece as condi¸c˜oes b´asicas que permitem aos organismos da ad- ministra¸c˜ao p´ublica colaborarem entre si em benef´ıcio dos cidad˜aos e das empresas. Suporta a implementa¸c˜ao de eventos da vida, pontos ´unicos de acesso, prestadores concorrentes e integra¸c˜ao de canais de atendimento. Baseia-se em tecnologias bastante divulgadas e consolidadas, incorporan- do solu¸c˜oes que permitem garantir a autentica¸c˜ao, a autoriza¸c˜ao, a confidencialidade, a integridade e a n˜ao repudia¸c˜ao. ´E uma arquitectura totalmente distribu´ıda, onde o conhecimento acerca da rede ´e distribu´ıdo entre os n´os participantes, sem necessidade de recurso a quaisquer unidades centralizadas. Finalmente, permite estabelecer uma plataforma de comunica¸c˜ao relativamente leve `a qual pode ser ligado virtualmente qualquer tipo de organismo e com base na qual podem ser estabelecidos novos n´ıveis de normaliza¸c˜ao.

A discuss˜ao efectuada na sec¸c˜ao anterior comprova a utilidade da arquitectura tanto do ponto de vista da coordena¸c˜ao de servi¸cos no front-office, seja ela est´atica ou dinˆamica, como do ponto de vista da integra¸c˜ao de processos no back-office. Comprova ainda a utilidade da arquitectura quando o atendimento ´e simplesmente presencial, em linha ou multicanal. Assim, a arquitectura proposta ´e ´util tanto para os quadrantes QxBcomo para os quadrantes QxAdo nosso quadro geral de

an´alise (Sec¸c˜ao 3.6). O facto de ela poder ser igualmente usada ao n´ıvel de um ´unico organismo da administra¸c˜ao p´ublica, pela separa¸c˜ao funcional entre departamentos de front-office e de back-office, permite-nos afirmar igualmente a sua relevˆancia para os quadrantes QxC e, consequentemente, para

todos os nove quadrantes do nosso quadro geral de an´alise.

A arquitectura proposta tem ainda alguma margem de progress˜ao e melhoramento. Na forma como foi apresentada, ela n˜ao constitui ainda uma norma completamente estabilizada que possa ser objecto de adop¸c˜ao alargada e imediata no dom´ınio do governo electr´onico. Entre os assun- tos que podem ser objecto de maior aprofundamento encontram-se o suporte da normaliza¸c˜ao de formul´arios, anexos e relat´orios; a defini¸c˜ao de crit´erios de pesquisa para servi¸cos e relat´orios; a hierarquiza¸c˜ao e a gest˜ao integrada de reposit´orios de servi¸cos; a partilha de informa¸c˜ao entre front- offices; a monitoriza¸c˜ao de processos distribu´ıdos; a distribui¸c˜ao e gest˜ao dos certificados digitais e das listas de revoga¸c˜ao de certificados; os m´etodos de pagamento; e a especifica¸c˜ao de interfaces. Contudo, isso n˜ao impediu que os principais fundamentos da arquitectura fossem objecto de vali- da¸c˜ao experimental. A an´alise dos processos com base nos quais essa valida¸c˜ao foi feita, o prot´otipo utilizado para tal e a infra-estrutura utilizada para implementar esse prot´otipo constituem o objecto do pr´oximo cap´ıtulo da disserta¸c˜ao.

Cap´ıtulo 6

Estudo de caso

6.1

Introdu¸c˜ao

No cap´ıtulo anterior propusemos e discutimos uma arquitectura para a integra¸c˜ao de servi¸cos no governo electr´onico. Neste cap´ıtulo descrevemos a valida¸c˜ao experimental, ainda que parcial, dos principais fundamentos dessa mesma arquitectura. O trabalho experimental consistiu no desenvol- vimento de um prot´otipo baseado na arquitectura proposta e no seu teste com base na simula¸c˜ao de alguns processos reais da Cˆamara Municipal de Aveiro (CMA). Para tal, foi feita a identifica¸c˜ao e caracteriza¸c˜ao de todos os processos iniciados pelos clientes atrav´es das sec¸c˜oes de Atendimento Geral e de Taxas e Licen¸cas da CMA.

O cap´ıtulo encontra-se organizado em cinco sec¸c˜oes, incluindo a presente sec¸c˜ao de introdu¸c˜ao. Na segunda sec¸c˜ao descrevemos a an´alise dos processos da CMA. Especificamente, justificamos a escolha da CMA e a selec¸c˜ao de processos efectuada, descrevemos o m´etodo de an´alise utilizado e apresentamos os resultados dessa an´alise no que diz respeito a dois processos paradigm´aticos. Na terceira sec¸c˜ao descrevemos o prot´otipo desenvolvido e na quarta sec¸c˜ao apresentamos e discutimos os testes efectuados. Finalmente, na quinta e ´ultima sec¸c˜ao, resumimos o cap´ıtulo e apresentamos algumas conclus˜oes.