Introdução

Em termos de importância, uma das áreas de complexidade mais comumente subestimadas em uma solução de TI é a integração com sistemas de backend. A despeito dos esforços da arquitetura orientada a serviço (SOA) para padronizar e simplificar o modo pelo qual acessamos sistemas de backend, cada novo projeto traz inevitavelmente novos pontos de integração ou, pelo menos, aprimoramentos às integrações existentes.

Este artigo de duas partes apresenta um modo para capturar e analisar a complexidade de integração usando as características da interface para melhorar sua capacidade de planejar, designar e, por fim, implementar soluções que envolvam integração.

A parte 1 inclui:

• Apresentação das características da interface: Um olhar sobre a amplitude das informações necessárias para realmente compreender a complexidade de uma interface.
• Integração no SOA e BPM: Por que a integração é muito importante para iniciativas de arquitetura como a SOA e o BPM.
• Análise da interface iterativa: Porque seria impraticável capturar todas as coisas sobre todas as interfaces em uma solução em uma única passada, esta seção aborda que características capturar, em que estágio no projeto e por quê.

A parte 2 se aprofundará em cada uma das características individuais da interface em detalhes.

Voltar para parte superior

Apresentando as características da interface

Com a abordagem descrita nestes artigos para analisar sistematicamente os requisitos de integração e os recursos de sistemas backend, você será capaz de fazer apenas as questões apropriadas em cada análise e estágio de design para garantir efetivamente a identificação de riscos e, por fim, a escolha dos padrões de design apropriados para obter a integração desejada na solução.

Essa técnica se concentra na captura interativa das características principais da interface que têm o maior efeito sobre o design e implementação. No caso simples de um solicitante conectando-se diretamente a um provedor, as características da interface são as características do provedor, conforme mostradas na Figura 1.

As características da interface foram apresentadas em resumo em muitas conferências internacionais e gradualmente afinadas nos projetos do cliente por muitos anos, mas esta é a primeira vez que elas foram documentadas completa e publicamente. O conjunto completo das características principais é mostrado na Tabela 1 (essas serão descritas em detalhes na Parte 2).

Felizmente, o escopo dessas características esclarece imediatamente a razão de diversos projetos falharem ao avaliar a integração efetivamente. Não há dúvida de que seria uma experiência significativa capturar e avaliar uma grande quantidade de informações de uma vez. Mais tarde, você verá como tudo isso pode ser dividido em etapas gerenciáveis.

A Figura 2 mostra que há realmente dois conjuntos de características de interface a serem capturadas. O conjunto à direita inclui os recursos do provedor, mas também é necessário conhecer os requisitos do solicitante.

À medida que você compara as características do solicitante e do provedor, poderá estabelecer os padrões de integração que serão necessários para resolver as diferenças, como ilustrado na Figura 3.

Voltar para parte superior

Integração no SOA e BPM

Poucos projetos são executados em isolamento completo. Quase sempre, todo projeto é parte de uma iniciativa corporativa mais ampla. Duas iniciativas comuns em anos recentes foram a arquitetura orientada a serviços (SOA) e o gerenciamento de processos de negócios (BPM). É importante compreender por que as características da interface são críticas para os trabalhos maiores e como elas podem ser aplicadas de modo relevante.

SOA

SOA é um tópico vasto, mas o aspecto dela que se aplica aqui é quando ela é vista como uma extensão lógica de integração tradicional; tomando técnicas de integração existentes e dando um passo adicional para torná-las verdadeiramente reutilizáveis em um conjunto mais amplo de solicitantes. A diferença importante para essa discussão é que a integração tradicional atende a um conjunto conhecido de solicitantes para os quais você executa a integração explícita. Isso é mostrado no exemplo acima, na Figura 4. Não considere, portanto, as necessidades dos futuros solicitantes em potencial. Padrões como "hub and spoke" simplificam a apresentação de novos solicitantes, mas cada um deles requer integração explícita. A SOA dá um passo além buscando avaliar quais serão as interfaces mais úteis e trazendo tais interfaces à tona, como serviços, pela padronização do modo como elas são descobertas, como mostrado na parte inferior da Figura 4. O objetivo é que os solicitantes futuros possam simplesmente "usar" o serviço em vez da obrigação de integrá-lo.

Agora, vamos examinar simplesmente com é importante compreender as interfaces nessa situação.

Para expor serviços efetivamente, é necessário conferir as características da interface dos solicitantes antecipados para o seu sistema (a e b na Figure 4), além de estimar os futuros solicitantes potenciais (c). Compare isso com as interfaces disponíveis nos provedores (e). A parte mais difícil vem a seguir, quando é necessário usar todas as informações e definir o "serviço" idealizado que pode ser exposto para reutilização. Isso é mostrado na Figura 4 como características de exposição de serviço (d). Essas características quanto aos propósitos podem ser consideradas essencialmente idênticas às características da interface, exceto que elas se referem a um serviço exposto. Há diferenças, principalmente no sentido que muitas das características são definidas pelas políticas de controle da SOA, mas esse detalhe não é importante nesse nível.

Agora, imagine se você fizer esse exercício sem todas essas características da interface. Seria possível começar um caminho longo em seu projeto acreditando que, em um nível elevado, você teria uma solução viável, apenas para descobrir durante a implementação que algumas características fundamentais negam completamente o potencial de reutilização do serviço.

Evidentemente, talvez você não esteja no início de uma iniciativa SOA. Muitos serviços já podem ter sido expostos. Se esse for o caso, talvez seja possível fazer algumas suposições mais simples sobre quão fácil é para os seus solicitantes se conectar aos provedores, mas é necessário testar tais suposições primeiro. Um meio de avaliar isso é compreender o nível de maturidade em que a SOA se encontra em relação ao Service Integration Maturity Model (SIMM) como descrito pelo artigo referido acima. Por exemplo, se as interfaces trouxerem "serviços controlados" à tona baseados em SOA, a empresa atingiu o SIMM nível 4 (para tais interfaces, pelo menos) e, portanto, poderá presumir que tais interfaces devem ser fáceis de reutilizar. No entanto, não subestime a dificuldade de prover serviços bem controlados. É praticamente certo que algumas das interfaces estarão em um nível inferior, são nessas interfaces que você precisará se concentrar nas fases posteriores.

Igualmente importante, não presuma, simplesmente porque uma iniciativa SOA está em andamento, que todas as interfaces precisam se tornar serviços controlados completamente expostos; normalmente isso seria muito caro para a maioria dos projetos. Será necessário avaliar cada um deles quanto a sua oportunidade de reutilização. Um mecanismo que é possível usar para executar essa avaliação é o SOMA Litmus Test (consulte Recursos).

BPM

Como com a SOA, o BPM também é um tópico amplo, mas o aspecto do BPM que se aplica aqui é como os processos de negócios interagem com sistemas backend ou provedores.

A Figura 5 mostra que um processo de negócios de ponta a ponta pode interagir com vários sistemas de muitos modos diferentes. Há um número de coisas a se observar nesse diagrama.

Primeiro, porque o processo não deve, em condições ideais, conhecer os detalhes de como se integrar com cada um dos sistemas backend individualmente, o diagrama mostra apenas uma camada de serviço lógico, ocultando o detalhe da integração real necessária para obter os sistemas backend. Assim, a SOA pode claramente ser complementar ao BPM, criando os pontos de integração necessários pelo processo mais facilmente disponível.

Segundo, observe como o tipo de solicitante do serviço muda regularmente no decorrer do processo. As solicitações podem vir de uma interface gráfica com o usuário, de dentro de uma composição breve, de um processo assíncrono de longo prazo, e assim por diante. Cada um desses solicitantes prefere características de integração diferentes nos serviços que chama.

Terceiro, observe como as características de integração "preferidas" variam para tipos de implementação de processo diferentes. Vamos examinar apenas uma seleção da característica da interface entre essas interações, especificamente em torno do tipo de interação e transacionalidade (os números na lista abaixo correspondem aos que aparecem na Figura 5):

1. Leitura não transacional de solicitação-resposta síncrona
2. Atualização de solicitação-resposta síncrona não transacional
3. Leitura de solicitação-resposta síncrona com bloqueio de transação
4. Resposta-solicitação síncrona com atualização transacional
5. Evento fire-forget assíncrono
6. Evento assíncrono com dados de correlação
7. Recibo de evento assíncrono com dados de correlação
8. Atualização de solicitação-resposta assíncrona

É possível ver que cada interação tem uma preferência para determinadas características. Por exemplo:

• Um fluxo por uma interface gráfica com o usuário usa principalmente interações síncronas e não espera geralmente ser capaz de combiná-las transacionalmente.
• Uma composição transacional síncrona pode requerer serviços que podem participar de uma transação global.
• Um processo de execução longo salvando estado por um período de tempo significativo pode achar que é mais fácil interagir com serviços expostos assincronamente, e também será confortável interagir em um estilo baseado em evento onde os dados são recebidos por eventos completamente separados que contêm dados de correlação.

Assim, o que você deve tirar disso com respeito à relevância das características da interface em relação ao BPM? Principalmente, você deve estar ciente de que, para o que pode parecer ser a mesma interação, as características de interface preferidas variam consideravelmente, dependendo do contexto em que a interface é usada. Por estabelecer tipos de implementação de processo mais comuns, talvez você seja capaz de melhorar significativamente a quantidade de reutilização obtida dos serviços expostos assegurando que eles exibam as características apropriadas para os usos de contexto comuns.

Um comentário final sobre a Figura 5 e sobre o BPM no geral. A Figura 5 é típica dos diagramas de processo baseado em "raia" que são normalmente usados para capturar processos para BPM, normalmente usando uma notação como BPMN (business process modeling notation), embora um diagrama BPMN não mostre normalmente mais pistas para os usuários humanos do sistema e não mostre diretamente as interações com um barramento de serviço. De fato, a Figura 5 já está provavelmente em um nível mais detalhado de granularidade em relação a um processo de negócio de alto nível que deve ser documentado. Essa representação clara de um processo de negócio, abstraída completamente do detalhe das interações com sistemas backend, é uma parte essencial do que torna o BPM tão eficiente como um modo de documentar, analisar e implementar requisitos de negócios de um modo rápido e ágil, sendo de enorme valor. No entanto, você deve se lembrar apenas de quanto dessa abstração está oculta ao chegar para integração. O diagrama do processo de negócio é apenas a ponta do iceberg quando ele chega à integração. Claramente há circunstancias quando problemas de integração podem ser menos que um problema; por exemplo, quando a maioria do processo de negócio é orientada a humano em vez de orientado a sistema, ou se houver uma SOA madura na qual desenvolver processos BPM, muitas interações devem ser mais simples de implementar. No entanto, esse não é o caso geral. Há normalmente muitas interfaces novas e complexas - ou usos diferentes das interfaces existentes - que precisam de rigor detalhado e compreensão, e você deve trazê-las à tona o quanto antes, usando características da interface para assegurar que você remova o risco da iniciativa geral do BPM.

Voltar para parte superior

Análise da interface iterativa

Como não é prático (e é impossível) capturar todas as características nos estágios anteriores de um projeto, vamos examinar como esse processo pode ser explorado iterativamente para assegurar que apenas informações suficientes sejam capturadas para informar o projeto e o design em cada fase.

A captura das características da interface deve estar alinhada às fases e iterações do projeto. Há muitas metodologias diferentes para definir projetos e cada uma usa terminologia diferente, mas por questão de simplicidade, é possível afirmar que, independente da metodologia, sempre há alguma forma de dois exercícios básicos, bem separados:

• Soluçãoao descobrir em que sistemas os dados podem ser encontrados, e que tipos de interface técnica estão disponíveis para esses sistemas.
• Design, quando você examina a forma e o tamanho das operações de dados individuais que serão exigidas pela solução.

Um projeto de cascata tradicional pode solucionar toda a passagem dependendo dos requisitos do projeto antes de mover para a próxima fase do design. Em uma metodologia mais iterativa e ágil, você solucionaria um aspecto relevante (frequentemente descrito como uma história) do problema geral, em seguida, passaria diretamente para o design e implementação desse aspecto isolado da imagem global. De qualquer forma, as duas fases existem, e é possível discutir aqui o que você deve capturar em cada estágio.

Enquanto que uma abordagem estruturada é preferida para coletar as características mínimas que devem ser capturadas em cada estágio, nada pode substituir o olho de um especialista experiente em integração, capaz de inferir das primeiras características capturadas que uma investigação mais profunda em algumas interfaces será necessária antes do que o sugerido aqui. Nas seções que seguem, sugestões são incluídas (quando possível) referentes às características que podem ser úteis antes do tempo se estiverem facilmente disponíveis.

Voltar para parte superior

Solução

Nessa fase, você está ciente dos sistemas fundamentais envolvidos na arquitetura e os dados que serão fornecidos para a solução. Inicialmente nessa fase você terá nada mais que diagramas de caixas em um quadro branco, mas até o final dessa fase, será possível ter o princípio de um catálogo de interface.

Diagrama de contexto do sistema

A esta altura no projeto, é necessário ter criado, pelo menos, um diagrama de contexto de sistema (Figura 6).

A Figura 7 enfeita o diagrama de contexto com os mecanismos de interface técnica disponível (transporte, protocolo, formato de dados) e os objetos de dados do princípio usado pelo processo para mostrar em que sistema eles residem.

Se houver muitos sistemas envolvidos, o diagrama de contexto poderá tornar-se muito desordenado; nesse caso, pode ser necessário capturar as características em uma lista separada. De qualquer forma, no final, esses dados precisarão estar na forma de lista à medida que você capturar mais características; essa lista é geralmente conhecida como um catálogo de interface.

Esteja consciente de que pode haver mais de uma opção de como interagir com um sistema. Você deve listar todas elas em vez de favorecer uma nesse estágio (Figura 8). Até que você capture o próximo nível de detalhe, não é possível saber que interfaces são apropriadas para a sua utilização. De fato, é possível usar mais de uma opção em um único processo. Por exemplo, é possível fazer consultas (leituras) usando serviços da web, mas usar JMS (com entrega assegurada) para gravações.

Normalmente você perguntaria sobre disponibilidade neste estágio. Por exemplo, se um sistema estiver inativo por duas horas por noite, talvez seja necessário colocar uma fila na frente dele para armazenar solicitações enquanto ele está inativo, ao invés de aperfeiçoar uma gravação JDBC direta.

O que as características básicas que você capturou dizem para você e o que mais você precisa saber?

• A arte do possível: Você sabe se há uma interface com cada um dos sistemas principais ou não. A identificação precoce de sistemas que não tem nenhuma interface (ou interfaces inadequadas) é parte importante do processo de solução, representando a integração de alto risco. No entanto, se tiver características identificadas para as suas interfaces, tenha em mente que é possível descobrir mais tarde que a interface não tem todas as características necessárias, além do o risco de ter de desenvolver uma nova interface ou gastar tempo aprimorando a interface existente.
• Requisitos iniciais da pesquisa: você sabe as tecnologias de interface principais que precisará usar e, com isso, que conjuntos de habilidade a equipe de projeto necessitará. Se qualquer uma dessas tecnologias for substancialmente desconhecida, será possível usar esse aviso precoce para iniciar a pesquisa e melhorar o seu conhecimento, o que será útil na próxima fase do projeto.
• Estratégia de dados: Você sabe em que sistemas os seus dados primários residem, contudo, é importante saber se eles estão presentes em mais de um sistema. Em caso afirmativo, é necessário assegurar que você compreenda se já existe uma estratégia em vigor para manter os dados em sincronização ou se ela precisa ser colocada em vigor. Colocado em outros termos, é necessário identificar qual sistema é o principal para cada item de dados (a única versão da verdade) e, se houver mais de um, como as atualizações conflitantes serão tratadas.

Em poucas palavras, você melhorou o seu entendimento da complexidade e reduziu o risco - mas, certamente, não o eliminou. O risco pode ainda ser alto, mas, pelo menos, você sabe onde ele reside. Você deve passar para um nível mais profundo, se tiver qualquer confiança nas suas estimativas neste estágio.

A análise da diferença para avaliação de risco e estimativa

No estágio de solução, ainda será necessário fornecer uma avaliação do risco envolvido no projeto e alguma estimativa de alto nível. As informações que você tem até agora não são simples o suficiente para permitir que você faça isso.

As características iniciais que você capturou no diagrama do contexto da solução (mostrado como Obrigatório na Tabela 2), consulte apenas os mecanismos pelos quais é possível trocar dados com os sistemas. Você ainda não está no nível das funções ou operações individuais que podem ser executadas através dessa interface. Por exemplo, é possível que você tenha apenas entendimento dos volumes de dados gerais que passarão por uma interface, mas não as taxas de solicitação para cada troca de dados específica. Mesmo com tais, você seria capaz de estabelecer se a interface será completamente sobrecarregada pelos novos requisitos. Você atingirá o nível completo de detalhe na próxima fase, mas haverá ainda muitos sinais de aviso precoces a serem obtidos caso um especialista experiente em integração considere (mesmo em um nível elevado) um conjunto um pouco mais profundo de características. Um conjunto sugerido de características adicionais a serem examinados é mostrado como Opcional na Tabela 2.

Talvez esteja imaginando o detalhe de onde provêm os volumes gerais de dados a serem passados pela interface . Isso requer não apenas conhecimento da interface exposta pela interface, mas também um entendimento dos requisitos do solicitante. Neste estágio, é necessário fazer mais do que simplesmente estabelecer quais interfaces os sistemas tornam disponíveis. Como você viu novamente na Figura 2, também é necessário capturar os requisitos daqueles que farão solicitações nesses sistemas.

Daqui em diante, sua captura terá tudo a ver com comparar as diferenças entre os requisitos do solicitante e a realidade oferecida pelos provedores. Essas diferenças permitirão o entendimento das complexidades de integração que você terá de superar. Por exemplo, se souber que o solicitante necessita de acesso em tempo real aos dados, mas a única interface disponível se basear em lote, então saberá que a interface provavelmente não é adequada. Se não houver nenhuma outra interface atualmente disponível, você terá de designar e implementar uma interface completamente nova. É necessário presumir que esse problema de integração será de alto risco e complexo. Por outro lado, é bom saber que já existe um serviço SOA completamente controlado para reutilização pronto para ser utilizado. Em teoria, isso deve reduzir significativamente o risco e a complexidade da integração, embora, como observado anteriormente, é necessário considerar que grau de maturidade e quão bem controlado o SOA é, antes de fazer qualquer suposição.

Finalmente, junto com as características adicionais observadas acima, talvez você deseje obter um entendimento rudimentar da granularidade das interfaces em comparação com o que é necessário. Isso é difícil, visto que você não obterá uma imagem detalhada de tal granularidade até a próxima fase. No entanto, a composição inclui complexidade significativa na integração, assim ela é um fator crítico.

Como não é possível ainda desenvolver uma estimativa sobre esses fatores adicionais em detalhe, a abordagem típica é investigar profundamente um conjunto de amostras representativas de interações e extrapolar a partir de então. Essas também fornecem a oportunidade de mitigação de risco, à medida que podem ser usadas para exercícios de prova de conceito.

Voltar para parte superior

Design

Design de interação individual

Na fase anterior, você não teve tempo de estabelecer as especificações de cada interação do sistema, exceto talvez pelos exemplos representativos criados para estimativa.

Nesta fase do projeto, você estará percebendo as interações funcionais específicas da solução formando um entendimento da troca de dados específicas que ocorrerão através das interfaces já definidas na fase de design. Essas trocas são tipicamente representadas em alguma forma de diagrama de interação de sequência, como ilustrado na Figura 9.

Os diagramas de sequência o forçam estabelecer se as interfaces do sistema fornecem as operações de dados específicas que você requer. Isso preenche implicitamente as características remanescentes na seção de dados. É importante usar a mesma técnica de análise de diferença usada anteriormente, entendendo o problema do ponto de vista do solicitante, e considerar o que o provedor tem a oferecer.

Granularidade e composição da interface

Há algumas informações importantes que brotarão da criação dos diagramas de sequência - se a granularidade das interfaces disponíveis estiver ou não corretas. É frequente o caso que o solicitante tem um requisito funcional de mais alta granularidade que a interface do provedor. Por exemplo, o solicitante requer um cliente, com alguns pedidos atuais e uma lista de detalhes de alto nível de quaisquer contas retidas. Isso pode requerer várias solicitações para um provedor e talvez vários provedores. A Figura 9 mostra um exemplo adicional de uma incompatibilidade em granularidade segundo o qual a criação e o envio do pedido devem ser combinados em uma única operação para "processar o pedido". É fácil ver porque os diagramas de sequência são tão importantes nesse estágio

Essa diferença em granularidade significa que será necessário executar a composição (várias solicitações agrupadas como uma). O design macro deve estabelecer onde essa composição deve ocorrer: no solicitante, na camada de integração ou no sistema backend em si. A decisão será baseada em um equilíbrio entre fatores como desempenho e reutilização. (Onde e como essa composição deve ocorrer está além do escopo deste artigo.)

No entanto, a importância das outras categorias, no caso de a composição ser necessária, é relevante para o conceito principal deste artigo. Eis alguns exemplos comuns:

• Se uma composição necessitar de mais de uma interação que mude dados, será necessário considerar se essas interações podem ser transacionalmente combinadas e, se esse não for o caso, como você executará o gerenciamento de erro se a solicitação falhar entre as atualizações.
• Se for necessário executar as solicitações individuais de uma composição em paralelo para satisfazer aos requisitos de tempo de resposta, você tem simultaneidade suficiente para manipular o número aumentado de conexões necessárias. E se as interfaces do sistema forem bloqueio de encadeamento, como você gerará e controlará os encadeamentos adicionais necessários?
• Se uma composição interagir com vários sistemas, como você reterá as informações de segurança separadas e qualquer outro contexto stateful, como as sessões e conexões necessárias?

Estabelecendo os padrões de integração

Depois de conhecer as operações específicas que serão executadas, é possível explorar todas as outras características no detalhe apropriado para cada operação, tanto nos termos do solicitante quanto nos recursos atuais da interface existente.

À medida que você compara as características do solicitante e do provedor, poderá estabelecer os padrões de integração que serão necessários para resolver as diferenças, como ilustrado na Figura 3. Observe que a "composição" que acabamos de discutir é, em si mesmo, um dos padrões de integração.

Nesse estágio, os padrões são definidos em um nível lógico, sem referência à tecnologia específica. No entanto, como padrões de integração comumente usados são bem estabelecidos, técnicas de implementação padrão dentro das tecnologias disponíveis também devem ser exploradas, testadas e documentadas. Isso simplificará significativamente a fase de microdesign, a seguir.

Microdesign

Na fase microdesign, você usa as características capturadas para executar aspectos específicos da tecnologia do design.

Observe que todas as características da interface são agnósticas das tecnologias de integração; elas são características lógicas. Assim, a captura das características da interface deve ter sido concluídas até o momento que você atingir o microdesign e estiver usando meramente as características para ajudá-lo nos detalhes finais do design. Uma das causas relacionadas à integração mais comuns dos projetos em execução com o orçamento estourado é a captura ineficaz das características da interface antes do microdesign, deixando problemas inestimáveis - possivelmente não resolvíveis - para esta fase ou, pior ainda, para a implementação. De longe, o problema mais comum e preocupante aqui é falhar ao avaliar e capturar uma quantia suficiente de características de dados antes do microdesign.

Cuidado com as boas intenções que visam "adicionar isso mais tarde", especialmente para características que são preocupações que têm outras implicações, como a segurança. É aceitável deferir alguma coisa somente quando você estabelecer quão complexa ela é e quão difícil será incluí-la em uma implementação em execução.

As atividades primárias nessa fase que fazem uso das características da interface são:

• Trazer precisão ao modelo de dados, por exemplo, a definição dos tipos de dados detalhados e a reestruturação dos dados necessários para representação física.
• Detalhar a implementação específica da tecnologia da integração; que recursos de tecnologia serão usados e como.
• Designar por desempenho, usando as características de desempenho para auxiliar na escolha entre várias opções de tecnologia.

Voltar para parte superior

Conclusão

Este artigo descreveu um modo mecânico de analisar os requisitos de integração usando as características da interface e abordou por que isso é de importância crítica, não apenas para integração do aplicativo corporativo tradicional, mas para outras iniciativas corporativas como SOA e BPM. Este artigo também examinou como essa técnica pode ser usada iterativamente entre o ciclo de vida de um projeto para assegurar que você tenha as informações apropriadas, no momento oportuno.

A parte 2 examinará cada característica de interface individual em detalhe para ajudá-lo a adquirir um entendimento claro do seu significado e importância.

Voltar para parte superior

Agradecimentos

Os autores agradecem os que seguem pelas contribuições e revisões deste documento: Andy Garratt, David George, Geoff Hambrick, Carlo Marcoli.

Recursos

• Barramento de Serviço Corporativo, reexaminado
  
  
• Aumentar a flexibilidade com o Service Integration Maturity Model (SIMM)
  
  
• Design de Solução no WebSphere Process Server: Parte 1
  
  
• Padrões e Melhores Práticas para Integração Corporativa
  
  
• Executando SOA: Uma Metodologia para Modelagem e Design de Serviço
  
  
• Padrões de Conectividade Corporativos: Implementando soluções de integração com produtos de barramento de serviço corporativo da IBM
  
  
• Design da solução no WebSphere Process Server e WebSphere ESB, Parte 3: Tipos de implementação de processo: Design baseados em padrão para soluções baseadas em processo
  
  
• Zona de BPM do developerWorks: Obtenha os recursos técnicos mais recentes sobre as soluções IBM BPM, incluindo downloads, demos, artigos, tutoriais, eventos, webcasts e muito mais.
  
  
• IBM BPM Journal: Obtenha os artigos e colunas mais recentes sobre soluções da BPM neste journal trimestral, disponível também nas versões Kindle e PDF.
  
  
• WebSphere no IBM developerWorks
  
  

Sobre os autores

Kim Clark é um especialista de TI do Reino Unido que trabalha no IBM Software Services para WebSphere (ISSW). Além de prover orientação a clientes, ele escreve e faz apresentações regulares sobre o design da SOA. Tem trabalhado no segmento de mercado de TI desde 1993 estendendo a programação orientada a objeto, o Enterprise Application Integration (EAI) e a SOA. Foi pioneiro de diversos projetos anteriores usando produtos SOA Foundation Suite. Kim possui graduação em Física pela Universidade de Londres, Inglaterra.

Brian Petrini é um arquiteto de TI senior da equipe de consultoria do IBM Software Services para WebSphere. Participa da prática Focused Technology do IBM WebSphere Business Integration.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Apresentando as características da interface
• Integração no SOA e BPM
• Análise da interface iterativa
• Solução
• Design
• Conclusão
• Agradecimentos
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais