Para Contrução hoje de sistemas utilizando componentes de software tipo WebService, existem varias plataformas e tecnologias diferentes em produção e em evolução, neste post exponho um comparativo entre as funcionalidades de cada uma.

http://wiki.apache.org/ws/StackComparison

Depois de ouvir sobre a oferta da Oracle para comprar BEA por US $ 6,6 bilhões,
realizei uma pesquisa profunda com vários contatos, e descobri coisas interessantes à dizer:
“É basicamente uma enorme mudança de toda a maneira que middleware é que vai ser feito”

Oracle é agora a nova Microsoft?,
Agora as regras estão mudando. Oracle com PeopleSoft e JD Edwards, esta se fortalecendo principalmente para a competição no mercado corporativo de SOA que esta se estabelecendo. Historicamente a solução de Aplication Server da Oracle (OC4J), é fraca e pouco usada no mercado, mas com essa possível aquisição se concretizando ela tentará brigar com IBM e por em pé de igualdade, mais fortemente.
Esta noticia esta se repercutindo em todo o mercado mundial de software, nas próximas semanas iremos ouvir falar muito sobre isso.

“Segundo Ron Schmelzer analista da ZapThink, é questão de tempo e dinheiro”

Mas a briga esta só começando, IBM, SAP e até a HP iram em breve se manifestar, pois

HP e BEA tem uma relação muito estreita e Chuang(BEA) hoje seria provavelmente mais Abertos a serem adquiridos por eles do que por Oracle. “

Fontes:
http://www.eweek.com/article2/0,1895,2195308,00.asp

Neste mês saiu a nova versão do projeto Tuscany agora 1.0, bastou o grupo OSOA, liberar a especificação 1.0 da arquitetura SCA, para o projeto ser atualizado, isso mostra que esse esta sendo apoiado fortemente pelo grupo OSOA (IBM, BEA, ORACLE, etc), e em breve sera graduado para um completo projeto Apache.Semana passada recebi um email de Mike Edwards, e vejam o que ele me respondeu referente a evolução desta arquitetura e do projeto Tuscany
“The OASIS stuff is really getting going now and that makes things much morepublic. Also, Apache Tuscany did a 1.0 release andis moving towards graduation to a full Apache project.”
Por este motivo, esta arquitetura será promissora, pois simplifica o desenvolvimento da arquitetura SOA, e a construção de software componentizada.

Veja um comparativo da SCA, com o modelo tradicional J2EE.

É bem claro a simplicidade da arquitetura de SCA.

Neste mês saiu a nova versão do projeto Tuscany agora 1.0, bastou o grupo OSOA, liberar a especificação 1.0 da arquitetura SCA, para o projeto ser atualizado, isso mostra que esse esta sendo apoiado fortemente pelo grupo OSOA (IBM, BEA, ORACLE, etc), e em breve sera graduado para um completo projeto Apache.

Semana passada recebi um email de Mike Edwards, e vejam o que ele me respondeu referente a evolução desta arquitetura e do projeto Tuscany

Veja um comparativo da SCA, com o modelo tradicional J2EE.

É bem claro a simplicidade da arquitetura de SCA.

Pessoal,

Ainda não consegui terminar a segunda parte da matéria de SCA, pois nos últimos três dias, estive participando de um treinando de ITIL, e por isso não consegue termina-lo, mas este treinamento vem bem a calhar, e com esse consegui enxergar que o SOA pode ser uma boa base e ferramenta pra alinhamento dos sistemas com a ITIL em uma empresa e vice-versa também, pois tanto a Arquitetura Orientada a Serviços e como o ITIL, focam no alinhamento da TI com o négocio e a qualidade do serviço prestado aos clientes, por isso ao iniciar um projeto de implantação da ITIL na empresa, pode ser uma boa base e justificativa para implacar um projeto de SOA, e se a empresa implantar a SOA em sua empresa os sistemas estaram melhores dispostos a implantação do ITIL, pelo menos no que diz respeito a infra-estrutura e arquitetura de software da companhia.

Vou voltar a este tema em breve, por hoje é só.

Uma Visão geral de SCA

Um Pouco de História

• “… em um certo momento, alguns desenvolvedores pensaram que seria bom ter um modelo de programação para sustentação à arquitetura orientada do serviço…”
• Esse modelo é SCA
• As empresas da indústria de TI que colaboram cresceu de apenas 2 companhias para 18 hoje

• publicado a versão 1.0 das especificações de SCA, em março 2007

• As especificações de SCA agora estão prontas para a estandardização no comite OASIS.

Site do grupo Open SOA Collaboration www.osoa.org:

Padronização

• OASIS ira guiar a padronização das especificações da colaboração na seção dos membros de OpenCSA
• Estrutura da seção dos membro

• 6 comitês técnicos (TCs) para dirigir-se a um ou mais especificação da colaboração

• SDO V2.1 para Java será terminado no JCP como JSR235
• O desenvolvimento das especificações ira continuar dentro da colaboração de OSOA para as tecnologias ainda não prontas para a padronização.

Modelo de programação de SOA (1)

• O modelo de programação de SOA deriva-se do conceito básico de um serviço:
• Um serviço é uma abstração que encapsula uma função do software.
• Desenvolvedores controem serviços, usam serviços e desenvolvem soluções de serviços agregados.

• A composição dos serviços em soluções integradas é uma atividade chave

Modelo de programação de SOA (2)

• Elementos do núcleo:

- Conjunto do Serviço:
. Representação da composição dos serviços independente da tecnologia e da linguagem de programação.

- Componentes do Serviço:
. Implementação do serviço composto independente da tecnologia e da linguagem

- Serviço Objeto de Dados (Service Data Object – SDO):
. Representação do Serviço de Entidade de Dados (SDO), independente de tecnologia e linguagem.

O que são SCA e SDO?

• Service Componente Architecture:

- Um modelo executável para construir aplicações orientadas a serviço (SOA), como redes compostas de componentes de serviço.
- “Usado para construir aplicações baseadas em serviços compostos

• Service Data Objects:

- um modelo unified para a manipulação dos dados (do serviço), independente de sua fonte ou origem.
- “para assegurar e obter dados em um ambiente de serviços”

Service Component Architecture (SCA): Modelo de Programação Simplificada para SOA

• modelo para:
  - construindo componentes de serviço
  - montando componentes em aplicações
  - publicando (deploy) para ambientes de produção (distribuído)
  - prestar serviços de manutenção aos componentes
  - construir componentes apartir de códigos novos ou existentes usando princípios de SOA
  - neutralidade-de-vendedor – suportado através da indústria
  - língua-neutro – componentes escritos usando alguma língua
  - neutralidade-de-tecnologia – usar todos os protocolos e infra-estrutura de comunicação para ligar componentes

Benefícios Chaves de SCA

• Baixo Acoplamento: Integrar Componentes sem a necessidade de saber como os outros estão implementados
• Flexibilidade: Os componentes podem facilmente ser substituídos por outros componentes
• Serviços: Podem facilmente ser invocados de forma síncrona ou assíncrona
• Composição: Das soluções: claramente descritos
• Produtividade: Mais fácil de integrar componentes para dar forma às aplicações compostas
• Hetereogenidade: Implementações através de múltiplas linguagem de programação e mecanismos de comunicação.
• Declarativo: Aplicação de serviços de infra-estrutura
• Simplificação: Para todos os desenvolvedores, integradores e publicadores de aplicações.

Composição de Baixo para Cima

• Selecionar um jogo de componentes existentes para construir uma nova composição
• Configurar as propriedades dos componentes
• Desenha ligações internas
• Ajustar os componentes de uma composição e configurar as referências a serviços externos
• Não por a mão na composição do deployment

Composição de Cima para Baixo:

Começar com coleta de exigências para a composição nível de cima

• Define os serviços/referencias e propriedades para composição
• Quebrar da composição em componentes e em ligações entre eles
• Quebra recursiva de cada componente
• Entrega dos contratos dos componentes individuais para os desenvolvedores implementarem

Conjunto Heterogêneo

• Componentes numa mesma composição compartilham um contexto comum para muitos aspectos, tais como:

- a instalação, distribuição, as definições de segurança, registro de log, etc.

Implementando Reuso – Por configuração

• Selecione uma implementação de componente existente
• Configure seu comportamento (através de configs, propriedades, refs), para corresponder aos requerimentos/exigências atuais

- Exemplo: Configurar múltiplas instâncias do componente “ProductPricing”, cada uma com uma moeda, uma taxa, um gráfico de descontos, etc.

• Configure seu comportamento (através de configs, propriedades, refs), para corresponder aos requerimentos/exigências

Flexibilidade no Deployment

• Responsáveis pelo Deploy escolhem e configuram mecanismos de comunicação para os serviços/referências sem ter de modificar a implementação do componente

Abstrai declaração das políticas

0. Administrador de Politicas autor de policySets com as politicas concretas de SCA
1. Desenvolvedor especifica inteção na montagem de componente SCA
2. Desenvolvedor passa a montagem SCA para os Publicadores
3. Publicadores configuram montagems SCA, atribuindo conjunto de politicas para SCA (pode ser altomatizado)
4. Infra publica a montagem SCA configurada para o ambiente de SCA Runtime(servidor)
5. infra ou publicadores atualizam Registro de componentes(Registry)

Tecnologia SCA

As Especificações de SCA

OASIS SCA Comitês Técnicos

• OpenSCA Member Section
  SCA Assembly TC
  SCA Bindings TC
  SCA Policy TC
  SCA J TC
  SCA C-C++ TC
  SCA BPEL

Trabalho dos Comitês Técnicos para SCA

• Oasis produz Versões padrões das especificações de SCA

- conformidade nas indicações
- mandatório vs opcional
- portabilidade, interoperabilidade

• Suite de Teste

- Definir suítes de teste para checar conformidade

• Desafios

- Qual é uma boa suíte de testes para SCA?

- Coordenação entre os Comitês Técnicos

Trabalhos em Andamento

• Especificação para linguagem C
• Especificação para linguagem COBOL
• REST binding(s)
  - JSON, ATOM

Sumario

• OASIS SCA

- principal esforço para o próximo ano
- apelar para uma audiência muito grande

• 6 Comitês Técnicos para SCA avançar & coordenada!

Pessoal,

Como disse, irei postar essa semana uma visão detalhada do que é o padrão/especificação SCA (Service Componente Architecture), que foi criado pelo grupo osoa.org, neste grupo fazem parte a maioria dos fornecedores de soluções SOA e Aplication Servers, como IBM, BEA, ORACLE, SAP, RedHat e muitas outras estão entrando, como sempre a Microsoft não faz parte desse grupo.

No ultimo mes esta especificação foi passada a organização oasis, para que a mesma mantenha esse padrão de forma independente de fornecedor. Com isso foi criado o comite :http://www.oasis-opencsa.org/, que ficara responsável por evoluir este padrão, como podem perceber na OASIS o grupo foi intitulado como Open Composite Services Architecture, um dos principais nomes desse grupo é o Sr. Mike Edwards, (
Strategist – Emerging Technologies, SCA & SDO) , ele é um dos ativistas desse grupo em conjunto com outros grandes nomes como Robert Pincus (RogueWave), e outros.

Existe uma implementação Open Source chamado Tuscany, que pode ser acessado em http://incubator.apache.org/tuscany/, ele esta sendo mantido pelo apache.org, com contribuições fornecidas por esses grupos.

Sugiro a leitura de um paper interessante e inicial sobre o assunto, “Introducing SCA”, de David Chappell (http://www.davidchappell.com/articles/Introducing_SCA.pdf), onde ele faz uma afirmativa categórica: “Anyone who´s interested in the future of application development should also be interested in SCA”.
Para quem não conhece a OASIS, recomendo acessar seu portal.

A proposta da organização é bem clara: “OASIS (Organization for the Advancement of Structured Information Standards) is a not-for-profit consortium that drives the development, convergence and adoption of open standards for the global information society. The consortium produces more Web services standards than any other organization along with standards for security, e-business, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 5,000 participants representing over 600 organizations and individual members in 100 countries”.

A proposta do grupo CSA é bem simples:
“advances open standards that simplify SOA application development. Open CSA brings together vendors and users from around the world to collaborate on standard ways to unify services regardless of programming language or deployment platform. Open CSA promotes the further development and adoption of the Service Component Architecture (SCA) and Service Data Objects (SDO) families of specifications”.

A algumas semanas estive trocando ideias com Mike Edwards, e ele indica algumas literaturas para quem esta começando, Ele sugere a leitura do livro :

“SOA for the Business Developer: Concepts, BPEL and SCA”, de Ben Margolis.
Também sugere uma lista de papers disponíveis no site developerWoks, como:
1) SCA Application Development (parte 1 & 2) : An overview of SCA, acessado em http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scadev1/ e http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scadev2/ .

2) Building SOA Solutions with SCA (4 partes), http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.html

3) Java SCA invocation styles: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scajava/

4) Using PHP´s SCA and SDO extensions: http://www-128.ibm.com/developerworks/webservices/library/ws-soa-scasdo/

5) Introduction to Service Data Objects: http://www-128.ibm.com/developerworks/webservices/library/j-sdo/

E também recomenda acessar http://pecl.php.net/package/SCA_SDO para implementação do SCA/SDO em PHP.
Ok, acho que para começar tem bastante coisa para se ler e desenvolver…Mãos à obra!, no procisso port vou entrar em detalhes deste modelo de programação componentizada, que promete mexer com o mercado de desenvolvimento.

Esta semana iniciarei uma serie de materias para descrever o que é a Service Componente Arquitecture (SCA), e o que ela representa para o futuro da SOA, e todos os aspectos tecnicos deste padrão que ira revolucionar a forma de construção de componetes, e aplicações Enterprise.

Bem, esta é uma questão que toda vez eu sou questionado em minhas explanações sobre SOA que tenho feito para alguns profissionais pela empresa e mercado.
Além disto, esta é uma questão que se alastra desde os primórdios dos paradigmas de programação procedural, orientação a objetos, componentização, dentre outros.
Bom, para tentar responder a esta pergunta, antes de mais nada, vamos à alguns conceitos:
Atomicidade: Um serviço atômico, são serviços que desempenham uma tarefa ou ação específica.
Granularidade: Consiste na mensuração do tamanho, escala e nível de detalhes dos serviços. Onde serviços “gordos” são coarse-grained (baixa granularidade) e serviços “leves” são fine-grained (alta granularidade).
Para responder a esta questão, vamos considerar dois pontos.
Primeiro: Abordagem de Descobrimento dos Serviços
A atomicidade e/ou granularidade de um serviço pode depender da estratégia de descobrimento do mesmo. Ou seja, se nós fizermos uma abordagem “top-down“, primeiro iremos identificar os nossos processos de negócios, onde cada atividade dos mesmos podem ser desmembradas em sub-processos e assim por diante, até que não seja mais possível desmembrá-los. E neste ponto, teremos nossos serviços.
Por outro lado, se nós adotarmos uma abordagem “bottom-up“, nossos serviços vão sendo expostos através das funcionalidades candidatas dos sistemas legados existentes, onde a granularidade e a atomicidade destes serviços vão sendo refinadas até que os mesmos possam ser compostos (orquestrados) em processos de negócios.
Segundo: Características dos Serviços
Antes de percebermos as características dos serviços, primeiramente os serviços podem ser classificados da seguinte forma:
Serviços de Negócios (Business Level Services): Este serviços representam atividades/funções reais de negócios.
Serviços de Infra-Estrutura (Infrastructure Level Services): Estes serviços não contém regras de negócios, mas são necessários para suportar necessidades dos serviços de negócios.
Com isto, dependendo da classificação dos serviços, podemos identificar suas características e objetivos chaves que julgamos necessários para cada um dos serviços, tais como: reusabilidade, visibilidade, transacionabilidade, performance, dentre outras; Que devem serem levados em consideração em qualquer projeto de adoção SOA. Pois, um serviço pode ser atômico em virtude da reusabilidade, porém não atômico devido as dificuldade transacionais. Da mesmo forma, um serviço pode ser fine-grained em virtude da visibilidade, porém coarse-grained em razão da performance.
Portanto, segue abaixo uma tabela ou matriz, que talvez nos ajude a identificar melhor a atomicidade e/ou granularidade dos nossos serviços que estão projetados, dentro das características principais desejadas.
Obs: Na imagem acima, “Top-Down” e “Bottom-Up” indicam as abordagens explicitadas um pouco mais acima. Onde, “Top-Down” está mais direcionada aos processos de negócios e “Bottom-Up” às estratégias de migração.
Bom, como podemos perceber a definição da atomicidade e granularidade dos serviços que farão parte de um projeto de adoção SOA é uma tarefa bastante importante e delicada. Onde, a estratégia adotada para identenficação das mesmas, pode interferir no sucesso ou fracasso do projeto.
Espero ter ajudado um pouco neste grande dilema.

Depois de vários anos trabalhando com sistemas de missão critica 24×7, a partir da década de 90, em ambientes UNIX, e linguagens C e C++, para as áreas de telecomunicações e bancarias, e nos últimos 7 anos com linguagens mais novas como Java, vi a necessidade de compartilhar minhas experiências com a comunidade da engenharia de software, e mais recentemente com a intitulada Arquitetura de Software, que nada mais é que a velha Engenharia só que com um novo nome.
Também porque nos últimos anos tenho se concentrado nas arquiteturas e projetos de integração usando tanto tecnologias e linguagens na plataforma Microsoft, como em Open-Source como Java e mais recentemente em arquitetura SOA, que nada mais é na minha opinião a evolução da arquitetura EAI
Depois de todos os trabalhos e pesquisas que realizei, estou criando este blog pois senti a necessidade de disponibilizar um lugar único e central para o esclarecimento, desmistificação e disponibilização de informações serias e atualizadas no que tange a Arquitetura Orientada a Serviços e o processo de integração de software, que é uma das minhas especialidades.
Disponibilizarei informações atualizadas do mundo SOA, integração e missão critica. Também para desmistificar aspectos referente a ferramentas, produtos, tecnologias e padrões para uma boa implementação SOA, independente de fabricante. Procurarei ser o mais imparcial possível em relação a produtos e linguagens, para sim expor as melhores soluções e padrões para uma boa fundação SOA, e o futuro da mesma. Diferente de alguns blogs, Sites, e vendedores de soluções, como já me deparei no inicio dos meus trabalhos em SOA. Mantenho contato freqüente com importantes arquitetos e engenheiros da arquitetura SOA atual no mundo, tanto da IBM, BEA, e RogueWave, e com os consórcios para padronização da fundação de SOA, como osoa e oasis, Procurarei esclarecer possíveis duvidas na implementação, governança de arquiteturas para integração e SOA, e também para os programadores, e arquitetos que estão iniciando nesta Arquitetura.
Mas desde já quero esclarecer que SOA não é tecnologia e sim uma Arquitetura, como muitos por ai estão dizendo.