Service Component Architecture

1,989 views
1,899 views

Published on

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

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,989
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
56
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Não apenas XML era usadno para representar data, mas o XSD – Schema Definition Language e transformações XSL – ( XSTL) também faziam parte do conjunto da tecnologia XML.
  • - A especificação SOAP veio originalmente desenhada para refazer as comunicações proprietárias RPC. A idéia era trafegar dados parametrizados e serializados entre componentes , em XML de deserializados novamente em formato nativo.
  • Universal Description Discovery and integration.
  • Testando notas
  • Lembrar do DNS Soluções mais robustas possuem uma camada de mediação entre produtores e clientes, como por exemplo um cliente que invoca um serviço através de HTTP e num nível mais baixo você infoca através de JMS.
  • Inclua ou retire serviços sem necessidade de recompilar seus clients.
  • Analogia do Telefone
  • Em qualuer aplicação, mesmo java pra java, integrando através de interfaces, ou expandindo para WebServices, consumo numa aplicação java Sempre existe um problema a ser resolvido, descrever como essas peças isoladas interagem uma com as outras. No pensamento SOA essas interações podem ser descritas como serviços , separando claramente a tecnologia da função provisionada. SCA define uma maneira geral e especifica como esses componentes podem ser combinadas numa estrutura maior, chamada Composites.
  • Em qualuer aplicação, mesmo java pra java, integrando através de interfaces, ou expandindo para WebServices, consumo numa aplicação java Sempre existe um problema a ser resolvido, descrever como essas peças isoladas interagem uma com as outras. No pensamento SOA essas interações podem ser descritas como serviços , separando claramente a tecnologia da função provisionada. SCA define uma maneira geral e especifica como esses componentes podem ser combinadas numa estrutura maior, chamada Composites.
  • Pronunciado skiddle. Components e composits são peças fundamentais para cada SCA Application. Ambos são partes para formar uma construção maior chamada de domínio.
  • Qual a diferença lógica entre Composite e Domain ? O composite precisa rodar num único vendor runtime
  • Cada componente é uma implementação de uma lógica. Falando em Java, pode ser a implementação de uma interface ou BPEL – WSDL. Um ponto a destacar são as referências, usadas anteriormente nos anos 90, quando falamos em aplicações distribuídas. legal, é que a referência pode nos indicar de maneira clara a dependência do componente sobre outros, para descobertas automáticas, criando tipos de Injeção de dependência. Propriedade dos componentes servem para parametrizar o comportamento dos mesmos, como um componente de região, você quer customizar por país.
  • Services e references dizem que um componente se comunica com o outro, entretanto, eles não dizem como essa comunicação é feita. Isso fica a cargo dos binds.
  • Bindings podem ser assinalados para serviços e para referência e cada um especifica um protocolo particular.
  • @Scope uma coisa interessante é que o atributo só pode ser utilizado com protocolos que propagam sessão, como SOAP.
  • Service Component Architecture

    1. 1. ENTERPRISE MASHUPS SOA 2.0 SoaExpert.com.br - Felipe Kenobi
    2. 2. Agenda <ul><li>- SOA TimeLine </li></ul><ul><li>- Enterprise Service Bus </li></ul><ul><li>- SCA – Service Component Architecture (Mashups) </li></ul><ul><li>- Demo ( 10 min) </li></ul>
    3. 3. Do XML para WebServices ao SOA <ul><li>XML uma derivação do SGML – Standard Generalized Markup Language, anos 60. </li></ul><ul><li>XML ganha popularidade nos anos 90 , movimento e-business. </li></ul><ul><li>Schema Definition Language (XSD) e XSL-XSLT ( Transformation Language), são pontos chave da tecnologia XML. </li></ul>
    4. 4. WebServices – breve histórico <ul><li>Em 2000 o W3C recebeu uma submissão do SOAP – Simple Object Protocol. </li></ul><ul><li>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. </li></ul><ul><li>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. </li></ul>
    5. 5. WebServices – breve histórico <ul><li>Outros formatos como XML-RPC foram considerados, mas a indútria acabou adotando o SOAP como padrão. </li></ul><ul><li>Primeira geração trazia ainda a especificação UDDI , originalmente desenvolvida pela UDDI.org </li></ul><ul><li>Início das plataformas de produtos MOMS – Messaging Oriented Middleware. </li></ul><ul><li>WebServices começam de fato a facilitar a troca de informações em sistemas B2B e segue como alternativa ao EDI – Eletronic Data Interchange. </li></ul>
    6. 6. SOA – O início <ul><li>Utilizar a estrutura de WebServices para desacoplar a arquitetura. </li></ul><ul><li>Frequentemente classificado de diferentes maneiras, dependendo da implementação tecnológica utilizada. </li></ul><ul><li>O modelo inicial , mais inspirado no conjunto de definções padrão dos WebServices, definiam uma arquitetura com 3 componentes básicos: </li></ul>
    7. 7. SOA – O início Service registry Discover and retrieve WSDL Publish WSDL Exchange SOAP Messages Service requestor Service provider
    8. 8. SOA – O início <ul><li>O modelo primitivo é facilmente atingido hoje em dia. </li></ul><ul><li>Diversos players do mercado começam a manifestar interesse em evoluir o conceito </li></ul><ul><li>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-*) </li></ul>
    9. 9. SOA Contemporânio <ul><li>WS-Addressing </li></ul><ul><li>WS-RealiableMessaging </li></ul><ul><li>WS-Policy Framework( WS-Policy Attachment e WS-Policy Assertions) </li></ul><ul><li>WS-MetadaExchange </li></ul><ul><li>WS-Security(XML-Encryption, XML-Signature e SAML) </li></ul><ul><li>WS-Notification Framework (WS-BaseNotification, WS-Topics, WS-BrokeredNotification) </li></ul><ul><li>WS-Eventing </li></ul>
    10. 10. Banquete Completo
    11. 11. Hub and Spoke & ESB <ul><li>Hub and Spoke : Ponto central para serviços como transformação, roteamento e controle de transações. </li></ul><ul><li>Hub ( usualmente um Message Broker) é uma peça monolítica de software. </li></ul><ul><li>Hub – providencia a lógica do serviço de integração centralizada ex. Integregation Server, Process Manager, Database … </li></ul>
    12. 12. Enterprise Service Bus <ul><li>Bus – Um Hub que suporta uma implementação distribuída ou federada. </li></ul><ul><li>ESB – Um conjunto de Bus, integrado com seus diferentes protocolos-adaptadores, conectando diferentes formatos, utilizados em cada Bus. </li></ul>
    13. 13. ESB – Surgimento Early Version <ul><li>O nome ESB era ligado somente ao “service enabling”. </li></ul><ul><li>Não existia padrões estipulados pelo mercado – indústria. </li></ul>
    14. 14. Por que utilizar um ESB ? <ul><li>Arquitetura desacoplada – “Lose Coupling” </li></ul><ul><li>Localização Transparente de serviços </li></ul><ul><li>Mediação </li></ul><ul><li>Schema Transformation </li></ul><ul><li>Service Aggregation </li></ul><ul><li>Load Balance </li></ul><ul><li>Reforço de segurança </li></ul><ul><li>Monitoria </li></ul><ul><li>Configuração vs codificação </li></ul>
    15. 15. Tight Couple – EJB Model
    16. 16. Visão Point-to-Point
    17. 17. Expandindo apenas um bit…
    18. 18. Loose Coupling <ul><li>WebServices podem proporcionar desacoplamento entre sistemas ? </li></ul>
    19. 19. Location Transparency <ul><li>Uma estratégia para esconder os endpoints do service client . </li></ul><ul><li>Aumenta a flexibilidade para administrar seus serviços. </li></ul>
    20. 20. Mediation <ul><li>O ESB de fato é uma camada de mediação, residindo entre o service client e service provider. </li></ul><ul><li>Capacidade de realizar múltiplas operações, como transformação de estrutura de dados, ou schema de mensagens. </li></ul><ul><li>Direciona a rota das mensagens, para o serviço apropriado de acordo com o conteúdo. </li></ul>
    21. 21. Schema Transformation <ul><li>Um serviço publicado utiliza um outro schema. </li></ul><ul><li>Habilidade de transformar dados de um schema para um outro. </li></ul><ul><li>Algumas tecnologias correlatas: XSLT, Xquery e Xpath. </li></ul>
    22. 22. Service Aggregation <ul><li>ESB pode atuar como um façade e realizar uma série de chamadas como um serviço único. </li></ul><ul><li>Service Aggregation é aderente ao pattern. </li></ul><ul><li>Realiza múltiplas chamadas encapsulada num único proxy e retorna um único resultado. </li></ul><ul><li>Similar à service orchestration, entretanto inclui alguma lógica. </li></ul>
    23. 23. Load Balance <ul><li>ESBs podem distribuir os requests através de múltiplos service endpoints. </li></ul><ul><li>Permite ao admistrador acrescer ou retirar endpoints sem necessidade de reiniciar o serviço. </li></ul>
    24. 24. Enforcing Security <ul><li>Centraliza a administração. </li></ul><ul><li>Permite um maior nível de controle sobre falhas e exposições dos serviços. </li></ul><ul><li>Dirigida através frameworks de segurança – Policy-driven. </li></ul><ul><li>A utilização de policies padroniza um método para criação de cada webservice individual. </li></ul>
    25. 25. Monitoring <ul><li>Permite os admistradores saberem o status de cada serviço para agirem reativamente ou pró-ativamente. </li></ul><ul><li>Pró-ativamente, permite um admistrador realizar performance-tune sobre os serviços a fim de melhorar performance por exemplo. </li></ul><ul><li>Reativamente, permite definir uma série de alertas à condições específicas. </li></ul><ul><li>Definição de métricas e políticas de SLA. </li></ul>
    26. 26. Configuration vs Coding <ul><li>ESBs modernos são baseados em configuração e não programação. </li></ul><ul><li>Ciclo de desenvolvimento simplificado, basta alterara algo e esta é imediatamente refletido no comportamento do serviço. </li></ul>
    27. 27. Enterprise Integration Patterns <ul><li>Tem coisas, que só o ESB faz por você  . </li></ul>
    28. 28. Demo – Enterprise Service Bus <ul><li>Estou num mac, se estiver lento a culpa é do Ruindows ou da VMWare :-P </li></ul>
    29. 29. Service Component Architecture (SCA) <ul><li>O que é uma aplicação ? </li></ul><ul><li>Um conjunto de componentes de software trabalhando em conjunto, harmonia(rs). </li></ul><ul><li>Componentes podem ou não utilizar a mesma tecnologia, estar ou não na mesma máquina…. </li></ul>
    30. 30. Components e Composites (SCA) <ul><li>Composite é uma composição lógica, que pode rodar num simples processo numa máquina ou distribuída. </li></ul><ul><li>Uma aplicação completa pode ser construída por um único composite, ou combinar uma série deles. </li></ul>
    31. 31. Components e Composites (SCA)
    32. 32. Components e Composites (SCA) <ul><li>Um SCA Composite é tipicamente descrito e associado a um arquivo de configuração XML chamado – Service Component Definition Language (SCDL). </li></ul>
    33. 33. Domains (SCA) <ul><li>Domínio é um agrupamento lógico de composites , contendo um ou mais. </li></ul><ul><li>Os composites não precisam estar necessariamente na mesma máquina ou sob o mesmo player . </li></ul><ul><li>Domínios são conceitos importantes quando pensamos em aplicações distribuídas. </li></ul>
    34. 34. Domain (SCA)
    35. 35. Domain (SCA)
    36. 36. Entendimento sobre Componentes <ul><li>Componentes são como átomos de uma aplicação baseada em SCA. </li></ul><ul><li>Os átomos podem ser reagrupados de maneira consitente formando outras variçãoes de configuração. </li></ul><ul><li>Componente também pode ser entendido como uma instância de uma implementação. </li></ul><ul><li>A configuração expressada em SCDL define como os componentes interagem fora do seu mundo. </li></ul>
    37. 37. Services, References and Properties
    38. 38. Bindings
    39. 39. Já que estamos num evento Java… <ul><li>Os conceitos fundamentais sobre componentes SCA são simples: services, references properties e algumas vezes bindings. </li></ul><ul><li>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. </li></ul><ul><li>Algumas tecnologias anteriores como EJB, sãodesenhadas para encapsular a lógica de negócias, mas não enxergam os serviços como fundamentais. </li></ul><ul><li>Uma arquitetura java SCA-based pode suportar diversas formas de comunicação de maneira transparente. </li></ul><ul><li>Por essas e outras, acredito que o formato SCA deve simplificar bastante a vida do desenvolvedor Java  </li></ul>
    40. 40. Defining Services / SCA-java
    41. 41. Defining References <ul><li>MonitorService é uma interface e para invocá-la usamos o método usageCount(x); </li></ul><ul><li>Em tempo de execução a responsabilidade de localizar a instância é passada e o serviço correto é invocado via IoC . </li></ul>
    42. 42. Defining Properties <ul><li>Assim como as references e remote services, properties são identificadas usando uma anotação. </li></ul><ul><li>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. </li></ul>
    43. 43. Defining Bindings
    44. 44. Defining Bindings <ul><li>A versão 1.0 do SCA Java component model não define um meio do desenvolvedor especificar um binding diretamente em java. </li></ul><ul><li>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. </li></ul>
    45. 45. Defining Other Aspects of a Component <ul><li>@OneWay, especifica que uma operação não retorna resposta. </li></ul><ul><li>@Scope, controla o ciclo de vida do componente – Conversational ou Stateless. </li></ul><ul><li>@Callback, permite que uma interface da callback seja definida. Suporta comunicação two-way, entre componentes usando bi-directional interfaces. </li></ul>
    46. 46. Configuring a Component
    47. 47. Configuring a composite
    48. 48. Wires and Promotion
    49. 49. Using Policy <ul><li>SCA possui um policy framework que define praticamente duas categorias: </li></ul><ul><li>- Interaction policies: Modifica como um componente interage com outros componentes. (segurança). </li></ul><ul><li>- Implementation policies: Modifica o comportamento local. Ex. Como um componente se comporta dentro de uma transacação. </li></ul>
    50. 50. Juntando tudo
    51. 51. Projetos SCA <ul><li>Apache Tuscany - http://tuscany.apache.org </li></ul><ul><li>Fabric3 - http://fabric3.codehaus.org </li></ul><ul><li>Newton* http://newton.codecauldron.org </li></ul>
    52. 52. Questions & Answers <ul><li>Felipe “Kenobi” / [email_address] </li></ul><ul><li>Em breve > www.soaexpert.com.br </li></ul><ul><li>Obrigado pela paciência e Acordem!! A palestra da Yara e Alberto vai ser muito menos chata, I hope  . </li></ul>

    ×