A orquestração é uma responsabilidade do ESB?

Question

É um ônibus de serviço corporativo (Uma ferramenta que atua como mediadora, corretor de mensagens, facilitador de serviço, intensificador de transformação de esquema, provedor de localização transparente, agregador de serviços, balanceador de carga, monitor e tudo isso) responsável por orquestrar serviços?

Que tal colocar um processo de negócios automatizado com mais de mil etapas e dezenas de invocações de serviço dentro do seu barramento de serviço corporativo?

Você faria isso, ou usaria um especialista em orquestração, como um mecanismo BPEL?

Por favor me dê uma opinião.

Answer 1

Sim e não. Há uma linha fina e às vezes indistinguível entre orquestração e aumento de agregação/serviço.

Em geral, se você tem algum processo de negócios de longa duração ou complexo (o processo é a palavra -chave, embora eu evite defini -lo) - isso é mais adequado para o BPEL.

Tarefas simples, como agregar os resultados de três chamadas de serviço, podem e muitas vezes devem ser realizadas em uma camada ESB.

Não vale a pena perder muito sono, embora

Isenção de responsabilidade: Sou consultor da IBM ESB, embora não esteja escrevendo isso em uma capacidade oficial.

Answer 2

Não, a responsabilidade de um ESB não é a orquestração de serviços (por si só). O ESB fornece uma camada de abstração no "nível de infraestrutura de software".

Isso significa que um ESB é uma "porta abstrata lógica única de chamada para conectividade" com qualquer serviço publicado no barramento.

O ESB é abstrato, significa que os consumidores de serviços no ônibus "não precisam saber" detalhes da implantação do serviço e é possível expor "serviços de enfrentamento internamente" com um modelo de documento único. O ESB fornece serviços de baixo nível (como tradução de protocolo e transformação de mensagens), para que os serviços internamente possam se comunicar de maneira simplificada.

Isso implica alguma orquestração: o ESB fornece orquestração dos serviços de baixo nível mencionados acima (por exemplo, quando o serviço x é chamado via IIOP, traduza isso em SOAP com anexos. Em seguida, transforme a solicitação de quaisquer dados serializados em uma carga útil XML).

A orquestração que você normalmente evitaria em um ESB é: para processar essa venda (seguros), primeiro precisamos validar as informações fornecidas pelo comprador, depois precisamos subscrever o risco de garantir e, finalmente, calcular o prêmio que precisa Para ser pago pelo seguro, após o que precisamos ... etc.

As etapas descritas acima são claramente um processo de negócios (que pode até ser interrompido ... por exemplo, se a subscrição automática não for possível, um subscritor humano precisa avaliar ainda mais o risco).

Serviços de negócios (por exemplo, validação, subscrição, cálculo do prêmio) que compõem um processo de negócios (por exemplo, venda de seguros), que é o que normalmente é referido como orquestração, é mais adequado para acontecer em um mecanismo de processo de negócios e definido usando um processo de negócios formalizado Linguagem de modelagem (como BPEL).

Também adivinhe as muitas etapas do seu processo: no exemplo acima, a validação é um serviço (de granulação do curso). As próprias regras de validação são internas a esse serviço. Para regras de negócios complexas (ou seja, processos de negócios), o uso de um mecanismo de regras de negócios pode ser necessário.

Answer 3

Minha resposta curta rápida é não, que não é sua responsabilidade.

Prefiro deixar isso para o BPEL ou uma suíte BPM.

Mhh eu não sei o que mais adicionar :) ... boa sorte?

Answer 4

Agora minha própria visão.

Em relação a todo o trabalho que um ESB precisa fazer, colocar a orquestração de serviços dentro do principal elemento de infraestrutura do seu SOA não é uma boa ideia.

Agregado, ok! Mas manter seu canal de comunicação ocupado com a lógica de negócios, com certeza, causará um impacto terrível na capacidade de entregar outros recursos.

Afinal, A maioria dos ESBs como o serviço aqualógico de bea tem um Suporte limitado para orquestração Incluindo Falta de Estado Recursos e atividades como Wait (um temporizador) ou Pick (aguarde alguma entrada para mover o processo), recursos de divisão/junção (já adicionados no ALSB 3.0) e assim por diante.

Sem chance. Basta usar ferramentas como um mecanismo BPEL ou uma ferramenta como a integração WebLogic.

Obrigado.

Answer 5

Sempre que você tem dois ou mais serviços que interagem o uso de serviços de serviço, ou seja, para serviços de controle e controle de processos. Se você tiver o ESB, exponha este serviço de composição no ESB. Agora, se você precisar compor um novo serviço que inclua este Orchestrator de Uso do Serviço de Composição e exponha novamente no ESB. Use ESB como mecanismo de entrega de serviço e corretor de serviços da Web e proxy. Na composição de um orquestrador de serviço, usará o ESB para alcançar serviços de interação. Se esses serviços de interação usarem esquemas XML incompatíveis, poderão transformá -los/mapear em esquema comum em tempo de execução e rota as solicitações de serviço com base no conteúdo, por exemplo, namespace.

Answer 6

Sim, a orquestração é uma responsabilidade, na maioria dos casos, do ESB. Ou, alternativamente, se você desenhar uma linha entre o ESB Infra e a Orquestration Infra, o fará em um nível físico por razões de desempenho, não por atribuição lógica de responsabilidade.

Você tem duas opções - quando, por exemplo, um sistema de RH recebe um novo funcionário - onde você coloca a lógica de negócios que diz que "o departamento de conformidade precisará aprovar e verificar primeiro, e depois se estiver tudo bem, o departamento de RH precisará Para finalizar o aluguel, o departamento de contabilidade precisará de uma nova entrada e, em seguida, o sistema de folha de pagamento precisará de atualização e, se isso falhar, precisaremos enviar um email para o RH "? Se todos os processos de negócios forem considerados "pertencentes" ao departamento/aplicação inicial, o sistema geral que é a empresa se tornará complexo, com sistemas de orquestração díspares.

A segunda opção é centralizar a orquestração, essencialmente tornando -o um parceiro lógico da plataforma de mensagens. Se você optar por vê -los como artefatos separados, isso depende de você, mas é igualmente válido descrito como ESB.

Answer 7

Um barramento de serviço corporativo nunca deve ser responsável pela orquestração de serviços.

A orquestração implica um mínimo de "inteligência", especificamente a capacidade de compensar transações com falha. As ferramentas de barramento de serviço costumam dizer que oferecem "Try-Catch" ou algo assim, mas a capacidade de executar a comtonação com escopo é a marca de uma ferramenta de orquestração adequada. Além disso, a capacidade de esperar, conhecer seu próprio estado ou manter as coisas em suspense é outro indicador de que você está lidando com um orquestrador e não com um ônibus.

Falando a mais de 1000 etapas mais dezenas de serviços, considere o IF-Then no processo. Se todas as instruções IF-then em suas 1000 etapas falarem apenas com o roteamento sem alterações nas cargas úteis, você ainda estará em "roteamento" e, portanto, ainda no ESB. Mas se houver um aninhado Se-então e eu começamos a procurar ferramentas diferentes. Além disso, se isso parece que o roteamento pode impactar rapidamente a lógica de negócios. Quando a lógica de negócios começa a aparecer, um idioma melhor, como BPEL ou BPMN, é melhor.

O exemplo de um condutor de orquestra é frequentemente dado para descrever como a orquestração funciona, um indivíduo central direcionando os músicos de acordo com uma partitura. Muitas vezes, o que deixa de lado é a ideia de que o condutor não está apenas direcionando, mas também ouvir, e se algo der errado pode compensar de uma maneira confiável e repetível.

Por exemplo, imagine que nosso primeiro condutor vai trazer o jogador da Tuba, mas disse que o Tuba Player decidiu fazer outra coisa. Um simples "orquestrador" em estilo pinball trará a seção de tuba, sabendo muito bem que não está lá e, em seguida, aguarde o público reclamar mais tarde. Um condutor realmente experiente veria o tuba desaparecido e imediatamente trazia os chifres barítono mais profundos para compensar.