Desenvolvimento ágil e ESBs

votos
1

Eu estou trabalhando em mudar o nosso paradigma tecnológico corporativo para desenvolvimento ágil. Tem sido um processo difícil, mas estamos quase lá! :)

Temos sistemas legados para a nossa administração de banco de dados (para ser usado Access, agora portado para .NET e MS SQL) e estamos desenvolvendo uma estrutura para nossa visão de futuro. Queremos migrar, tanto quanto possível para a web. Mas queremos integrar o sistema atual com o próximo um. Nós não será sobreposição de tarefas e funcionalidades.

Minha visão é mover todas as informações de contato de nossos usuários para um banco de dados diferente, ligando esses perfis de volta para o MS SQL para sua história e informações contábeis. Nós vamos manter todos os sistemas de contabilidade no aplicativo de desktop, mas há muito mais funcionalidades que estamos prestes a adicionar que dependem fortemente da web, especialmente Ruby on Rails.

Eu acho que a pergunta é: por ESBs? Existe uma maneira de criar um SOA sem ir entusiasta com sistemas de ESBs complexos. A idéia é beijar qualquer maneira. a SOA pode ser criado de uma forma que permite que o desktop / web / mobile ser as interfaces, mantendo as funcionalidades na lógica de negócio (é claro que algumas funcionalidades teria de ser implementada na interface, mas mantendo que a um mínimo). E não ESBs mesmo caber uma filosofia Agile? Quanto mais eu leio e estudá-los, menos eu penso assim! : /

Obrigado por seus pais de entrada! Se você precisar de mim para esclarecer, apenas fazer algumas perguntas e eu vou fazer o meu melhor para fazê-lo! :)

Publicado 09/12/2008 em 23:51
fonte usuário
Em outras línguas...                            


3 respostas

votos
3

ESBs se encaixam bem com ágil assim que o enquadramento / infra-estrutura está em vigor. Você vai achar que você pode criar um novo sistema em pedaços, executar as novas peças em paralelo com o sistema antigo por um tempo, e gradualmente desligar as velhas partes do sistema até que apenas o novo sistema é deixado, e ninguém vai nunca sabe a diferença

um SOA básico apenas define os serviços em vez de aplicações; um ESB administra os serviços em canais para esconder os pontos finais, fazendo atualizações e substituições muito mais "ágil"

Respondeu 10/12/2008 em 00:24
fonte usuário

votos
1

Eu aprendi rapidamente a se coíbe do termo "ESB", como itis muito sobrecarregado e significa coisas diferentes para pessoas diferentes (e às vezes coisas diferentes para a mesma pessoa :-))

A coisa chave, naturalmente, é de se perguntar o que é que você realmente necessita.

Envolvendo seu banco de dados (s) como um serviço é susceptível de ser uma escolha sábia, especialmente se você tiver vários clientes para esses dados; você terá que gastar uma boa quantidade de tempo pensando sobre seus contratos e escopo, mas ágil pode ajudar muito aqui.

A questão agora é como é que estes serviços são chamados, e eu acho que você precisa pesar a probabilidade de clientes e serviços de mudança e como o sistema vai evoluir.

Um autocarro de serviço ajuda a mascarar os serviços do seu cliente (que pode ser outros serviços) e este "mascarando" pode relayte à localização, protocolo, formatos, códigos, etc. algumas formas de um ônibus serviço também manter o itinerário (que precisa ser chamado, e quando), mas eu geralmente não gostam da idéia.

por isso - a pergunta que você precisa perguntar a si mesmo em primeiro lugar, penso eu, é o que você precisa para começar com e quanto investimento inicial você está desejando fazer (e pode justificar)

Por exemplo, se inicialmente você está feliz com uma abordagem mais ponto-a-ponto, os clientes podem ligar para o serviço diretamente; numa fase posterior, como o serviço evolui, você pode introduzir o "homem médio" para intermediar a solicitação e resposta (sim - você pode chamá-lo de ESB, se quiser).

Alternativamente, você pode começar com um "homem médio" básico, de modo que os clientes nunca chamar o serviço diretamente, mas tem apenas os recursos que você precisa para começar e expandir as suas capacidades como forma de requisitos; ele pode muito bem começar como sendo uma máquina de encaminhamento simples.

Idealmente, você iria construir em cima de um produto que tem muitas capacidades construídas em; BizTalk Server é uma boa matchif você estiver em MS pilha (mas tem a sua curva de aprendizagem)

so - desculpas se isso não é uma resposta muito concreta - mas eu acho que o meu ponto principal é que "ESB" não tem que ser um exagero, ele simplesmente se resume ao que você deseja ter em um dia, e ágil (e SOA ) definitivamente ajuda, permitindo-lhe evoluir gradualmente, em vez de qualquer coisa big-bang como.

(Se alguma coisa acima é um disparate completo ou apenas um pouco claro que é devido à falta de sono com um recém-nascido em casa! Desculpas :-))

Respondeu 10/12/2008 em 11:40
fonte usuário

votos
0

Toda a migração é o que me levou a ESBs ... Mas toda a ideia de um ESB parece maneira de complexo para resolver um problema que envolve cerca de 30.000 perfis! Estamos à beira de algum crescimento exponencial (com alguns milhões de perfis) e talvez a partir de um novo caminho seria melhor. Como é fácil para ligar uma entrada que se senta em um banco de dados MySQL com os dados armazenados no MS SQL DB? Eu não quero dupla entrada, obviamente, mas pode haver uma maneira mais ágil do que um "todo" ESB ... eu entendo que uma SOA com um ESB pode ser bastante ágil em termos de atualizações e substituições mas seria um exagero? :)

Respondeu 10/12/2008 em 00:41
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more