52
ENTERPRISE MASHUPS SOA 2.0 SoaExpert.com.br - Felipe Kenobi

Service Component Architecture

Embed Size (px)

DESCRIPTION

Apresentação em português realizada no evento JustJava08 por Felipe Olivelra (Kenobi), instrutor da SOAExpert.

Citation preview

Page 1: Service Component Architecture

ENTERPRISE MASHUPS SOA 2.0

SoaExpert.com.br - Felipe Kenobi

Page 2: Service Component Architecture

Agenda

- SOA TimeLine - Enterprise Service Bus - SCA – Service Component Architecture

(Mashups) - Demo ( 10 min)

Page 3: Service Component Architecture

Do XML para WebServices ao SOA XML uma derivação do SGML – Standard

Generalized Markup Language, anos 60. XML ganha popularidade nos anos 90 ,

movimento e-business. Schema Definition Language (XSD) e

XSL-XSLT ( Transformation Language), são pontos chave da tecnologia XML.

Page 4: Service Component Architecture

WebServices – breve histórico

Em 2000 o W3C recebeu uma submissão do SOAP – Simple Object Protocol.

Muitas companhias viram o potencial para avançar o estado da tecnologia de e-business, criando uma forma de se comunicar através da internet.

A peça central do conceito é a Interface Pública, que permite sua invocação através de assinatura e identificação – WSDL ( Web Service Description Language) – 2001.

Page 5: Service Component Architecture

WebServices – breve histórico

Outros formatos como XML-RPC foram considerados, mas a indútria acabou adotando o SOAP como padrão.

Primeira geração trazia ainda a especificação UDDI ,

originalmente desenvolvida pela UDDI.org

Início das plataformas de produtos MOMS – Messaging Oriented Middleware.

WebServices começam de fato a facilitar a troca de informações em sistemas B2B e segue como alternativa ao EDI – Eletronic Data Interchange.

Page 6: Service Component Architecture

SOA – O início

Utilizar a estrutura de WebServices para desacoplar a arquitetura.

Frequentemente classificado de diferentes

maneiras, dependendo da implementação tecnológica utilizada.

O modelo inicial , mais inspirado no conjunto

de definções padrão dos WebServices, definiam uma arquitetura com 3 componentes básicos:

Page 7: Service Component Architecture

SOA – O início

Service request

or

Service

registry

Service

registry

Service

provider

Discover and retrieve WSDL

Publish WSDL

Exchange SOAP Messages

Page 8: Service Component Architecture

SOA – O início

O modelo primitivo é facilmente atingido hoje em dia.

Diversos players do mercado começam a manifestar interesse em evoluir o conceito

SOA Conteporânio começa a ser desenhado

colaborativamente e uma série de extensões começam a surgir sobre a primeira geração de WebServices - Segunda geração ( WS-*)

Page 9: Service Component Architecture

SOA Contemporânio

WS-Addressing WS-RealiableMessaging WS-Policy Framework( WS-Policy Attachment e

WS-Policy Assertions) WS-MetadaExchange WS-Security(XML-Encryption, XML-Signature e

SAML) WS-Notification Framework (WS-

BaseNotification, WS-Topics, WS-BrokeredNotification)

WS-Eventing

Page 10: Service Component Architecture

Banquete Completo

Page 11: Service Component Architecture

Hub and Spoke & ESB

Hub and Spoke : Ponto central para serviços como transformação, roteamento e controle de transações.

Hub ( usualmente um Message Broker) é

uma peça monolítica de software.

Hub – providencia a lógica do serviço de integração centralizada ex. Integregation Server, Process Manager, Database …

Page 12: Service Component Architecture

Enterprise Service Bus

Bus – Um Hub que suporta uma implementação distribuída ou federada.

ESB – Um conjunto de Bus, integrado com seus diferentes protocolos-adaptadores, conectando diferentes formatos, utilizados em cada Bus.

Page 13: Service Component Architecture

ESB – Surgimento Early Version O nome ESB era ligado somente ao

“service enabling”. Não existia padrões estipulados pelo

mercado – indústria.

Page 14: Service Component Architecture

Por que utilizar um ESB ?

Arquitetura desacoplada – “Lose Coupling” Localização Transparente de serviços Mediação Schema Transformation Service Aggregation Load Balance Reforço de segurança Monitoria Configuração vs codificação

Page 15: Service Component Architecture

Tight Couple – EJB Model

Page 16: Service Component Architecture

Visão Point-to-Point

Page 17: Service Component Architecture

Expandindo apenas um bit…

Page 18: Service Component Architecture

Loose Coupling

WebServices podem proporcionar desacoplamento entre sistemas ?

Page 19: Service Component Architecture

Location Transparency

Uma estratégia para esconder os endpoints do service client.

Aumenta a flexibilidade para administrar

seus serviços.

Page 20: Service Component Architecture

Mediation

O ESB de fato é uma camada de mediação, residindo entre o service client e service provider.

Capacidade de realizar múltiplas operações, como transformação de estrutura de dados, ou schema de mensagens.

Direciona a rota das mensagens, para o serviço apropriado de acordo com o conteúdo.

Page 21: Service Component Architecture

Schema Transformation

Um serviço publicado utiliza um outro schema.

Habilidade de transformar dados de um schema para um outro.

Algumas tecnologias correlatas: XSLT, Xquery e Xpath.

Page 22: Service Component Architecture

Service Aggregation

ESB pode atuar como um façade e realizar uma série de chamadas como um serviço único.

Service Aggregation é aderente ao pattern.

Realiza múltiplas chamadas encapsulada num único proxy e retorna um único resultado.

Similar à service orchestration, entretanto inclui alguma lógica.

Page 23: Service Component Architecture

Load Balance

ESBs podem distribuir os requests através de múltiplos service endpoints.

Permite ao admistrador acrescer ou

retirar endpoints sem necessidade de reiniciar o serviço.

Page 24: Service Component Architecture

Enforcing Security

Centraliza a administração.

Permite um maior nível de controle sobre falhas e exposições dos serviços.

Dirigida através frameworks de segurança –

Policy-driven.

A utilização de policies padroniza um método para criação de cada webservice individual.

Page 25: Service Component Architecture

Monitoring

Permite os admistradores saberem o status de cada serviço para agirem reativamente ou pró-ativamente.

Pró-ativamente, permite um admistrador

realizar performance-tune sobre os serviços a fim de melhorar performance por exemplo.

Reativamente, permite definir uma série de alertas à condições específicas.

Definição de métricas e políticas de SLA.

Page 26: Service Component Architecture

Configuration vs Coding

ESBs modernos são baseados em configuração e não programação.

Ciclo de desenvolvimento simplificado,

basta alterara algo e esta é imediatamente refletido no comportamento do serviço.

Page 27: Service Component Architecture

Enterprise Integration Patterns Tem coisas, que só o ESB faz por você .

Page 28: Service Component Architecture

Demo – Enterprise Service Bus Estou num mac, se estiver lento a culpa

é do Ruindows ou da VMWare :-P

Page 29: Service Component Architecture

Service Component Architecture (SCA) O que é uma aplicação ? Um conjunto de componentes de

software trabalhando em conjunto, harmonia(rs).

Componentes podem ou não utilizar a

mesma tecnologia, estar ou não na mesma máquina….

Page 30: Service Component Architecture

Components e Composites (SCA) Composite é uma composição lógica,

que pode rodar num simples processo numa máquina ou distribuída.

Uma aplicação completa pode ser construída por um único composite, ou combinar uma série deles.

Page 31: Service Component Architecture

Components e Composites (SCA)

Page 32: Service Component Architecture

Components e Composites (SCA) Um SCA Composite é tipicamente descrito e associado a

um arquivo de configuração XML chamado – Service Component Definition Language (SCDL).

Page 33: Service Component Architecture

Domains (SCA)

Domínio é um agrupamento lógico de composites, contendo um ou mais.

Os composites não precisam estar necessariamente na mesma máquina ou sob o mesmo player.

Domínios são conceitos importantes quando pensamos em aplicações distribuídas.

Page 34: Service Component Architecture

Domain (SCA)

Page 35: Service Component Architecture

Domain (SCA)

Page 36: Service Component Architecture

Entendimento sobre Componentes Componentes são como átomos de uma

aplicação baseada em SCA.

Os átomos podem ser reagrupados de maneira consitente formando outras variçãoes de configuração.

Componente também pode ser entendido como uma instância de uma implementação.

A configuração expressada em SCDL define como os componentes interagem fora do seu mundo.

Page 37: Service Component Architecture

Services, References and Properties

Page 38: Service Component Architecture

Bindings

Page 39: Service Component Architecture

Já que estamos num evento Java… Os conceitos fundamentais sobre componentes SCA são simples: services,

references properties e algumas vezes bindings.

Algumas tecnologias hoje no mundo java fazem muito bem esse tipo de abstração – SpringFramework, que provisiona suporte explícito para serviços, referências e propriedades.

Algumas tecnologias anteriores como EJB, sãodesenhadas para encapsular a lógica de negócias, mas não enxergam os serviços como fundamentais.

Uma arquitetura java SCA-based pode suportar diversas formas de

comunicação de maneira transparente.

Por essas e outras, acredito que o formato SCA deve simplificar bastante a

vida do desenvolvedor Java

Page 40: Service Component Architecture

Defining Services / SCA-java

Page 41: Service Component Architecture

Defining References

MonitorService é uma interface e para invocá-la usamos o método usageCount(x);

Em tempo de execução a responsabilidade de localizar a instância é passada e o serviço correto é invocado via IoC .

Page 42: Service Component Architecture

Defining Properties

Assim como as references e remote services, properties são identificadas usando uma anotação.

Esta propriedade pode estar assinalada em

um atributo ou método e indica que o valor deve ser lido do arquivo de configuração SCDL do composite o qual o componente pertence.

Page 43: Service Component Architecture

Defining Bindings

Page 44: Service Component Architecture

Defining Bindings

A versão 1.0 do SCA Java component model não define um meio do desenvolvedor especificar um binding diretamente em java.

A escolha dos bindings de um service ou uma reference são escolhidos em rutime por uma comunicação intra-domain ou explicitados no SCDL.

Page 45: Service Component Architecture

Defining Other Aspects of a Component

@OneWay, especifica que uma operação não retorna resposta.

@Scope, controla o ciclo de vida do componente – Conversational ou Stateless.

@Callback, permite que uma interface da callback seja definida. Suporta comunicação two-way, entre componentes usando bi-directional interfaces.

Page 46: Service Component Architecture

Configuring a Component

Page 47: Service Component Architecture

Configuring a composite

Page 48: Service Component Architecture

Wires and Promotion

Page 49: Service Component Architecture

Using Policy

SCA possui um policy framework que define praticamente duas categorias:

- Interaction policies: Modifica como um componente interage com outros componentes. (segurança).

- Implementation policies: Modifica o comportamento local. Ex. Como um componente se comporta dentro de uma transacação.

Page 50: Service Component Architecture

Juntando tudo

Page 51: Service Component Architecture

Projetos SCA

Apache Tuscany - http://tuscany.apache.org

Fabric3 - http://fabric3.codehaus.org Newton* http://newton.codecauldron.org

Page 52: Service Component Architecture

Questions & Answers

Felipe “Kenobi” / [email protected] Em breve > www.soaexpert.com.br

Obrigado pela paciência e Acordem!! A palestra da Yara e Alberto vai ser muito menos chata, I hope .