Vale a pena conferir o curso SOA Adoption and Architecture Fundamentals

Vale a pena conferir o curso SOA Adoption and Architecture Fundamentals

Quando o assunto é SOA o que ouço de histórias de problemas de adoção, cancelamentos de projeto ou de como a empresa espera retomar a iniciativa, tem um sortimento tão grande que sem dúvida daria para escrever um livro.

Não é possível apontar exatamente quem é o culpado por toda essa frustração, mas posso dizer que alguns sintomas são muito comuns.

- Pensar que SOA é um produto – Muitas empresas confundem uma abordagem estrutural corporativa com a aquisição de um produto de suporte, é fácil imaginar que ao adquirir um conjunto de ferramentas para construir webservices está automaticamente desenvolvendo SOA.

- Não rever práticas de desenvolvimento – Desenvolvimento de sistemas ou desenvolvimento de integrações de sistemas são atividades totalmente conhecidas, a adoção de métodos tradicionais ou modernos de SDLC é totalemente aplicável para esses projetos, no entanto, quando o assunto é SOA, conseguir aplicar o método correto e ajustado é essencial para o sucesso da nova visão de tecnologia da informação.

- Não colocar na mesma mesa TI e negócio – Olhando para aspectos não técnicos, decidir implantar SOA em uma companhia sem o envolvimento e a dedicação da área de negócio é a assinatura de um cheque em branco, puro prejuízo. Não basta pedir para que a área de negócio ajude a área de TI, as áreas de TI e de negócio devem andar de mão dadas, pois é um investimento comum das duas partes.

Quando soube do novo curso SOA Adoption and Architecture Fundamentals oferecido pela Oracle University a primeira coisa que fiz foi buscar informações a respeito dos tópicos abordados, e posso dizer que o conteúdo chamou muito a minha atenção positivamente.

O foco desse treinamento são os aspectos fundamentais do SOA, mapeando desde as atividades iniciais até o momento em que se tem arquitetura e processos maduros na companhia.

171788

Vale ressaltar alguns pontos do conteúdo do curso, logo de cara no primeiro capítulo, é apresentada a arquitetura de referência da Oracle e o conceito de implementação de tecnologia que eles utilizam, logo em seguida, é abordado o modelo de maturidade SOA.

SOA-maturity-model-large
Pode parecer irrelevante ou até mesmo presunçoso ter esses dois temas no curso pois são focados diretamente na visão da Oracle sobre SOA, mas posso afirmar com tranquilidade que a riqueza de informações que se extrai desses tópicos podem fazer a diferença entre o sucesso e o fracasso de uma iniciativa SOA.

Com uma visão correta de arquitetura (lógica e física), associado a um processo correto de desenvolvimento SOA (envolvendo programa e projetos) e se sabendo como traçar o caminho para o futuro (modelo de maturidade), o sucesso na adoção do SOA fica um pouco mais próximo.

O demais tópicos são tão importantes quanto os primeiros, com eles se aprende como organizar o desenvolvimento dos projetos, como lidar com as dependências de serviços, como reconhecer, definir e reutilizar serviços de negócio, além de obviamente, tratar do processo de governança de todo esse ecossistema, tentando garantir a saúde geral da iniciativa.

Creio que não seja demais enfatizar, com esse curso você não vai aprende a utilizar o SOA Suite ou o Weblogic Server, o foco são métodos e processos, é entender como se faz para alinhar a área de negócio com a área de TI, como a área de TI deve se comportar para conseguir tirar proveito do SOA, como fazer o sonhado ROI efetivamente acontecer, como pensar no futuro desenvolvendo soluções para o presente.

Um pouco mais sobre WebCenter

Um pouco mais sobre WebCenter

A experiência de ministrar cursos técnicos é sempre enriquecedora, seja pelo objetivo de apresentar da melhor maneira o conteúdo programático, seja pela possibilidade de discutir temas relevantes para a rotina dos alunos, ou até mesmo por poder colaborar indiretamente no sucesso das empresas contratantes.

Essa semana ministrei o curso Oracle WebCenter Spaces 11g: Build E2.0 Portals and Communities, onde são expostas as características sociais do produto Oracle WebCenter Suite.

O conteúdo do curso é vasto a respeito das capacidades básicas embutidas na plataforma, no entanto, não é exposto um conteúdo onde é apresentada uma visão mais ampla das possibilidades.

Dessa forma, decidi criar um diagrama que exponha um pouco das capacidades da plataforma WebCenter Suite e as possibilidades de integração que seus usuários podem lançar mão.

Sobre o WebCenter

O Oracle WebCenter é uma plataforma baseada na tecnologia Java EE e Portal, tem como filosofia fortalecer a convergência da interação entre os usuários e as informações do negócio utilizando um conjunto de componentes pré-construídos e possibilita agregar componentes adicionais para responder às necessidades de negócio.

Seus componentes pré-construídos atuam fortemente na integração dos usuários, permitindo realizar a criação da rede social corporativa, já suas possibilidades de integração externa tornam a plataforma um ponto ideal para concentração das aplicações corporativas existentes.

Visão Geral

Visão básica

No meu ponto de vista o produto pode ser dividido em três verticais, pessoas, negócio e serviços.

  • Pessoas, diz respeito a todas as funções de integração entre os usuários, como por exemplo, a ligação de relacionamento e o sistema de comunicação por correio ou comunicação instantânea.
  • Negócio, as capacidades de integrar sistemas corporativos à plataforma, unificando plataformas distintas em apenas um ecossistema.
  • Serviços, os componentes nativos da plataforma, que permitem a criação de portais corporativos, grupos de usuários baseado em contextos, entre outras capacidades.

Tais verticais podem ser detalhadas para algo parecido com a imagem abaixo.

Detalhamento

 Pessoas

Detalhamento Pessoas

Possibilitar a relação interpessoal e é fundamental na plataforma, a companhia deter-se apenas a essa função é abster-se de uma série de possibilidades secundárias que atuam diretamente no interesse corporativo.

A evolução das relações corporativas podem ser alcançadas por meio da unificação de processos, aplicação de conformidades operacionais, compartilhamento de informações por meio de documentos geridos, entre outras ferramentas, todos esses objetivos podem ser atingidos a partir desse módulo em cooperação com os demais módulos da plataforma.

Negócio

Detalhamento Negócio

Entender o universo de recursos que podem ser agregados para a expansão da plataforma muitas vezes não é claro para seus usuários, a imagem acima mostra um pouco das tecnologias que podem fazer parte do WebCenter Suite.

Serviços como o Oracle BPM, Webservices, portal, ECM, MS Office, conteúdo com XML, arquivo texto, HTML e integração com Banco de Dados permitem que o produto seja bastante flexível e  atenda as mais variadas demandas.

Serviços

Detalhamento Serviços

 O conjunto de serviços básicos da plataforma permitem a realização de uma série de ações que integram os usuários à companhia e facilitam sua comunicação.

Utilizar o serviço de Anúncios facilita a comunicação corporativa por meio do envio eletrônico de comunicações, o serviço de Agendas (eventos) permite alinhar as expectativas das equipes por meio de uma agenda única de ações, o sistema de Tags facilita a descoberta dos conteúdos corporativos por meio do serviço de Pesquisas, sem contar os serviços de referência por meio de links.

Caso de Uso

Para ilustrar um caso de uso sobre as facilidades do WebCenter vou referenciar uma imagem do manual do produto, especificamente o capítulo 11.4 AviTrust Employee Portal: An Example of Delegated Navigation do manual do usuário.

 

Estrutura de Navegação

Na imagem acima, é apresentado o recurso de estruturação de um portal, são criados Subspaces para acomodar as áreas da companhia e a área de banco possui outros níveis de Subspaces.

Essa imagem ilusta os recursos de criação de espaço e a criação de sub-espaços, além da possibilidade de criação de páginas de acesso dos usuários. Um espaço ou um sub-espaço são apenas áreas de contexto, é necessário que existam páginas para que seja possível acessar esses espaços.

Diante da visão do diagrama de estrutura de navegação, é fácil imaginar a possibilidade de criar sites corporativos e intranets em um único ambiente compartilhando dos recursos disponíveis e das facilidades construídas. Realizar esse tipo de construção é um caminho quase natural, principalmente por ser fortemente apoiada pelo rigoroso sistema de autorização de acesso, que garante a gestão do acesso aos recursos com um profundo grau de detalhamento e pelo poderoso serviço de busca, que permite recuperar qualquer conteúdo interno do produto ou de sistemas externos que permitam indexação.

As páginas são um dos principais pontos de acesso dos recursos avançados do WebCenter, são nelas que os portlets são adicionados, onde são construídos os componentes de interação, onde podem ser consumidas bases de dados, Webservices e arquivos XML. Além do uso dos componentes, os objetos podem ser ligados, podem ser passados parâmetros e enriquecida a interação.

Por se tratar de um tema vasto, aliado ao fato de que esse artigo esta um pouco maior do que o esperado, em breve escreverei especificamente sobre as páginas do Webcenter, suas capacidades e recursos.

 

SOA Suite 11g, algumas dicas.

Sempre que apresento o Oracle SOA Suite 11G para uma nova turma e digo que partir de então todo desenvolvimento será feito utilizando XML a reação de alguns alunos é mais que previsível, por mais que o formato XML seja algo comum no dia-a-dia de quem trabalha com desenvolvimento de sistemas, muitas das vezes o XML é utilizado de maneira marginal ou tem um papel coadjuvante, se deparar com a notícia que aquele conhecido distante se tornará seu melhor amigo mesmo que a contragosto é realmente algo que não se espera.

Tudo bem, eu sei que de certa forma exagero um pouco quando falo isso, não consigo evitar o apelo dramático que expor essa notícia tem, no entanto, essa é uma realidade da qual os alunos não devem fugir, todo produto foi desenvolvido utilizando esse formato e é realmente importante que eles entendam a mudança de paradigma e assimilem essa necessidade o mais breve possível.

Se o fato lidar com um grande volume de XMLs no novo ambiente chama a atenção de boa parte das turmas, apresentar os componentes que a suite possui sem dúvida consegue colocar uma pulga atrás da orelha de outra grande parte das turmas, por exemplo, utilizar uma máquina de regras nas avaliações de condição ao invés de declarar as condições no código é algo bem diferente do que se utiliza até então, entender a aplicabilidade desse componente e conseguir utiliza-lo coerentemente  faz as cabecinhas dos alunos esquentarem.

No intuito de complementar o conteúdo dos cursos, busco indicar referências de literatura relevante para quem busca conhecer mais do produto e dos conhecimentos complementares que ele exige, dessa forma, algumas indicações:

 

XSLT 2.0 and XPath 2.0 Programmer’s Reference – Michael Kay

 

 

 

 

 

 

Web Service Contract Design and Versioning for SOA – Thomas Erl; Anish Karmarkar; Priscilla Walmsley; Hugo Haas; L. Umit Yalcinalp; Canyang Kevin Liu; David Orchard; Andre Tost; James Pasley

 

Oracle SOA Suite 11g R1 Developer’s GuideOracle SOA Suite 11g R1 Developer’s Guide – Antony Reynolds, Matt Wright

 

Afinal, o que é Tuxedo?

Tuxedo é um monitor de processamento transacional (TPM), desenvolvido no início da década de oitenta pela AT&T’s Bell Laboratories para ser um gerenciador de transações baseado em sistema operacional UNIX e que garantisse uma performance superior a 1.000 (um mil) transações por SEGUNDO.

As características do produto foram estabelecidas como pilares tão sólidos que o batismo do mesmo não poderia ser tão menos criativa, TUXEDO significa em inglês “Transactions for Unix, eXtEnded for Distributed Operations”.

Uma década depois de sua criação e depois de ter mudado de casa uma vez, o produto é adquirido pela BEA Systems que empenha esforços para tornar o produto amplamente conhecido no mercado, em 1999 é destacado como a melhor plataforma de transações distribuídas para aplicações C/C++ e COBOL utilizando a arquitetura de serviços (você achava que SOA era novidade?).

 

Foco de Mercado

 

Não é de se estranhar, mesmo sendo um produto com características muito avançadas desde sua concepção o TUXEDO não é conhecido de maneira geral no Brasil.

Os principais clientes desse produto são operadoras de telefonia, bancos, operadoras de cartão de crédito, empresas de aviação e empresas de logística, a rigor, empresas que possuem um volume muito grande de transações em sistemas de missão crítica, quando fala-se em grande volume de transações os números são geralmente astronômicos, lembrando do requisito básico de mil transações por segundo.

Vale ressaltar, no Brasil mesmo não sendo muito conhecido, esse produto é encontrado em operadoras de cartão de crédito, operadoras de telefonia, entre outras.

Alguns dos grandes utilizadores do Tuxedo: FEDEX, MasterCard, Delta, Citi, CREDIT SUISSE e China Unionpay.

 

Visão Geral da Arquitetura

 

Tuxedo é essencialmente e trocando para termos mais comuns um servidor de aplicações. Possui características como ambiente clusterizado, comunicação entre ambientes, distribuição de carga entre os servidores, tolerância a falhas, coordenação transacional, sistema de mensageria e conectividade com outras plataformas.

Originalmente eram suportadas as linguagens C e C++, a evolução da plataforma fez com que fosse disponibilizado o suporte a COBOL, para atender clientes que pretendiam sair da plataforma Mainframe com o mínimo de impacto, atualmente, são suportadas também as linguagens Phyton, Ruby e PHP.

É interessante ressaltar uma característica que muitas vezes é ignorada, o Tuxedo é multi-plataforma, um cluster pode ser formado por máquinas de arquiteturas distintas, como por exemplo, Intel e SPARC, todo trabalho de garantir a comunicação correta entre esses servidores fica a cargo do servidor de aplicação.

 

Arquitetura Orientada a Serviços (SOA)

 

Atualmente muito se fala na área da arquitetura de sistemas sobre o desenho de soluções baseadas em serviços, por sua vez, Tuxedo é totalmente baseado nessas características desde o início, uma aplicação cliente ao invocar uma serviço Tuxedo, na verdade invoca o nome do serviço, não é necessário se preocupar com a localização do mesmo, muito menos precisa ter ciência de detalhes de implementação do serviço.

Com a consolidação da tecnologia de Webservices, bastou criar um módulo que extrai a assinatura original dos serviços do ambiente Tuxedo (SALT) e cria uma camada de conversão para XML, a partir disso todos serviços passaram a responder Webservice sem NENHUM tipo de modificação.

Modelo de Comunicação

 

Por mais que não pareça, a rigor toda comunicação na plataforma é assíncrona utilizando Unix/Linux IPC (Inter-process communication), essa característica é um importante recurso voltado a estabilidade, velocidade de resposta e garantia de ativação do serviço.

Mesmo que inerentemente as invocações sejam assíncronas, a plataforma permite que o cliente execute chamadas do tipo síncrona e assíncrona sem abrir mão de nenhum tipo de benefício citado acima. Um outro tipo de invocação permitida é a de encaminhamento (tpforward), não entrarei em detalhes a respeito pois pretendo manter esse material em um nível menos técnico.

Além da comunicação por meio de memória compartilhada, outra forma de comunicação tão poderosa quanto o IPC é a comunicação por mensagens, para isso o Tuxedo fornece o sistema de mensagens conhecido por /Q, esse produto garante a persistência das mensagens e a garantia de entrega e consumo por meio de transação distribuída (XA). Originalmente esse módulo somente permitia a tramitação de mensagens persistidas em meio físico, no entanto, a partir da versão 8 foi disponibilizado o recurso de mensagens em memória para atender requisitos de performances que aceitavam abrir mão da garantia de persistência em caso de falha do servidor.

Altíssima Disponibilidade

 

A grande maioria das aplicações corporativas são desenvolvidas para que estejam constantemente disponíveis, seja para atender uma grande rede de consumidores, seja para suportar um grande volume de transações ou para atender demandas oriundas de regiões distintas do globo, garantir a disponibilidade esperada é muito mais complicado na prática do que na teoria.

Todo desenho da solução Tuxedo leva em conta equipamentos de arquitetura distinta, coordenação de transação distribuída, localização remota de servidores/serviços, persistência de informação e distribuição de comunicação.

Um exemplo básico da arquitetura de alta disponibilidade diz respeito a comunicação entre máquinas. O administrador do ambiente pode definir a maneira como os servidores do cluster devem se relacionar quanto a comunicação de rede, uma das características é a ativação de canais paralelos de comunicação entre máquinas, sempre que uma máquina enviar pacotes para outra máquina, ela utilizará em paralelo placas de redes e/ou infraestrutura de redes distintas, garantindo que a mensagem enviada alcance seu destino da melhor forma possível, ultrapassando possíveis dificuldades de infraestrutura.

Indisponibilidade de sistemas é algo muitas vezes negligenciado, 99,99% de disponibilidade significa uma indisponibilidade superior a 52 minutos em um ano, para uma operadora de cartões de crédito que processa algo em torno de 400 transações por segundo, significa a perda de 1.248.000 transações, agora multiplique isso pelo valor médio das compras e é possível chegar no impacto financeiro da indisponibilidade. Aplique esse exemplo para o volume de transações que originou o Tuxedo, 1.000 transações por segundo, são 3.120.000. Por fim, multiplique esse tempo de indisponibilidade por 50.000.000 transações por segundo (156.000.000) e não estou falando de um caso hipotético, existe relatos de clientes com performance muito superior a essa.

Ambientes Tuxedo desenhados corretamente e administrados da maneira correta tendem a alcançar 99.999% de disponibilidade, o que significar uma indisponibilidade máxima de pouco mais de 5 minutos ao ano, sem dúvida uma prazo administrável.

 

Performance Imbatível

 

Quando o assunto  é performance novamente estamos falando de Tuxedo, serviços são desenvolvidos para operar na escala de nanosegundos, comunicação é desenhada para ser super performática, assim por diante.

Velocidade é algo tão marcante que é esperada para as próximas versões do produtos a capacidade de definição de limite de tempo de resposta (timeout) na escala de nano segundos, não cabe mais esperar um segundo por um serviço que leva 30 nanosegundos para executar.

Para colocar o termo “performance imbatível” em um novo patamar, em Dezembro de 2010 foi anunciado o recorde mundial de transações por minuto pela Oracle, utilizando Tuxedo e hardware Exalogic, o recorde anterior do mês de agosto do mesmo ano era da IBM com um valor próximo a 10 milhões de transações por minuto, a Oracle conseguiu junto com o Tuxedo o módico valor de mais de 30 milhões de transações por minuto. Vale ressaltar que esses testes seguem uma metodologia e são certificados, ou seja, a comparação entre eles é válida.

É muita pretensão querer colocar tudo sobre Tuxedo em uma única postagem, dessa forma, nos próximos posts teremos mais sobre esse produto…

 

Carga Automatica de Servidores Tuxedo

A capacidade do Tuxedo de gerenciar as instâncias de servidores ativas é possivelmente um dos recursos mais mal explorados pelos clientes com que tive contato, isso por que, a configuração do recurso não é obvia como a maioria dos demais e depende do entendimento de outros recursos para seu uso.

O bom funcionamento de um ambiente é (entre outras coisas) diretamente ligado a capacidade desse ambiente atender a um volume de trabalho que lhe é conferido, quando capacidade de resposta é referência ao número disponível de um determinado recurso, temos nas mãos um paradigma de gestão, pois no ambiente computacional todo recurso possui limitações.

A definição de valores fixos para um determinado recurso pode ocasionar comportamentos distintos:

  • Os valores serem superiores ao necessário e gerar o consumo desnecessário de recursos no ambiente computacional.
  • Os valores serem inferiores ao necessário e gerar lentidão e ou indisponibilidade do recurso. Obrigando a alocação de recursos operacionais extras para gestão da indisponibilidade.

Em ambos os casos o resultado não será satisfatório, pois leva ao uso descomedido de recursos escassos, na busca de um uso racional, o Tuxedo nos oferece uma alternativa muito atraente.

 

Definição de Demanda x Capacidade de Resposta

Conhecer a demanda de um determinado servidor é um requisito não funcional que deve(ria) ser conhecido no momento da construção dos serviços. Uma vez que se conhece a demanda e é aferida a performance dos serviços no momento dos testes, é possível definir a performance do servidor e o número de instâncias necessárias para atender a demanda linear.

Sendo, R tempo de resposta média do servidor, D demanda diária de requisições e I o número de instâncias, podemos realizar o seguinte cálculo, divide-se as requisições diárias pelo número de segundos de um dia e multiplica-se pelo tempo de resposta do serviço.

Se R = 2s e D = 500.000, precisamos de 11.5 instâncias ativas para podermos atender a carga linear de requisições. A rigor, são muito raros os cenários onde um serviço atende a demanda regular de invocações, é comum haver variações durante o período, podendo gerar um ou mais momentos de pico e consequentemente momentos de vales.

A variação de demanda obriga o administrador do ambiente Tuxedo a pensar nos valores adequados de instâncias que vão atender a demanda de pico, a demanda média, a demanda de vale do serviço e qual tempo de resposta é considerado aceitável para um pequeno nível de retenção das chamadas.

Tendo em conta o seguinte cenário:

O serviço X é uma operação transacional com o SLA é de 5s, o tempo médio de resposta em ambiente operacional é de 1.3s e será invocado 200.000 vezes durante o dia, sendo que, 40% dessas chamadas serão concentradas no período das 12pm-14-pm e 18h-20h.

É necessário se preocupar com a demanda de pico e a demanda regular, não há informação suficiente para avaliar a demanda de vale para o serviço, dessa forma, o volume de pico é:

  • 40% das transações: 80.000
  • Período do volume: 4 horas
  • Transações por segundo: 5.6
  • Instâncias necessárias: (5.6 x 1.3) = 8 (como não existe meia instância, arredonda-se para cima)

Demanda regular:

  • 60% das transações: 120.000
  • Período do volume: 20 horas
  • Transações por segundo: 1.7
  • Instâncias necessárias (1.7 x 1.3) = 3

Requisições Previstas x Instâncias Necessárias

Os números acima são valores absolutos, indicam a média absoluta de requisições no momento de baixa demanda e o máximo absoluto no momento de pico, no entanto, existe uma variação entre os dois momentos, o ambiente pode estar operando em um regime abaixo da média no momento A e com o aumento da carga, no momento alcança o pico após 1 hora de trabalho, isso indica que não é necessário ocupar antecipadamente os recursos necessários para atender uma demanda esperada, sendo que, esse volume poderá levar uma hora para ser alcançado.

A melhor forma de gerir o número de instâncias disponíveis é avaliar a demanda de requisições e a capacidade de resposta de forma dinâmica, elevando o número de instâncias disponíveis de acordo com o aumento de demanda e reduzindo a capacidade disponível sempre que aferida disponibilidade ociosa, liberando recursos para outros componentes do ambiente.

Ativação dinâmica de Instâncias

 

O gráfico acima apresenta o comportamento do Tuxedo quando definida a adequação dinâmica de recursos, no período de 2 minutos, um determinado serviço teve um aumento de invocações, sendo que, o número de instâncias ativas não eram capazes de atender adequadamente, para isso, levando em conta os parâmetros definidos, o Tuxedo ativou instâncias extras do servidor para que fosse possível adequar a capacidade de resposta, em seguida, desabilitou algumas instâncias por não serem mais necessárias.

 

Definindo o Comportamento do Servidor Tuxedo

Para ativação e desativação dinâmica de servidores no Tuxedo, é necessário definir o número médio requisições retidas por um determinado período de tempo no ambiente, por exemplo:

  • Sempre que o servidorX tiver uma média de 4 requisições ou mais retidas por um tempo superior a 3 segundos, deve ser ativada uma nova instância, até que se alcance o valor máximo de instâncias prevista ou que o número de mensagens retidas fique abaixo do valor definido.
  • Quando o servidorX tiver 2 requisições ou menos em média retidas por mais de 30 segundos, deve ser desativada uma instância do servidor até que se alcance o número mínimo de instâncias previstas.

Uma vez que se prevê a demanda e faz-se a definição da adequação da capacidade, não é necessário executar nenhum tipo de ação operacional para que seu serviço atenda de forma correta a variações de volume de requisições.

Como dito no inicio do post, para que funcione a capacidade de adequação de carga no Tuxedo, é necessário conhecer uma série de características distintas que unidas permite tirar o melhor da plataforma, nesse momento, iremos abstrair o conhecimento claro dessas outras características e vamos nos focar na configuração do recurso de gestão dinâmica, para isso devem ser definidos os seguintes parâmetros.

Parâmetros do Servidor

  • MIN – Número mínimo de servidores, número de instâncias que devem ser carregadas ao ativar o servidor.
  • MAX – Número máximo de instâncias do servidor.
  • RQADDR – Nome de identificação da fila de requisições do servidor.
  • REPLYQ – Indica se o servidor necessita de fila de resposta.
  • CLOPT – Parâmetros de ativação do servidor.
O parâmetro CLOPT é onde indica-se os parâmetros para ativação e desativação de instâncias, usando como base os valores do exemplo acima, obtemos a seguinte configuração:
CLOPT="-A -p 2,30:4,3"

Detalhe:

-p – Indica a opção de controle do número de instâncias.

<carga regular> , <período> : <carga superior> , <período> – Indica as características da carga regular para desativação de instâncias e da carga superior para ativação de novas instâncias.

Cada servidor deve usar uma fila exclusiva, não pode ser feita a definição de uma mesma fila para serviços distintos.

Uma visão um pouco mais ampla da configuração nos apresenta:

ServidorX
    SRVID=100 SRVGRP=APGR101
    MIN=3  MAX=10
    RQADDR=SERVXRQ  REPLYQ=Y
    CLOPT="-A -p 2,30:4,3"

 

Antes de Encerrar…

… algumas considerações finais, não foi discutido aqui detalhes básicos da arquitetura Tuxedo, como por exemplo, ipc, computação distribuída, load-balance e peso de invocação, esses temas ficam para um momento oportuno.

Instâncias do servidor?

Para quem é novo no mundo Tuxedo, entender alguns termos e algumas características é fundamental para conseguir extrair o máximo dessa plataforma transacional.

  • Servidor – Aplicação de negócio (binário) que é executado associado ao Tuxedo.
  • Serviço- Interface ou interfaces providas por um servidor.
  • Máquina – Equipamento físico onde é executado o ambiente transacional.

Entendendo Listeners e Handlers

Falando um pouco mais sobre o que se ganha com o Tuxedo e que se não souber usar só vai atrapalhar, vamos discutir rapidamente sobre Listeners e Handlers.

 

Um pouco de feijão com arroz

Tuxedo é uma plataforma que possui uma série de características próprias, por exemplo, controle de acesso, protocolo de comunicação e controle de threads. Existe também a definição de tipos de clientes entre clientes locais e clientes remotos.

Clientes locais são aqueles que acessam o ambiente transacional a partir de uma máquina que faça parte do ambiente, sem a necessidade de uso de rede. Esses clientes utilizam a memória compartilhada (via IPC) para se comunicar.

Cliente remoto é todo aquele que acessa o ambiente transacional por meio de um canal de rede.

 

Listener, o porteiro

Para que clientes remotos possam acessar o ambiente transacional é necessário que exista uma porta de acesso, na arquitetura Tuxedo uma das portas mais conhecidas é o Workstation Listener, que em poucas palavras é um dos São Pedros da plataforma, é ele quem decide quem entra e quem fica de fora e quando entra, quais seus direitos.

Como todo bom chefe, o Listener delega o trabalho para os Workstation Handlers, esses sim fazem o trabalho sujo de ligar o cliente aos serviços que desejam utilizar.

Mas chega de metáforas ruins, vamos ver como isso funciona na prática e com que temos que nos atentar.

 

Abra una porta e ganhe uma peneira

O Workstation Listener (WSL) é o servidor que disponibiliza uma porta de acesso ao Tuxedo, a definição de qual será a porta que o servidor deverá abrir é uma decisão tomada no momento da configuração.

WSL     SRVGRP="SG1110"   SRVID=3
        RESTART=Y GRACE=0 MAXGEN=100
        CLOPT="-A -- -n //hostname:10000 -m 2 -M 2"

No exemplo de configuração acima é indicado endereço de rede “//hostname:10000″, informando que a porta “10000” deve ser usada para acesso dos clientes externos, como é nos detalhes que mora o perigo, o que faz os administradores de ambientes Tuxedo muitas vezes quebrarem a cabeça é o que vem logo em seguida, os parâmetros “-m 2 -M 2″.

Os parâmetros m e M indicam qual o número mínimo e o número máximo de  Workstation Handlers devem ser ativados associado ao servidor WSL em questão, no exemplo são fixos dois servidores.

Workstation Handler é um delegado do cliente remoto, ele recebe os comandos enviados pelo cliente remoto e executa em seu nome no ambiente local Tuxedo, acessando diretamente a memória compartilhada. Para que seja possível receber os comandos do cliente remoto, o Handler abre uma porta de conexão para que possa ser realizada a comunicação, diferente do WSL onde se conhece a porta que se abrirá, as portas abertas pelo Handler são de conhecimento do Listener, sendo assim, ao carregar o ambiente podemos ter algo parecido com a imagem abaixo.

 

Delegação de responsabilidade

O processo de acesso do cliente ao ambiente Tuxedo é executado seguindo uma série de ações, como o único endereço de acesso conhecido é o do WSL (o endereço declarado na configuração), o cliente se conecta a esse servidor e executa a autenticação no ambiente, concluída essa etapa, o WSL delega a responsabilidade de tratar as operações do cliente para um dos WSH disponível.

Ao final, o WSL responde para o cliente o endereço de rede do Handler que deve ser invocado nas chamadas, o cliente por sua vez, se conecta ao servidor WSH indicado.

Se os parágrafos acima ficaram confusos, não se preocupe, aqui embaixo temos mais um diagrama ilustrativo para ajudar.

Sequência de ações:

  1. O cliente é autenticado no WSL;
  2. O cliente é delegado para o WSH disponível;
  3. É informado ao cliente o WSH de conexão;
  4. O cliente se conecta ao WSH indicado.

Passando pelo muro de fogo

Como comentado anteriormente, a única porta conhecida previamente é a do servidor WSL, por outro lado, a comunicação entre o cliente e o ambiente Tuxedo utiliza ao menos duas portas, fazendo as contas, sobra uma porta que não se conhece, além disso, não é possível definir empiricamente qual porta o WSH utilizará, em cada carga do ambiente são selecionadas portas distintas.

Após a carga do servidor:

tcp    0   0 127.0.0.1:10000         0.0.0.0:*           LISTEN      24706/WSL
tcp    0   0 127.0.0.1:26055         0.0.0.0:*           LISTEN      24707/WSH
tcp    0   0 127.0.0.1:26056         0.0.0.0:*           LISTEN      24708/WSH

Após o reinicio do servidor:

tcp    0   0 127.0.0.1:10000         0.0.0.0:*           LISTEN      24706/WSL
tcp    0   0 127.0.0.1:30458         0.0.0.0:*           LISTEN      24707/WSH
tcp    0   0 127.0.0.1:30459         0.0.0.0:*           LISTEN      24708/WSH

Em ambientes corporativos, por questões de segurança toda comunicação entre equipamentos é doutrinada por firewall, faz parte da doutrina definir quais portas podem ser acessadas em determinado servidor, se não é conhecida a porta que o WSH utilizará o cliente conseguirá acessar o WSL mas não conseguirá completar a conexão com o WSH pois será impedido pelo firewall.

Para se conhecer as portas que serão utilizadas pelo WSH é necessário declarar na configuração servidor WSL, no entanto, deve-se ter muito cuidado com essa questão, caso as portas declaradas estejam em uso no momento da carga do servidor, o ambiente não será carregado adequadamente.

WSL     SRVGRP="SG1110"   SRVID=3
        RESTART=Y GRACE=0 MAXGEN=100
        CLOPT="-A -- -n //hostname:10000 -m 4 -M 10 -p 10001 -P 10010"

Como evolução da configuração original, são usados o parâmetros p e P para a carga do servidor WSL, esses parâmetros indicam a menor e a maior porta a serem alocadas pelos WSH quando carregados, os valores padrão são “-p 2048 -P 65535″.

Portas alocadas pelos WSH quando definida a faixa permitida:

tcp    0   0 127.0.0.1:10000         0.0.0.0:*          LISTEN      28559/WSL       
tcp    0   0 127.0.0.1:10001         0.0.0.0:*          LISTEN      28562/WSH       
tcp    0   0 127.0.0.1:10002         0.0.0.0:*          LISTEN      28563/WSH       
tcp    0   0 127.0.0.1:10009         0.0.0.0:*          LISTEN      28560/WSH       
tcp    0   0 127.0.0.1:10010         0.0.0.0:*          LISTEN      28561/WSH

Agora que se conhece as portas pelas quais o cliente irá se comunicar com o WSH, é possível cadastrar as regras no firewall para que a comunicação possa ocorrer sem problemas.

 

Quando fucinho não é tomada

Permitir o acesso de clientes remotos significa que esses clientes podem estar em qualquer lugar, como por exemplo em outra rede, caso a comunicação entre as redes envolva o mascaramento dos endereços internos por meio de NAT (Network Address Translation), além de indicar o IP/DNS interno e a porta que o servidor utilizará na máquina, é necessário indicar o IP/DNS e a porta pública que os clientes devem utilizar fora da rede interna para acessar o WSL.

Para indicar a configuração de acesso via rede pública utiliza-se o parâmetro H.

WSL     SRVGRP="SG1110"   SRVID=3
        RESTART=Y GRACE=0 MAXGEN=100
        CLOPT="-A -- -n //hostname:10000 -m 4 -M 10 -p 10001 -P 10010
                     -H //publicname:10000"

No exemplo acima a configuração indica que o servidor irá abrir a porta local 10000 no IP associado ao nome hostname e que receberá comunicação pelo IP associado ao nome publicname.