Particularidades na execução de projetos com integrações – Parte Final

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

Particularidades na execução de projetos com integrações – Parte 2

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!

Uso do MDS (MetaData Service) no Oracle SOA Suite

O Oracle SOA Suite, solução da Oracle para integração de sistemas e automação de processos, na sua versão 11g, trouxe muitas novidades, se compararmos com a versão 10g. Uma delas foi o MDS, ou o MetaData Service. Nesse post vamos falar sobre ele, procurando esclarecer para que serve e como utilizá-lo.

Definição
O MDS é um repositório unificado para armazenamento de arquivos (metadados) usados nos projetos do SOA Suite. Quando, por exemplo, um projeto BPEL ou BPM é implementado (deploy) os seus arquivos são armazenados no MDS.

Além disso, é possível utilizar o MDS para outros fins, como, por exemplo, compartilhar artefatos comuns entre os vários projetos, sejam eles schemas XML (XSD), arquivos EDL, DVM ou WSDL.

Porque usar o MDS para artefatos comuns?
O MDS provê maior segurança e melhor manutenção dos artefatos comuns aos projetos do SOA Suite. Existe total compatibilidade com o JDeveloper (IDE de desenvolvimento) para visualizar o conteúdo do repositório e total compatilidade do EM para a sua manutenção.

Um exemplo de situação que justifica o uso do MDS é quando um arquivo XSD é compartilhado por vários projetos, o que ocorre com certa freqüência quando utilizamos modelos canônicos. Ter uma cópia desse arquivo em cada projeto pode gerar um problema de manutenção (pensemos que, cada nova versão do arquivo deveria ser replicada 10, 20 vezes, dependendo da quantidade de projetos envolvidos na integração). Se utilizamos o MDS, os projetos envolvidos farão uma referência para ele no repositório e, sempre que o arquivo XSD for atualizado, automaticamente todos os projetos também estarão atualizados.

Como utilizar o MDS
Existem duas versões do MDS: uma armazenada em forma de arquivos e outra registrada no banco de dados (servidor). A primeira é usada para o desenvolvimento e pode ser salva, por exemplo, num repositório subversion (GIT, SVN, CVS, TFS, etc), de forma que todos os desenvolvedores tenham acesso ao conteúdo.

A versão do banco de dados, por sua vez, será aquela utilizada pelo servidor SOA Suite, que estará rodando sobre um server Weblogic. Assim será necessário implementar (deploy) o conteúdo dos arquivos no banco de dados para que o servidor tenha acesso ao conteúdo atualizado pelos desenvolvedores.

Cada projeto utiliza um padrão próprio para implantação (deploy) dos projetos no servidor SOA Suite. Esse artigo explica como criar a árvore de arquivos e como atualizar o MDS da maneira nativa, ou seja, via JDeveloper.

Uma vez que o MDS esteja configurado e com o conteúdo armazenado, a referenciação dentro do projeto é bastante simples, bastando informar, na localização, o caminho completo dentro do MDS e incluindo o prefixo oramds. Veja no exemplo:

  • Para referenciar o XSD que está no caminho apps/MyCannonical: oramds:/apps/MyCannonical.xsd
  • Para referenciar um WSDL:

 

Utilizar o MDS em projetos SOA Suite é uma opção de arquitetura que pode simplificar muito o desenvolvimento. Porém, é necessário que exista um forte controle das atualizações dos arquivos locais e do banco de dados. Trabalhar com multi-desenvolvedores também pode causar algum tipo de transtorno caso isso não ocorra.

Podem haver problemas, também, no uso compartilhado do conteúdo do repositório. Indispensável dizer que deve haver uma preocupação muito grande quando esses artefatos forem atualizados, evitando incompatibilidade com outros projetos.

Quando usar o OSB, Oracle BPEL ou Oracle BPM

Estivemos presentes no Oracle Open World Brasil 2012 e tivemos a oportunidade de ter uma agradável conversa com um consultor da Oracle sobre uma dúvida recorrente entre os nossos clientes. Por mais que saibamos para ‘que serve’ cada produto, muitas vezes, em projetos de automação de processos e de integração de sistemas, existe a dúvida: quando utilizar OSB, Oracle BPEL e Oracle BPM?

Usando do expertise da iProcess e da Oracle buscamos alguns pontos que podem ajudar na tomada de decisão. São eles:

  • BPEL e BPM possuem a auditoria completa da execução da instância de orquestração e do processo automatizado. Assim, se o serviço precisa de auditoria, sugere-se escolher um deles. OSB não tem esse requisito.
  • O seu projeto vai produzir eventos que irão ser integrados ao Oracle BAM? BPEL e BPM possuem esse recurso e o desenvolvimento é rápido e fácil com ele. OSB, não.
  • É necessário utilizar o error hospital, incluindo a ressubmissão de mensagens etrace completo no caso de erro? Essa também é uma característica do BPEL e BPM.
  • BPEL/BPM são stateful (guarda o estado do processo) e OSB é stateless (não guarda o estado do processo). Ou seja, caso seja necessário ter uma execução de longa duração (de alguns minutos a vários dias) que aguarde eventos intermediários e tome decisões baseado no estado atual do processo e mais os dados do evento recebido, deve-se utilizar BPEL/BPM. Caso a execução leve apenas alguns segundos e todas as decisões ocorram apenas com base nos dados recebidos no momento da chamada, pode-se utilizar OSB. Para saber mais sobre stateless/stateful, veja esse artigo.
  • O projeto prevê a existência de tarefas humanas? Opte por BPM. O BPEL também é uma alternativa (já que a infraestrutura do SOA Suite é a mesma para ambos). OSB não possui esse recurso.
  • Entre BPM e BPEL, qual escolher? Ambos são ótimas soluções. No caso de não haver grande diferença entre um e outro, hoje em dia sugere-se utilizar o BPM pela simplicidade no aprendizado e na pouca quantidade de código envolvido. O BPEL ainda necessita um conhecimento mais aprofundado de XML e seus correlatos. Outro ponto é que BPM usa BPMN como notação para representar o fluxo do processo, que é muito mais facil de ser compreendida pelo negócio tanto no desenho do processo a ser automatizado quanto no acompanhamento da execução das instâncias.
Certamente muitos outros aspectos devem ser considerados nessa tomada de decisão, incluindo o tempo de processamento do serviço, se ele será síncrono ou assíncrono, etc. Mas os pontos acima podem ser úteis para, ao menos, eliminar uma ou outra opção.
(Com a contribuição de Leonardo Fagundes, Kelly Sganderla e Rafael Andrade).

Oracle SOA Suite 11g: uso da atividade assign no BPEL

Trabalho com desenvolvimento BPEL há alguns anos utilizando o produto da Oracle, o SOA Suite, e tenho acompanhado a sua evolução desde a versão 10g, incluindo a IDE de desenvolvimento, o JDeveloper.

Recentemente estive envolvido em um projeto e precisei utilizar em diferentes contextos o componente assign. Nas versões mais recentes do produto existe uma sensível diferença na interface para realizar as atribuições e isso me motivou a escrever esse post, na tentativa de destacar e exemplificar o uso do copy e das suas regras: copy listappend, insert after e insert before.

Nos exemplos abaixo utilizei uma VM produzida pela Oracle (disponível aqui) e configurada com:

Oracle Enterprise Linux (64-bit) EL 5 Update 5
Oracle XE Database 11.2.0
Oracle SOA Suite 11.1.1.6.0 (includes Service Bus)
Oracle BPM Suite 11.1.1.6.0
Oracle JDeveloper 11.1.1.6.0
JRockit R28.2.0-79-146777-1.6.0_29s

O valor de input utilizado nos testes foi:

<inputVariable>
    <part  name="payload">
        <ns1:OrdemServicoRequest xmlns:ns1="http://xmlns.oracle.com/DDM">
            <ns1:CodigoOS>123</ns1:CodigoOS>
            <ns1:DataAberturaOS>22/09/2012</ns1:DataAberturaOS>
            <ns1:TipoOS>OS</ns1:TipoOS>
            <ns1:StatusOS>Iniciado</ns1:StatusOS>
            <ns1:DataEncerramentoOS>25/09/2012</ns1:DataEncerramentoOS>
            <ns1:Codigocliente>12114</ns1:Codigocliente>
            <ns1:NomeCliente>José da Silva Sauro</ns1:NomeCliente>
            <ns1:EnderecosCliente>
                <ns1:EnderecoCliente>
                    <ns1:Rua>Rua 1</ns1:Rua>
                    <ns1:Numero>2</ns1:Numero>
                    <ns1:Complemento>Bairro 3</ns1:Complemento>
                    <ns1:Cidade>Longe de Tudo</ns1:Cidade>
                    <ns1:Estado>Algum</ns1:Estado>
                    <ns1:CEP>01000-000</ns1:CEP>
                </ns1:EnderecoCliente>
                <ns1:EnderecoCliente>
                    <ns1:Rua>Rua 2</ns1:Rua>
                    <ns1:Numero>3</ns1:Numero>
                    <ns1:Complemento>Bairro 4</ns1:Complemento>
                    <ns1:Cidade>Perto de Tudo</ns1:Cidade>
                    <ns1:Estado>Nenhum</ns1:Estado>
                    <ns1:CEP>02000-000</ns1:CEP>
                </ns1:EnderecoCliente>
            </ns1:EnderecosCliente>
            <ns1:EmailCliente>jose@sauro.sil</ns1:EmailCliente>
        </ns1:OrdemServicoRequest>
    </part>
</inputVariable>

 

  • Uso tradicional do copy

O uso tradicional do copy serve, entre outras coisas, para atribuição de valores para variáveis à partir de outras variáveis ou funções pré-definidas no produto (expression).

Copy tradicional

Nesse caso temos o uso do assign com o copy tradicional. Cada campo utiliza uma solução diferente: atribuição direta de variável, atribuição de valor textual e utilização de uma função pré-definida do produto (no exemplo, current-dateTime()).

O retorno dessa atribuição será:

Copy tradicional - resposta

Resultado da execução

 

  • Uso do append

O append irá inserir um elemento ao final da lista, sem alterar o conteúdo já existe. Veja o exemplo abaixo.

Nesse exemplo foi criado um elemento para ser inserido na lista de status. Depois de alimentar as informações com valores válidos, foi incluído o elemento na lista de status com a regra append.

O resultado da lista, nesse momento do exemplo, são dois elementos.

Esse é o resultado da lista com o elemento incluindo no append.

 

  • Uso do copyList

A regra copyList tem por característica eliminar todos os elementos que já existirem na lista de destino e substituir integralmente o seu conteúdo, incluindo elementos e atributos.

No nosso exemplo incluímos um terceiro assign, depois dos dois assigns dos exemplos acima, com a regra copyList. Note que o array destino continha, até então, dois elementos. Os dois foram excluídos e um novo elemento será incluído, conforme exemplo. Para deixar claro o exemplo, incluímos dois elementos utilizando o copyList. O valor final do array irá conter somente o segundo valor inserido.

copyList assign

Observe que foram incluídos 2 novos elementos usando o copyList. Somente o segundo irá aparecer no array, já que a função copyList tem por princípio eliminar todos os elementos do destino antes de alimentar a variável com os novos valores.

O resultado final da lista conterá somente o segundo elemento inserido.

copyList response

O resultado do exemplo depois do uso do copyList no último assign.

 

  • Uso do insertBefore e insertAfter

O nosso último exemplo é para demonstrar o uso do insertBefore e insertAfter. O primeiro irá incluir um elemento antes do elemento assinalado no destino e o segundo, depois.

Nesse ponto do exemplo temos somente 1 elemento na lista. No último assign incluímos dois novos elementos: um utilizando insertBefore e outro utilizando insertAfter. Veja abaixo o resultado desse array.

O resultado final da lista será:

O resultado da lista com os valores incluídos antes e depois do elemento que já estava na lista.

 

A atividade assign é uma ótima opção para atribuição de valores às variáveis, muitas vezes eliminando a necessidade de uma transformação. Conhecer bem as suas regras ajuda a tirar proveito de todos os recursos envolvidos.

Um detalhe, por experiência de projeto, é que essa janela pode se tornar muito lenta no caso de utilização de schemas (XSD) que ficam armazenados em servidores remotos e no MDS. Esperemos que isso melhore nas próximas versões do produto.

O projeto utilizado no exemplo está disponível para download no link abaixo:

  • [download id=”1″]

Orquestrar é uma arte

Recentemente perdi o sono com um pensamento que me intrigou positivamente. Fiquei impressionado por ter constatado algo tão simples e, ao mesmo tempo, tão interessante.

Trabalho com orquestração de webservices há mais de 2 anos. Também sou músico amador há pelo menos 25 e talvez, até o momento, eu nunca tivesse feito uma relação entre as duas coisas.

Ora, a coisa é simples! Imaginemos uma orquestra musical. Nela, o maestro é responsável por determinar o tempo da música, o seu pulso. Os gestos que ele faz determinam a textura da música, ou seja, se as notas vão ser mais suaves ou mais duras; e a amplitude da regência determina o volume (forte ou piano), quando a música deve crescer e quando deve diminuir; em suma, a interpretação dinâmica.

Além disso o maestro é quem dá as entradas para os músicos (já que nem todas as músicas começam e terminam com todos os instrumentos tocando ao mesmo tempo) e também determina o fechamento da música de forma que todos os músicos possam parar de tocar na hora certa.

A maioria dos maestros faz uma regência bem parecida, mas as diferenças são adaptáveis, dependendo do seu costume e dos ensaios.

O maestro, porém, não pode fazer tudo sozinho. Ele é o ‘regente’ e é quem deve ter a capacidade de contagiar sua orquestra. Mas não é ele que, no fim, irá gerar o som… É aí que entra o papel dos músicos e dos seus instrumentos. Se os músicos são bons o resultado é fabuloso!! Igualmente, se os músicos são limitados, não há maestro que faça milagres… E, por mais fantástico que seja um instrumento, se o musicista não é tão competente assim, o resultado pode ser desastroso. E vice-versa.

Se não bastasse, ainda devemos pensar em utilizar o instrumento certo para a tarefa certa, e este deve estar devidamente afinado. Não posso utilizar uma flauta no lugar de um baixo, por exemplo.

Algo semelhante ocorre na orquestração de sistemas. A orquestração é capaz de integrar sistemas de forma melodiosa e harmônica. Ela dita o ritmo da integração, invocando o serviço certo no momento certo, informando as entradas de cada serviço. Mas esse ‘maestro’ é totalmente dependente do serviço, o nosso músico, ao ponto de limitar-se à tarefa de realizar uma requisição e obter ou não uma resposta.

Esse exemplo também nos ajuda a visualizar os papéis envolvidos num processo de orquestração. Se pensarmos que a orquestração é como o maestro e os serviços são como os músicos, fica muito claro entender a separação entre a lógica da orquestração e a lógica de negócio: assim como o maestro não toca nenhum instrumento, a lógica de negócio não deve ser implementada junto com a lógica de orquestração e sim em serviços separados para serem orquestrados.

É fundamental, também, escolher o instrumento certo para tocar o trecho correto. O instrumento errado ou desafinado pode comprometer toda a orquestração, toda a peça. Da mesma forma que o serviço chamado na hora errada poderá comprometer os resultados da orquestração.


Chego à conclusão que orquestrar é uma arte!! E é por isso eu tenho tanto prazer em desenvolver esse tipo de trabalho!