Thursday, November 18, 2004

24 horas com o SharePoint 2003

O problema: numa configuração Small Server Farm, tal e qual como descrita na documentação, o SPS queixa-se de "topologia não suportada", o que impede - entre outras coisas - a realização de backups.


Depois de algum tempo com este problema, foi aberto um caso com a MS, que recomendou a re-criação da BD de Configuração, e o re-attach das BD's de conteúdo antigas. Decidimos avançar por aí.


15:00 Problema de topologia não suportada num SPS em produção.


15:05 Realização de backup SQL às 4 bases de dados que suportam o SPS.


15:10 Modificação das atribuições de componentes aplicacionais (Web, Search, Index e Job Server), que foram limpas.


15:15 Disconnect da BD de Configuração, e criação de nova BD de configuração.


Entre esta hora e as 17:15, tentativas variadas de ligar o portal às BDs de conteúdo previamente existentes. Telefonemas de utilizadores a queixar-se de indisponibilidade do sistema.


17:15 Já com apoio telefónico da MS, repetição de todos os passos tentados durante as 2h anteriores, sem sucesso.


17:50 Plano de contingência: voltar à BD de configuração anterior, restaurando também as "component assignments" prévias.


18:00 Na página da Central Administration, o erro de topologia... desapareceu (!). O portal parece totalmente funcional, com a excepção da pesquisa: "No results are available due to a network failure. Please contact the portal's administrator."


Dia seguinte


15:00 Análise do Event Log (nada) e dos logs de pesquisa do SharePoint, que numa das suas linha diz: Could not find stored procedure 'dbo.proc_MX_getVersion'.


15:10 Número de resultados por pesquisas por proc_MX_getVersion no Google e Google Groups: 0 (zero). :-)


15:15 Análise às bases de dados do SharePoint. Nenhuma delas tem este Stored Procedure. A BD xxx_SERV, no entanto, tem uma tabela chamada "MX_Version".


15:20 Restauro, para uma nova BD, do backup da xxx_SERV das 15:05 do dia anterior.


15:30 Comparação dos stored procedures existentes nas duas bases de dados. A base de dados restaurada de backup tem vários proc_MX_*, nenhum dos quais existente na versão actual, além de um proc_getPortalBuildVersion e um proc_getPortalSchemaVersion.


16:00 Criação na base de dados nova dos 16 Stored Procedures "Missing In Action".


16:20 Realização de full update ao Portal Content bem sucedido.


16:30 A pesquisa funciona. Sucesso. :-)


Claro que entretanto, o catálogo de non-portal content ficou limpo quando fiz um full update. E descobri um problema que já acontecia há 10 dias, relacionado com o Exchange usado para enviar notificações, na sequência do qual são escritos erros no Event Log de 10 em 10 segundos.


Mas isso são outras 24 horas. :)


jota

Monday, November 1, 2004

SOA: Boundaries are explicit

Na visão da Microsoft/Don Box, a orientação a serviços pode definir-se por 4 tenets:



  1. Boundaries are explicit
  2. Services are autonomous
  3. Services share schema and contract, not class
  4. Compability is based upon policy

O primeiro deste tenet, "Boundaries are explicit", foi descrito por Rich Turner como "Services are expressed at their boundary and there is only ONE way to access the information and/or functionality held within a service - through capabilities exposed at the Service Boundary. Also, assume that calling methods on a Service may take time and may be unreliable.", e pelo próprio Don Box como "Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services." (ver também este artigo, já agora)


Este post, e o foco no 1º tenet (e não só, para falar estritamente verdade), surge a propósito de um artigo que li chamado "A Note On Distributed Computing". Escrito por uns rapazes da Sun em 1994, este artigo tenta demonstrar porque é que se deve lidar com objectos remotos de forma diferente da forma como se lida com objectos locais (i.e., num mesmo espaço de endereçamento). É como que uma defesa do 1º tenet, interessante, actual e rápida de ler, e tem tudo a ver com web services.


Logo a abrir, "In such systems, an object, whether local or remote, is defined in terms of a set of interfaces declared in an interface definition language. The implementation of the object is independent of the interface and hidden from other objects." (can you spell w-s-d-l?)


No artigo identificam-se alguns motivos pelos quais se devem tratar invocações remotas de forma distinta de invocações locais:



  1. Latência: os tempos de espera em invocações remotas são a diferença mais óbvia entre os tipos de acesso (o artigo sugere algo similar a uma optimização que aproxime os objectos usados mais frequentemente, no SOA tende-se para uma visão em que a funcionalidade oferecida por cada serviço é mais rica);
  2. Acesso à memória: esta diferença prende-se especificamente a acesso à memória usando apontadores ou referências. Referem-se duas alternativas: ou todos os acessos à memória devem ser gerido pelo sistema, ou o programador deve estar consciente das diferenças entre acesso a memória local e remota;
  3. Falha parcial e concorrência: a principal classe de diferenças entre os dois modelos, refere-se por exemplo a situações em que o servidor falhe inesperadamente, e ao facto de "In a distributed system, the failure of a network link is indistinguishable from the failure of a processor on the other side of that link". Há muito a dizer sobre este ponto, o artigo fá-lo melhor do que eu.

E quase a concluir: "A better approach is to accept that there are irreconcilable differences between local and distributed computing, and to be conscious of those differences at all stages of the design and implementation of distributed applications. [...] While writing code, engineers will have to know whether they are sending messages to local or remote objects, and access those objects differently. While this might seem to add to the programming difficulty, it will in fact aid the programmer by providing a framework under which he or she can learn what to expect from the different kinds of calls."


Com as devidas adaptações, e talvez lendo "serviços" onde o artigo usa geralmente "objectos [remotos]", o artigo surpreendeu-me pela sua actualidade, e recomendo-o vivamente a quem desenvolva web services hoje, com ou sem o chapéu do SOA.


jota


Ps: isto não é um post "pró-Sun", mas sim de surpresa por uma bela pérola encontrada ao acaso :-)