Schools Interoperability Framework e SOA

Uma ponte de interoperabilidade

A movimentação de dados dos distritos escolares para os departamentos estaduais de educação é uma questão importante para as escolas de ensino fundamental ao médio atualmente. Por meio de exemplos, este artigo descreve uma ponte de interoperabilidade que permite que as agências educacionais estaduais baseadas em SOA se interconectem e obtenham dados dos distritos que podem ser baseados no Schools Interoperability Framework (SIF).

Viswanath Srikanth, Senior Software Engineer, Os compiladores IBM

Viswanath Srikanth author photoSri é líder de padrões de soluções para os segmentos de mercado de educação e transportes na IBM. Anteriormente, foi copresidente do SOA Best Practices Technical Report no IMS Global Learning Consortium.



Christopher M. Laffoon, Software Engineer, Os compiladores IBM

Christopher M. Laffoon author photoChris é engenheiro de normas de soluções para os segmentos de mercado de educação, transporte, produtos químicos e petróleo. Ele possui importante experiência no desenvolvimento de diversos padrões de sistemas de mensagens para segmentos de mercado, como o Schools Interoperability Framework, XML, XML Schema e tecnologia Java™ .



Gee Chia, Advisory Software Engineer, Os compiladores IBM

Gee Chia author photoAtualmente, Gee trabalha com softwares emergentes e padrões de segmentos de mercado na IBM. É uma das principais designers e desenvolvedoras da ponte de interoperabilidade SIF/SOA.



Christopher Jay Davia, Lead Architect, Os compiladores IBM

Christopher Jay Davia author photoChris é responsável pela arquitetura tecnológica da IBM Global Education Industry. Trabalha em conjunto com as comunidades de software livre, corporações de padrões abertos e fornecedores de segmentos de mercado. Chris também é líder do Technical Architecture Board da IBM Cloud Academy.



31/Ago/2012

Introduction

Nos Estados Unidos, as escolas do ensino fundamental ao médio, conhecidas como K-12, estão sob uma pressão cada vez maior para melhorar o desempenho dos alunos e fornecer uma visualização mais integrada sobre seu desenvolvimento. Os departamentos de Justiça, Saúde, e outros interessados envolvidos no sucesso dos alunos, esperam que os distritos escolares e os departamentos estaduais de educação compartilhem informações. Hoje em dia, consideramos que uma perspectiva holística é fundamental para o desenvolvimento da mão de obra e dos cidadãos do futuro.

O cumprimento dos objetivos de integração e movimentação de dados envolve dois componentes básicos:

  • Maior movimentação de dados dos distritos escolares para o nível estadual, para melhor consolidação, análise e recomendações.
  • Maior integração entre diversos interessados de forma segura e aproveitável.

Até recentemente, a maioria dos requisitos de integração de dados referentes a escolas do ensino fundamental ao médio se concentrava no compartilhamento de dados seletos dentro de um distrito escolar, e uma movimentação de dados seletos no estado. Um padrão arquitetural do tipo "hub and spoke", popularizado por meio do Schools Interoperability Framework (SIF), atendeu razoavelmente bem aos requisitos. Características como entrega garantida e segurança foram integradas. a Figura 1, da SIF Association, mostra o padrão arquitetural básico.

Figura 1. Schools Interoperability Framework
Schools Interoperability Framework

O principal padrão de uso do SIF envolve o registro de interesse por parte de certos aplicativos (por meio do agente de SIF) referente a dados específicos e, por parte de outros aplicativos, referente à sua capacidade de fornecer dados em um padrão clássico de troca de mensagens do tipo publicação e assinatura (também conhecido como pub/sub). Outros recursos incluem troca de mensagens do tipo solicitação/resposta e, em futuros releases, mais recursos para os agentes do SIF. O principal padrão e o uso dominante continuarão com o paradigma arquitetural pub/sub baseado em dados.

Uma discussão detalhada a respeito da SOA está fora do escopo deste artigo. Esse assunto está bem documentado em outros textos (consulte Resources).

Para cumprir com os requisitos referentes à maior movimentação de dados dos distritos para o nível estadual e à maior integração entre os interessados, os distritos escolares e departamentos de educação de grande porte estão se interessando cada vez mais na arquitetura orientada a serviços (SOA). A SOA envolve a integração e a coreografia de aplicativos distribuídos em suporte aos processos de negócios, incluindo processos entre agências. A SOA se enquadra bem nos novos requisitos de negócios dos distritos escolares do ensino fundamental ao médio e nos departamentos estaduais de educação.

Este artigo descreve uma ponte de interoperabilidade que permite que os departamentos estaduais de educação baseados em SOA se interconectem e obtenham dados de distritos baseados em SIF.


Os requisitos

O primeiro requisito é movimentar uma quantidade significativamente maior de dados dos distritos escolares para o nível estadual. Pode-se obter a movimentação desses dados por meio de diversos protocolos, como FTP, upload da Web, solicitação/resposta SIF e serviços da Web.

O segundo requisito é que os dados, depois de serem recebidos pelo estado, devem ser:

  • Consolidados em um banco de dados comum
  • Analisados
  • Disponibilizados para o acesso de distritos escolares e outros interessados, como instituições de ensino superior ou o Departamento de Justiça dos EUA

O melhor método para colocar os dados à disposição do estado é por meio de serviços da Web, que podem proporcionar facilidade de acesso e integração simplificada. Há um perfil de padrões de serviços da Web para fornecer segurança e confiabilidade e tratar do uso de um mecanismo robusto de integração.

O terceiro requisito é que os dados se integrem a outros aplicativos dentro de um departamento estadual de educação. Esse requisito é preenchido facilmente por meio da SOA e dos serviços da Web.

À medida que um departamento estadual de educação estabelece a SOA como sua arquitetura de integração, ainda existe a necessidade de interagir com as redes escolares que já investiram no SIF. A necessidade é particularmente relevante no caso de uso em que uma instituição de ensino superior solicita o histórico escolar de um aluno candidato a ingressar na instituição. Normalmente, a solicitação passaria pelo estado e iria para o distrito escolar apropriado (a menos que o estado optasse por hospedar os históricos escolares de todos os alunos). Por esta razão, os aplicativos estaduais devem ser capazes de trabalhar com um distrito habilitado para SIF. Outro caso de uso envolve a movimentação de dados dos distritos escolares para o estado, em que o estado está totalmente habilitado para SOA.

Há, hoje em dia, uma ponte SIF/SOA que preenche o requisito de que os aplicativos que operam no paradigma SIF possam se conectar a aplicativos no domínio SOA. A seção a seguir descreve a ponte de interoperabilidade.


Arquitetura da ponte SIF/SOA

Na arquitetura SIF, os agentes servem de frente para os aplicativos e atuam como intermediários para a comunicação de dados entre aplicativos. Os agentes transformam objetos em objetos de dados do padrão SIF, registram-se como Zone Integration Server (ZIS) e informam ao ZIS seus recursos e interesses. O ZIS roteia solicitações e eventos apropriadamente entre os agentes, garantindo a segurança e a entrega de mensagens. Basicamente, em uma implementação do SIF, o aplicativo se baseia nos seus agentes para trocar dados usando o ZIS.

Para permitir que aplicativos SOA participem da troca de dados com aplicativos da zona do SIF, foi projetada uma ponte SIF/SOA. A ponte conecta os aplicativos SOA baseados em serviços da Web a aplicativos da zona do SIF gerenciados pelo ZIS.

a Figura 2 mostra como uma ponte SIF/SOA atua como agente do SIF na zona do SIF para se integrar a um ZIS e aos objetos de dados naquela zona. No outro lado, a ponte SIF/SOA irá expor uma interface de serviços da Web que permite que um barramento de serviço corporativo (ESB) e outros consumidores de serviços da Web se conectem a uma zona do SIF por meio de serviços da Web.

Figura 2. Zona única do SIF conectada à SOA com a ponte SIF/SOA
Zona única do SIF conectada à SOA com a ponte SIF/SOA

Componentes da ponte SIF/SOA

A tabela a seguir descreve os principais critérios para o design e a implementação da solução de ponte SIF/SOA. Ela inclui as funções que cada componente deve suportar.

ComponentsRecurso
Implementar um agente do SIF em conformidade com a especificação do SIF na qual a ponte se baseia para se conectar ao ZIS, a fim de trocar dados com aplicativos da zona do SIF.
  • SIF_HTTPS ou SIF_HTTP como a camada de transporte.
  • Iniciar o agente quando a ponte é iniciada e encerrá-lo quando a ponte é encerrada. Isso garante que o agente seja conectado ao ZIS, possa tratar mensagens SIF e libere recursos com segurança quando a ponte é encerrada.
  • Mensagens do SIF para registrar diversas configurações dos agentes no ZIS e para a troca de mensagens entre os agentes. Por exemplo,
    • Capacidade de registrar os objetos de dados dos quais o agente SIF precisa para fornecer, solicitar e responder.
    • Configurar o ZIS e a zona do SIF aos quais o agente do SIF se conecta, e fazer as configurações da conexão (push x pull, HTTP x HTTPS).
Implementar e expor um serviço da Web para permitir que um ESB, e outros consumidores dos serviços da Web, se conectem a uma zona do SIF por meio de serviços da Web. As trocas de dados fluirão das zonas de SOA para a zona de SIF. Permitir que os aplicativos (consumidores dos serviços da Web) na zona de SOA:
  • Encaminhem as solicitações de objetos de dados de consulta SIF para uma zona de SIF apropriada.
  • Encaminhem objetos de dados SIF em resposta a uma solicitação correspondente de objetos de dados.
  • Encaminhem eventos de dados de interesse a partir da zona de SOA.
Implementar um cliente de serviço da Web para chamar os provedores de serviços da Web, a fim de possibilitar trocas de dados da zona de SIF para as zonas de SOA.Permitir que a chamada do provedor de serviço da Web na zona do SOA:
  • Encaminhe a solicitação de objetos de dados de consulta SIF do aplicativo para a zona de SIF.
  • Encaminhe objetos de dados em resposta à solicitação correspondente de objeto de dados.
  • Encaminhe eventos de dados de interesse a partir da zona de SIF.

Além de suportar o agente de SIF e os componentes do serviço da Web, a ponte também deve suportar a conversão e o mapeamento de formatos de mensagem (tanto de solicitação quanto de resposta) de um aplicativo na zona de SIF para o formato de carga útil das mensagens dos serviços da Web, e vice versa.

Os componentes de agente SIF, serviço da Web e transformação de dados são mostrados na A figura 3. É possível ver as interações e fluxos entre os componentes para realizar o fluxo de dados bidirecionais dos sistemas na zona de SIF e na zona de SOA. (Veja uma versão ampliada da Figura 3.)

Figura 3. Design da ponte SIF/SOA - componentes chave e interações
Design da ponte SIF/SOA - componentes chave e interações

Cenário de exemplo

Um cenário simples, chamado de validação do ID Estadual de Estudante, mostra como a ponte SIF/SOA integrou o School Information System (SIS) local da zona de SIF, executando em um distrito escolar local, e o serviço da Web de ID estadual, usando o ZIS. No cenário, o SIS local envia uma solicitação de validação do ID de estudante para o sistema de identificação do departamento estadual de educação (Serviço de ID Estadual). Ao receber a solicitação, o Serviço de ID Estadual processa a solicitação e envia a resposta de volta ao SIS local.

A figura 4 detalha os fluxos de dados e interações entre os componentes para realizar uma troca de dados de solicitação/resposta entre o SIS local na zona de SIF, e o Serviço de ID Estadual na zona de SOA.

Figura 4. Agente de SIF na zona de SIF interagindo com o serviço da Web de ID estadual por meio da ponte SIF/SOA
Agente de SIF na zona de SIF interagindo com o serviço da Web de ID estadual por meio da ponte SIF/SOA

Na Figura 4, os componentes interagem da seguinte forma:

  1. O sistema de SIS do distrito envia uma SIFRequest referente a um objeto StudentLocator para o ZIS.
  2. O ZIS envia de volta uma Confirmação SIF para o sistema de SIS do distrito.
  3. O ZIS do distrito envia essa SIFRequest para o agente de SIF da ponte SIF/SOA.
  4. O agente de SIF da ponte SIF/SOA extrai a consulta de SIF (usando o módulo de transformação de dados/mapeamento) da Solicitação SIF, e a entrega ao componente de serviço da Web da ponte SIF/SOA.
  5. O agente de SIF da ponte SIF/SOA envia de volta uma Confirmação SIF para o ZIS.
  6. O componente de serviço da Web da ponte SIF/SOA faz uma chamada de serviço da Web, que encaminha a consulta SIF para o terminal de serviço da Web do sistema de ID estadual.
  7. Ao processar a solicitação de ID estadual, o Serviço de ID Estadual envia um objeto StudentLocator SIF, por meio de uma chamada de serviços da Web, para o componente de serviços da Web da ponte SIF/SOA, como resposta à solicitação original.
  8. O componente de serviços da Web da ponte SIF/SOA extrai o DataObject (StudentLocator) SIF e o entrega ao agente de SIF da ponte SIF/SOA.
  9. O agente de SIF da ponte SIF/SOA cria uma Resposta SIF com o DataObject (StudentLocator) SIF e envia a resposta para o ZIS do distrito que fez a solicitação original.
  10. O ZIS do distrito envia uma Confirmação SIF para o agente de SIF da ponte SIF/SOA.
  11. O ZIS do distrito encaminha a resposta SIF para o sistema SIS local em resposta à solicitação de SIF original.
  12. O sistema SIS do distrito envia uma Confirmação SIF para o ZIS do distrito.

Usando a ponte SIF/SOA

Como foi mencionado, a ponte SIF/SOA fornece o importante recurso de transformar mensagens de serviço da Web (SOAP/HTTP) em mensagens SIF. Também gerencia a conectividade às zonas de SIF do distrito escolar. O caso de uso a seguir mostra o verdadeiro valor da ponte SIF/SOA: a movimentação complexa e vertical de dados das escolas locais ao nível do distrito.

Imagine que um administrador de uma instituição de ensino superior quer solicitar um histórico escolar do ensino médio referente a um aluno que está se candidatando a uma vaga na instituição. O administrador não precisa saber se conectar e comunicar-se diretamente com o distrito escolar local. Em vez disso, ele usa o portal único da instituição, que se conecta ao serviço da Web estadual apropriado para solicitar os históricos escolares. Sem o conhecimento da instituição de ensino superior, o estado tem dois distritos escolares que se comunicam com a plataforma de integração de formas completamente diferentes: um distrito escolar suporta apenas a arquitetura SIF, e o outro suporta apenas SOA.

Antes de detalhar os diversos componentes necessários para desenvolver uma solução para esse caso de uso, vamos descrever os principais requisitos.

  • A instituição de ensino superior precisa ser capaz de enviar uma requisição de histórico escolar para o departamento estadual de educação.
  • Depois de processar a solicitação, o departamento estadual de educação deve retornar o histórico escolar apropriado.

    No caso do cenário, o histórico escolar será retornado no formato padrão Postsecondary Electronic Standards Council (PESC), amplamente adotado.

  • O departamento estadual de educação deve ser capaz de solicitar os históricos escolares apropriados de dois distritos diferentes: o que suporta apenas a arquitetura SIF e o que suporta somente SOA.
  • Para se comunicar com o distrito que suporta a arquitetura SIF, é necessário usar a ponte SIF-SOA. O distrito que suporta SOA precisaria apenas de suporte para o serviço da Web padrão.

Figura 5, mostra uma arquitetura geral que poderia ser usada para preencher os requisitos desse caso de uso.

Figura 5. Instituição de ensino superior que solicita históricos escolares por meio do departamento estadual de educação
Instituição de ensino superior que solicita históricos escolares por meio do departamento estadual de educação

A arquitetura acima inclui um ESB no departamento estadual de educação para rotear e transformar as mensagens que fluem entre a instituição de ensino superior e os distritos escolares locais. O ESB contém diversos componentes de integração que, em conjunto, possibilitam o caso de uso de solicitação de históricos escolares:

  • Serviço de solicitação de históricos escolares para integrar-se à instituição de ensino superior.
  • Comunicação por mensagens com a ponte SIF/SOA para se conectar ao distrito de SIF em protocolos padrão de serviços da Web.
  • Roteamento de mensagens do serviço de solicitação de transcrições à solicitação de transcrições em distritos não SIF, ou para a zona de SIF do distrito de SIF, dependendo de onde o aluno está matriculado.
  • Transformação de mensagens entre mensagens SIF e mensagens PESC para o distrito de SIF, para comunicação com a instituição de ensino superior.
  • Agregação/desagregação de mensagens, para suportar as diversas mensagens SIF necessárias para responder a uma solicitação única de histórico escolar de ensino superior.

Em uma implementação do caso de uso, todos os componentes de integração foram implementados como módulos de mediação dentro do WebSphere® Enterprise Service Bus. Em vez de agrupar todo o roteamento, transformação e agregação de mensagens dentro de um módulo de mediação, os módulos de mediação foram projetados para ser extensíveis e flexíveis, tendo como resultado diversos módulos de mediação diferentes com um propósito específico.

A sequência de fluxos de dados para o caso de uso da solicitação de histórico escolar é mostrada na A Figura 6.

Figura 6. Fluxo de dados referente à solicitação de histórico escolar para o distrito escolar usando a ponte de interoperabilidade SIF/SOA
Fluxo de dados referente à solicitação de histórico escolar para o distrito escolar usando a ponte de interoperabilidade SIF/SOA

Na Figura 6, um histórico escolar referente a um aluno matriculado em um distrito habilitado para SIF está sendo solicitado. É possível seguir o fluxo numerado e as setas (em vermelho). Estes são alguns destaques dos componentes de mediação neste contexto:

  • O State Transcript Handler é um módulo de mediação que decide se a solicitação de histórico escolar vai para o distrito habilitado para SIF ou para o distrito não SIF. O módulo roteia a mensagem para o SIF Transcript Handler ou para o PESC Transcript Handler, respectivamente.
  • O SIF Transcript Handler é responsável por:
    • Tratar uma mensagem de solicitação de entrada e uma mensagem de resposta.
    • Enviar duas mensagens SIF diferentes para o distrito SIF (usando o SIF Bridge Message Gateway).
    • Agregar as duas respostas de mensagens SIF para desenvolver uma transcrição PESC.
  • O SIF Bridge Message Gateway é responsável por toda a comunicação com o distrito SIF a partir do WebSphere Enterprise Service Bus, por meio das interfaces fornecidas pelo canal da ponte SIF/WS.

O uso de um ESB, além da ponte SIF/SOA, permite que o departamento estadual de educação forneça um serviço importante e integrado à instituição de ensino superior que procura históricos escolares de alunos. A instituição de ensino superior não precisa se preocupar com as complexidades da arquitetura SIF.


Padrões de implementação para a ponte de interoperabilidade SIF/SOA

figura 7 mostra quatro padrões diferentes de implementação para a ponte SIF/SOA.

Conforme o descrito no Padrão 1, a colocação da ponte SIF/SOA no departamento estadual de educação para receber todas as solicitações SIF é uma solução possível. Nesse padrão, a ponte deve tratar solicitações provenientes de diversos distritos, ou ter diversas instâncias da ponte implementadas no nível estadual (uma por distrito).

Figura 7. Padrões de implementação para a ponte de interoperabilidade SIF/SOA
Padrões de implementação para a ponte de interoperabilidade SIF/SOA

No Padrão 2 acima, um ZIS é implementado no departamento estadual de educação, e é responsável pelo recebimento de todas as mensagens SIF provenientes das requisições do distrito. A ponte de interoperabilidade SIF/SOA se conecta ao ZIS e converte todas as mensagens para mensagens de serviços da Web, para a comunicação com outras requisições no estado. Essa abordagem evita a necessidade de ter um ZIS em cada distrito.

O Padrão 3 implementa a ponte de interoperabilidade SIF/SOA em cada distrito, convertendo toda a comunicação do distrito com o estado para uma comunicação de serviços da Web. O estado não recebe nenhuma solicitação de SIF, e se baseia unicamente em serviços da Web.

O Padrão 4 é aplicável nos casos em que há uma coleção de dados intermediária, no nível regional, e um ponto de encaminhamento. O ZIS e a ponte de interoperabilidade SIF/SOA podem ser implementados a nível regional, para que toda a comunicação bidirecional de recebimento de dados com os distritos use SIF. Toda a comunicação bidirecional de envio de dados com o estado usa serviços da Web.

Cada padrão de implementação proporciona benefícios diferentes. O uso dos padrões deve ser ajustado aos seus requisitos específicos.


Visão de futuro

As equipes de TI de departamentos de educação, distritos escolares e escolas particulares independentes enfrentam o desafio de se fazer mais com menos. Os orçamentos de TI estão sendo reduzidos, mas existe a expectativa de aumentar o número de serviços de relatório de dados e processos de negócios e, ao mesmo tempo, aumentar a eficiência dos mesmos. Consequentemente, os departamentos de TI não podem mais se dar ao luxo de descartar e substituir serviços já existentes por serviços novos, patenteados e prestados por fornecedores. A abordagem de descartar e substituir tem um alto custo inicial e um custo posterior chamado aprisionamento tecnológico. Com o aprisionamento tecnológico, o upgrade pode ser caro, e pode haver dificuldade de customizar ou integrar serviços em torno da tecnologia patenteada do fornecedor.

Espera-se que as equipes competentes de TI aproveitem os serviços já existentes, e incluam novos serviços de forma incremental à infraestrutura já existente. Os novos serviços são como blocos de® Lego: componentes independentes e fáceis de gerenciar que se juntam por meio de padrões. Com essa abordagem, é possível alinhar os serviços ao processo de negócios. Devido ao fato de que os serviços são vinculados por meio de padrões, eles podem ser trocados facilmente, criando um ambiente no qual os processos de negócios são flexíveis e fáceis de estender.

Há diversas razões para que uma organização adote a SOA:

  • Há um grande mercado de trabalho para ferramentas de desenvolvimento, mecanismos de processos de negócios e servidores de aplicativos. As ferramentas são oferecidas por comunidades de software livre e fornecedores comerciais.
  • Os padrões para vincular os serviços possibilitam uma infraestrutura flexível que é mais fácil de suportar, aprimorar e substituir.
  • Os padrões referentes ao middleware da infraestrutura evitam o aprisionamento tecnológico.
  • A SOA é um componente crítico da nuvem.
  • A SOA provou o seu valor em praticamente todos os segmentos de mercado. Por que seria diferente na educação?

Summary

A ponte de interoperabilidade SIF/SOA é uma primeira etapa importante para as organizações que desejam aproveitar os investimentos já existentes na arquitetura SIF. As agências baseadas em SOA podem se interligarobter dados provenientes de aplicativos baseados em SIF. A ponte se adapta a uma infraestrutura de SOA baseada em padrões, que pode aumentar ao longo do tempo.

Recursos

Aprender

Obter produtos e tecnologias

  • Obtenha a especificações SIF.
  • Versão de teste do software IBM: Avalie os produtos de software da IBM da maneira que for melhor para você. De downloads de avaliação a produtos hospedados em nuvem, o developerWorks tem softwares especialmente para desenvolvedores.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado, WebSphere
ArticleID=834851
ArticleTitle=Schools Interoperability Framework e SOA
publish-date=08312012