Modelagem atravs de SOAML Oq acha do titulo?

Claudia Goetz, Henrique Zmuda da Silva Instituto de Informtica Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal 15.064 91.501-970 Porto Alegre RS Brazil
{henriquezmuda;claudiagoetz?}@hotmail.com

Abstract. Tu podes traduzir para ingles o resumo (esta cheio de erros) This paper shows through examples and reviews the use of SoaML (ServiceOriented Architecture Modeling Language) is an OMG standard with which aims to bring clarification of the content and help in the perception of the potential of SOA. SoaML is a small set of UML extensions that support SOA modeling, as well as an abstraction of SOA emphasizing the description of the needs and resources of the participants and linking them in service value chains. Resumo. Este artigo mostra atravs de comentrios e exemplos a utilizao de SoaML (Service-Oriented Architecture Modeling Language) com um padro OMG que tem como objetivo trazer esclarecimento do contedo e ajudar na percepo do potencial do SOA. SoaML um pequeno conjunto de extenses UML que oferecem suporte modelagem SOA, assim como uma abstrao de SOA enfatizando a descrio das necessidades e recursos dos participantes e ligando-os nas cadeias de valor do servio.

1. Introduo SoaML

1.1. SOA e SoaML

A Arquitetura Orientada a Servio (SOA) uma forma simples de descrever e compreender as organizaes, comunidades e sistemas,

maximizando a agilidade, escalabilidade e interoperabilidade. Os profissionais geralmente utilizam SOA tanto para definir um estilo de arquitetura quanto para descrever uma infraestrutura de TI que possibilita a operao de sistemas de TI que so construdos utilizando esse estilo de arquitetura. Permitindo oferecer os nossos recursos em troca de algum valor, estabelecendo assim, uma comunidade,

processo ou mercado, facilitando a integraes de aplicaes existentes, bem como na criao e integrao de novas aplicaes. Para atingir seu potencial, uma infraestrutura de TI baseada em SOA necessita ser relevante aos negcios, e portanto, dirigida pelo negcio e implementada para oferecer suporte aos negcios. Isso muito difcil de se conseguir se os requisitos dos negcios forem uma simples lista de requisitos e o nvel de abstrao do SOA for capturado em vrios documentos XML que representam uma coleo de servios da Web. Ento, SOA utilizado para modelar como as pessoas, organizaes e sistemas fornecem e utilizam os servios para alcanar resultados. SoaML fornece um modo padro para solues SOA usando o Unified Modeling Language (UML). Utilizando por exemplo, os mecanismos de extenso built-in de MOF e UML para definir os conceitos de SOA em termos de conceitos de UML existentes, e onde algumas ferramentas podem oferecer recursos de modelagem avanada. A SoaML oferece vrios benefcios:

Permite a escolha de plataformas flexveis Permite a interoperabilidade e integrao no nvel do modelo Trata dos interesses da integrao de negcios e interao de servios no nvel da arquitetura utilizando a arquitetura como ponto entre requisitos de negcios e solues de TI automatizadas

Fornece um nvel mais alto de abstrao separado da variabilidade da plataforma e da complexidade dos padres dos documentos XML de servios da Web de nvel inferior

Desacopla implementaes de solues de plataformas de arquitetura para prevenir que as solues existentes impeam a evoluo da plataforma

Habilita o SOA tanto nas plataformas existentes como entre elas, atravs de model-driven architecture (MDA)

Alavanca e se integra a padres OMG existentes para o desenvolvimento e gerenciamento de ciclos de vida de ponta a ponta

1.2. Prestando suporte as perspectivas de negcios em SOA

A utilizao de SOA com uma variedade de abordagens e tecnologias, demostra uma opinio expressa de sua importncia na abordagem de arquiteturas de sistemas. Utilizado para compreender e especificar como as coisas podem funcionar melhor para cumprir um conjunto de metas e objetivos As arquiteturas descritas com SOA podem ser arquiteturas de negcios, arquiteturas de misso da comunidade, ou arquiteturas de sistemas de tecnologia da informao - tudo pode ser igualmente orientada a servios. A abordagem para a arquitetura SOA ajuda a separar as preocupaes sobre o que precisa ser feito da forma como ele feito, onde feito, ou quem ou o que o faz. Alguns outros pontos de vista "SOA e Web Services" so muito focados tecnologia e em lidar com os "bits e bytes" de computao distribuda. Estas preocupaes de tecnologia so importantes e se unem, mas no so o nico foco de SOA como expresso por SoaML. Essas tecnologias tambm podem ser suportados pela SoaML atravs de perfis de tecnologia e vrios "Modelos Dirigidos a Arquitetura" mtodos para a implementao de solues baseadas em modelos (como servios web e CORBA). SoaML explora a tecnologia como um meio para um fim, mas no se limita a arquitetura de tecnologia. Na verdade, a maior alavancagem da contratao de SOA vem do entendimento de uma comunidade, processo, ou da empresa como um conjunto de servios inter-relacionados e de apoio que a empresa orientada a servios tem com sistemas de servios habilitados.

1.3. Abordagem baseada em interface para SOA

SoaML integra capacidades de modelagem e de apoio utilizando SOA em diferentes nveis e com diferentes metodologias. Em apoio especial para uma abordagem de "contract based" e "interface based" o que, em geral, segue os elementos "ServiceContract" e "ServiceInterface" do perfil SoaML,

respectivamente. SoaML suporta diferentes abordagens para SOA, o que resulta em modelos diferentes, mas que se sobrepem aos elementos de perfil. Antes de abordar as diferenas, vamos rever algumas das semelhanas e terminologia: Participantes - Os participantes so entidades ou tipos especficos de entidades que fornecem ou usam os servios. Os participantes podem representar pessoas, organizaes ou componentes de sistemas de informao. Os participantes podem fornecer qualquer nmero de servios e consumir qualquer nmero de servios. Portas - participantes fornecem ou consomem servios atravs de portas. A porta a parte ou caracterstica de um participante que o ponto de interao para um servio - onde fornecido ou consumido. A porta onde um servio oferecido podendo ser designado como uma porta "Servio", e onde um servio consumido pode ser designado como uma porta "Request". Descrio do servio - a descrio de como o participante interage para fornecer ou utilizar um servio encapsulado em uma especificao para o servio - existem trs maneiras de especificar uma interao de servio - uma interface UML, um ServiceInterface e um ServiceContract. Estas formas diferentes para especificar um servio relacionam com a abordagem SOA e a complexidade do servio, mas em cada caso, resultar em interfaces e comportamentos que definem a forma como o participante ir fornecer ou utilizar um servio atravs de portas. As descries de servios so independentes, mas consistente de como o provedor fornece o servio ou como (ou porque) o consumidor consome. Esta separao de interesses entre a descrio do servio, e como ele implementado fundamental para SOA. A especificao do servio especifica a forma de como os consumidores e os prestadores devem interagir atravs de seus portos para decretar um servio, mas no como eles fazem isso.

 Recursos - os participantes que fornecem um servio devem ter a capacidade de fornece-lo, mas diferentes fornecedores podem ter diferentes recursos para prestar o mesmo servio podendo alguns at "terceirizar" ou delegar a execuo do servio por meio de um pedido de servio a outros. Os recursos de trs do servio iro fornecer o servio de acordo com a sua descrio e tambm podendo ter dependncias em outros servios para fornecer essa capacidade. Os recursos de servio so muitas vezes parte integrante do processo de negcio do provedor, podendo ser visto a partir de duas perspectivas: as capacidades de um participante que podem ser exploradas para a prestao de servios, bem como os recursos necessrios para a empresa que podem ser utilizados para identificar candidatos de servios. Estas abordagens para especificar um servio podem ser resumidas como: Interfaces simples - a interface simples chama a ateno para a interao oneway fornecido por um participante em uma porta representado como uma interface UML. O participante recebe operaes nesta porta e pode fornecer resultados para o chamador. Este tipo de interface de um modo pode ser usado com chamadas "annimas" e o participante no faz suposies sobre o chamador ou a coreografia do servio. O servio one-way corresponde mais diretamente ao simples "servios web estilo RPC. Interfaces simples so muitas vezes utilizados para expor a capacidade de "raw" de sistemas existentes ou para definir alguns servios que no possuam protocolos. Os casos degenerados do ServiceInterface e do ServiceContract, onde o servio unidirecional, o

consumidor chama operaes no fornecedor e o fornecedor no retorna a chamada do consumidor, no podendo mesmo saber se o consumidor est disponvel. ServiceInterface - Uma abordagem baseada em ServiceInterface permite servios bidirecionais, onde h "callbacks" do fornecedor para o consumidor como parte de uma conversa entre as partes. Uma interface de servio definida em termos pelo prestador do servio que especifica como a interface do fornecedor ser oferecida, bem como a interface, quando houver, esperada por parte do consumidor. A interface do servio tambm pode especificar a coreografia do servio, onde as informaes sero enviadas entre o fornecedor e o consumidor e em que ordem. A ServiceInterface um tipo de porta "servio" em um provedor e um tipo de porta "Request" para o consumidor. Em resumo, o

consumidor se compromete a utilizar o servio, conforme definido pela sua interface de servio, e o fornecedor se compromete a fornecer o servio de acordo com a sua interface de servio. A compatibilidade de interfaces de servio determina se estes acordos so consistentes e podem, portanto, serem ligados. A abordagem ServiceInterface mais aplicvel onde as capacidades existentes esto diretamente expostas como servios e ento usado de vrias maneiras, ou em situaes que envolvam uma ou duas partes no protocolo de atendimento. ServiceContract - Uma abordagem baseada em contrato de servio define as especificaes de servio (o contrato de servios) que detalham como prestadores de servios, consumidores e outros papis trabalharam juntos para realizar as trocas de valor, onde a troca de valor a promulgao do servio. A abordagem do contrato de servio define os papis de cada participante desempenha (como provedor e consumidor) e as interfaces que implementam o desempenho dos papeis nesse servio. Estas interfaces so os tipos de portas do participante, o que o obriga a ser capaz de desempenhar esse papel em que o contrato de servio. O contrato de servio representa um acordo entre as partes para a forma como o servio ser prestado e consumido. Este acordo inclui as interfaces, coreografia, e quaisquer outros termos e condies. O acordo pode ser afirmado com antecedncia ou dinamicamente, contanto que um acordo existe no momento em que o servio entra em vigor. Se um provedor e consumidor possuir diferentes contratos de servios, deve haver um acordo ou determinao de que seus contratos de servio mesmo diferentes so compatveis e coerentes com outros compromissos dos mesmos participantes. Os contratos de servios so frequentemente parte de uma ou mais arquiteturas de servio, definidos como um conjunto de participantes que fornecem e utilizam os servios para um determinado proposito de negcio ou processo. Em resumo, a abordagem do contrato de servio baseado na definio do contrato de servio "no meio" (entre as partes) e com as extremidades (os participantes), que concordam com as suas partes no contrato, ou se adaptam a ele. A abordagem ServiceContract mais aplicvel quando uma empresa define os servios construdos ou adaptados para operar dentro da arquitetura acordada, ou quando h mais de duas partes envolvidas no servio.

A diferena fundamental na abordagem baseada em contratos de interface que na interao entre os participantes definida separadamente dos participantes de um ServiceContract que define as obrigaes e solicitaes de todos, individualmente ou em servio.

1.4. Desenvolvimento para SOA A SoaML pode ser usada para servios bsicos de contextos independentes, concentrando-se na especificao de um nico servio sem levar em conta o seu contexto ou dependncias. Podendo-se tambm ser usado "na grande" onde estamos permitindo que uma organizao possa trabalhar de forma mais eficaz atravs de um conjunto inter-relacionado de servios. Tais servios so executados no contexto deste empreendimento, processo ou da comunidade e por isso dependem de acordos capturados na arquitetura de servios da comunidade. A ServicesArchitecture SoaML mostra como vrios participantes trabalham em conjunto, fornecendo e utilizando servios para permitir que os objetivos ou processos de negcios sejam atendidos. Os servios de tecnologia podem ser identificados, especificados,

implementados e eventualmente executados em alguns ambiente . H uma variedade de abordagens para a identificao de servios que so suportados pelo SoaML. Estas diferentes abordagens so destinadas a apoiar a variabilidade observada no mercado, permitindo a identificao de alguns os servios: projetos de arquiteturas de servios que especificam uma comunidade de participantes interagindo, e os contratos de servios que refletem os acordos para a forma de como pretendem interagir para alcanar algum objetivo comum. Organizar as funes individuais em capacidades dispostas em uma hierarquia, mostrando as dependncias de uso esperadas e usando esses recursos para identificar as interfaces de servios que os expem por meio dos servios. Usando um processo de negcio para identificar os recursos funcionais necessrias para realizar algum propsito, bem como os papis desempenhados pelos participantes. Processos e servios so pontos de vista diferentes do mesmo sistema - um com foco em como e por que as partes interagem entre si e outro com foco em atividades que executam partes para fornecer e utilizar esses servios.

 Identificar os servios de ativos existentes que podem ser utilizados pelos participantes para adaptar esses recursos e retorna-los como servios. Identificar dados comuns e fluxos de dados entre as partes e agrupando-as em servios. Independentemente da forma como os servios so identificados, eles so formalizados por meio de descries de servios. Como alternativa, o acordo entre a solicitao do consumidor e prestador de servios podem ser capturadas em um contrato de servio comum, definida em um s lugar, restringindo tanto interface de servio do consumidor e interface de servio do provedor. Os servios so prestados pelos participantes que so responsveis pela execuo dos servios e, possivelmente usando outros servios. Implementaes de servios podem ser especificado por meio de mtodos que so os comportamentos dos participantes expressas utilizando interaes, atividades, mquinas de estado ou comportamentos opacos. Os participantes tambm podem delegar implementaes de servio para as peas de sua estrutura interna, que representam um conjunto de outros participantes de servio ligados em conjunto para proporcionar uma soluo completa.

Os servios podem ser realizados por implementaes de participantes que podem ser executados em algum ambiente de execuo manual ou automatizado. SoaML se baseia em tcnicas MDA OMG que separa a implementao lgica de um servio a partir de suas possveis realizaes fsicas em vrias plataformas. Esta separao de preocupaes tanto mantm os modelos de servios mais simples e mais resistentes a mudanas de plataforma subjacente e a ambientes de execuo. Usando MDA os modelos de arquiteturas SoaML podem suportar uma variedade de implementaes de tecnologia e suporte das ferramentas ajudando a automatizar estes mapeamentos de tecnologia. 1.5. Conceitos fundamentais de servios bsicos Um conceito fundamental o de servios. Servio definido como a entrega de valor para outro partido, ativado por uma ou mais capacidades. Aqui, o acesso ao servio prestado atravs de um contrato prescrito e exercida de acordo com as restries e polticas, conforme especificado pelo contrato de servio. O servio fornecido por um participante que atua como o provedor do

servio para uso por outros. Os eventuais consumidores do servio no podem ser conhecidos ao prestador do servio e pode demonstrar a utilizao do servio para alm do mbito originalmente concebido pelo provedor. [OASIS RM] Como mencionado anteriormente, o provedor e o consumidor podem ser pessoas, organizaes, componentes de tecnologia ou sistemas - ns chamamos estes de participantes. Os participantes oferecem servios atravs de portas que podem utilizar o esteretipo de "Servio" e solicitar servios de Portas como o "Request". Estas portas representam caractersticas dos participantes, onde o servio oferecido ou consumido. A figura abaixo (Figura 1) mostra um "Productions" participante da prestao de um servio "agendamento". O tipo de porta de servio a interface UML "Agendamento", que tem duas operaes, "requestProductionScheduling" e "sendShippingSchedule." A interface define como um consumidor de um servio de agendamento deve interagir enquanto a porta de servio especifica que participante "Productions" tem o recurso para oferecer o servio, o que poderia, por exemplo, ser descrita em um repositrio UDDI. Percebese que um participante pode tambm oferecer outros servios em outras portas de servio. O participante "Productions" tem dois comportamentos que so os mtodos das operaes previstas atravs do servio de agendamento.

Figura 1 - Servios e participantes do servio 2. Uso da interface simples para definir os participantes Interfaces simples definem os servios de uma maneira que no necessitam de um protocolo. Esses servios podem ser definidos com apenas

uma nica interface UML e depois fornecido em uma porta "Servio" e consumido em uma porta "Request".

Figura 2 - Interface Simples

A interface acima define totalmente o servio, tornando-o apto a seu usado inclusive no ServiceInterface ou ServiceContract - mas isso no

obrigatrio. A interface UML pode ser usado como o tipo de porta de Servio e porta de Pedido.

Figure 3 - Uso de interface simples

O diagrama acima mostra o uso de "Estado de Embarque", como um tipo de porta de servio e de Pedido, que quando so utilizados na porta de Servio da interface liberado e quando so utilizados na porta de Pedido o servio utilizado e as portas resultantes so compatveis. 2.1. Interface baseada em SOA A ServiceInterface uma classe UML e define funes especficas a cada participante desempenha na interao de servio, onde cada papel tm um nome e um tipo de interface. A interface do fornecedor (o qual deve ser o tipo de uma das partes da classe) realizado (fornecido) pela classe ServiceInterface. A interface do consumidor (se houver), deve ser usada pela classe. Este exemplo demonstra como pode ser montada uma interface de servio.

Figura 4 Definio de interface de servio

Analisando cada parte individualmente: ServiceInterface Lugar da Ordem de Servio - Esta a raiz da interface de servio e representa o servio em si, contedo os termos, as condies em que o servio pode ser promulgadas e os resultados do servio. A interface do servio pode estar relacionada com os objetivos de negcio ou requisitos. A interface de servio tambm pode ser utilizada em arquiteturas de servios para mostrar como vrios servios e como os participantes trabalham em conjunto para alcanar os objetivos de negcio ou requisitos. Esta interface de servio definida a partir da perspectiva do prestador do servio - o tomador de ordem. Fornecedor: Order Taker - isto define o papel do provedor de servio de ordem (interface que um provedor vai exigir uma porta para prestar este servio). O provedor o participante que oferece algo de valor para o consumidor. Consumidor: Order Placer - este o papel do consumidor de servio de ordem . O consumidor o participante que tem alguma necessidade e solicita um servio de um provedor. Esta a interface que um consumidor ir implementar em uma porta para consumir esse servio (no caso de um servio unidirecional, pode no haver uma relao de consumo).

2.2. Especificando a coreografia

Figura 5 - Lugar coreografia ordem

A coreografia de servio acima um comportamento da propriedade da interface de servio e define as interaes necessrias e opcionais entre o prestador e o consumidor. H dois conjuntos de interaes primrias - O pedido de citao, resultando em uma citao e da ordem, resultando em uma confirmao do pedido. Neste caso, essas interaes podem ser definidas atravs de sinais, o que torna esta interface de servio assncrona e o documento orientado.

2.3. O uso da interface de servio para definir participantes

Os participantes definem os tipos de organizaes, funes organizacionais, ou componentes pelos papis que desempenham em arquiteturas de servios e os servios que prestam e usam. Por exemplo, na Figura 6, a figura da direita, ilustra um participante fabricante que oferece um servio comprador. Participantes fornecem recursos atravs de portas de servio geridas pelo ServiceInterfaces ou em casos simples, UML interfaces que define os seus recursos fornecidos ou oferecidos. O servio utiliza o conceito de UML de uma porta e indica o ponto de funo ou interao atravs do qual um classificador interage com outros classificadores (ver Figura 6). Uma porta digitada por um ServiceInterface e designada com o Servio conhecida como uma porta de servio. A porta de servio a caracterstica que representa o ponto de interao em um participante na qual um servio efectivamente prestado. Em outras palavras, a porta de servio o ponto de interao para envolver os participantes em um servio via suas interfaces de servio. Assim como queremos definir os servios prestados por um participante usando uma porta de servio, queremos definir quais os servios que um participante precisa ou consome. Quando um participante expressa suas necessidades, fazendo um pedido para os servios de algum outro participante, sua solicitao definida usando uma porta estereotipada como uma porta pedido. O ServiceInterface usado para gerar portas de Servio e de Pedido dos participantes. O prestador do servio usa uma porta servio e o consumidor do servio usa uma porta pedido. As portas de Servio e Pedido so os pontos de interao para o servio.

Vejamos alguns participantes:

Figura 6 - Participao nos servios

Nota-se que tanto o revendedor e o fabricante tem uma porta "Place Order Service", o fabricante o prestador do servio possuindo uma porta servio, e o revendedor um consumidor do servio possuindo a porta Request. Percebe-se tambm que a porta do fabricante fornece uma interface "Taker Ordem" e exige a interface "Placer Ordem".

2.4. Conceitos-chave da arquitetura de servios

Um dos principais benefcios do SOA a capacidade de permitir que uma comunidade, organizao ou conjunto de sistemas possam trabalhar em conjunto de forma mais coesa utilizando servios sem ficar excessivamente acoplado. Isso requer uma compreenso de como as pessoas, organizaes e sistemas trabalham em conjunto, ou colaboram para algum propsito. Ns permitimos esta colaborao, criando um modelo de arquitetura de servios. A arquitetura de servios coloca um conjunto de servios no contexto e mostra como os participantes trabalham juntos para apoiar a comunidade de objetivos. A ServicesArchitecture (ou SOA) uma rede de papis de participantes fornecendo e consumindo servios para cumprir um propsito. A arquitetura de servios define os requisitos para os tipos de participantes e realizaes de servios que cumprem essas funes. A arquitetura de servios tambm pode ter um processo de negcio para definir as tarefas e orquestrao de fornecer esse valor. A arquitetura de servios uma viso de alto nvel de como os servios

trabalham juntos para um propsito. Os mesmos servios e participantes podem ser utilizados em muitas arquiteturas, proporcionando reutilizao. A arquitetura de servios tem componentes em dois nveis de granularidade: A arquitetura de servios comunidade uma viso de "nvel superior" de como os participantes independentes trabalham coordenadamente. No assumindo ou exigindo qualquer entidade ou processo de controle, mas modelando com componentes como de colaborao estereotipados como
ServicesArchitecture.

Um participante pode tambm ter uma arquitetura que especifique subservios que trabalham juntos para fornecer os servios de o participante possui. A arquitetura de um participante mostrada como uma arquitetura de servios, realizada por uma classe UML ou componente e, frequentemente, tem um processo de negcio associado. Os participantes que realizam esta especificao devem aderir arquitetura especifica. A ServicesArchitecture (veja a Figura 7) definido usando uma colaborao UML.

Figura 7 - Exemplo de arquitetura de servios da comunidade com funes e servios participantes.

A arquitectura de servios serve para definir as caractersticas de cada um dos participantes, seus papis, como so preenchidos pelos participantes, quais portas de servio so exigidas nas entidades que preenchem esses papis e, em seguida, esto vinculados s arquiteturas de servios em que participam. Podemos utilizar a ServicesArchitecture para especificar a arquitetura dentro de um participante (onde existe um conceito de "gesto" existe uma

arquitetura de servios ) mostrando como perceber os participantes e colaboradores externos atuaes e o acompanhamento do processo de negcio. A ServicesArchitecture ou classe especificao pode ser composto a partir de outras arquiteturas de servios e contratos de servios.

Figura 8 - Exemplo de arquitetura de servios para um participante

A Figura 8 ilustra a arquitetura de servios para um determinado participante " Manufacturer", indicando que esta arquitetura consiste de uma srie de outros participantes interagindo atravs de contratos de servios. A arquitetura de servios participante Fabricao incluiria um processo de negcio que especifica como estes participantes interagem a fim de proporcionar um servio de compra. Esta arquitetura de servios a arquitetura para um fabricante especfico, compreendendo as exigncias do fabricante em geral. Nota-se que os papis "de fora" do fabricante so indicados pelos papis com linhas tracejadas (:Dealer and :Shipper) sendo "agregao compartilhada" em UML. Um componente pode ento realizar e/ou utilizar esta arquitetura de servios. O efeito lquido que as arquiteturas de servios podem ser usadas para especificar como o trabalho do conjunto de sistemas (todo o caminho), no prendendo-se a componentes de tecnologia.

2.5. Contratos de servio e contrato com base SOA

Uma parte fundamental de um servio o ServiceContract ( Figura 9).

Figura 9 - Exemplo ServiceContract

A ServiceContract contem os termos, condies, interfaces e coreografias que interagem com os participantes (direta ou indiretamente) . Definindo a especificao completa de um servio que inclui todas as informaes, e quaisquer outros termos e condies do servio. Ela vinculativa para os provedores e consumidores desse servio ,ou a todos os participantes no caso de um servio multipartidrio. A base do contrato de servio tambm uma colaborao UML que est focada nas interaes envolvidas no fornecimento do servio. Um participante joga um papel no mbito maior de uma ServicesArchitecture e tambm desempenha um papel como o fornecedor de servios ou do utilizador especificados por ServiceContracts. A coreografia uma especificao do que transmitido, e quando ela transmitida entre as partes para aprovar um servio de troca. A coreografia especifica o intercmbio entre as partes - os dados, ativos e obrigaes que vo entre elas. Definindo o que acontece entre o fornecedor e os participantes de consumo, sem definir os seus processos internos - seus processos internos tm que ser compatveis com suas ServiceContracts. Uma coreografia

ServiceContract um comportamento UML, tal como pode ser mostrado no diagrama de interao ou no diagrama de atividades que de propriedade da ServiceContract (Figura 10).

Figura 10 - Exemplo de coreografia

O ServiceInterface especifica as interfaces fornecidas que definem todas as operaes ou recepes de sinais necessrios para os tipos de papel desempenhados - estes contero cada obrigao, ativo, ou parte dos dados que a entidade pode enviar ou receber como parte do contrato de servio. Fornecendo o uso de interfaces UML correspondentes, desta forma montando a "liga dos pontos" entre o contrato de servio e os requisitos para qualquer participante a desempenhar um papel no servio de provedor ou consumidor. Um dos recursos importantes de SOA que ele pode trabalhar "na grande", onde entidades independentes esto interagindo atravs da Internet para os departamentos e processos internos. Isto sugere que existe um caminho para decompor um ServicesArchitecture e visualizar como os servios podem ser implementados usando ainda outros servios. Um participante podem ainda ser descritos pela sua arquitetura interna de servios ou por um componente composto. Tal participante tambm pode usar os servios internos ou externos, montar outros participantes, processos de negcios e outras formas de implementao. SoaML mostra como a estrutura interna de um participante descrita usando outros servios. Isto feito atravs da definio de um ServicesArchitecture para participantes de uma arquitetura de servios mais granular (escala maior), como mostrado na Figura 7 e a Figura 8.
A especificao de um SOA quando apresentado como um modelo UML esses modelos so geralmente considerado esttico, no entanto, qualquer das construes SoaML poderia muito bem ser construdo dinamicamente em resposta s mudanas nas condies. A semntica de SoaML so independentes do tempo de

design, ou a tomada de tempo de execuo. Por exemplo, um ServiceContract novo ou especializado poderia ser negociado em tempo real e imediatamente utilizados entre os participantes especficos. A capacidade de infra-estrutura tecnolgica para suportar tal comportamento dinmico apenas emergente, mas SoaML pode apoi-lo em seu cresciento.

2.6. Exemplo de Contrato com base SOA Um contrato de servio representada como uma colaborao UML e define funes especficas a cada participante jogando no contrato de servio. Esses papis tm um nome, um tipo de interface que pode ser estereotipado como o "provedor" ou "Consumidor." O consumidor est prevista para iniciar o servio, chamando o provedor para fornecer algo de valor para o consumidor.

Figura 11 Coreografia - Ordem de Servio Contrato

A figura acima ilistra a coreografia de um contrato de servio, neste h dois conjuntos de interao principais: 1) a solicitao de cotao, resultando em uma citao, e 2) a ordem, resultando em uma confirmao do pedido. Neste caso, essas interaes podem ser definidas atravs de sinais, o que torna este servio contrato assncrono e documento orientado, um mainstream melhores prticas SOA.

Vamos dar uma olhada em algumas das partes deste contrato de servio.

Figura 12 Interface de Colaborao Contrato de servio

O diagrama de interao na Figura 12 parte da ordem colaborao contrato de servio. Esta colaborao liga as partes do contrato de servio. As peas incluem o diagrama de interao, descrevendo as funes do servio, e as interfaces que definem as operaes e recepes de sinal, podendo ser recebido pelos participantes de cada funo.

2.7. Exemplos graficos de uso de contratos de servio

Figura 13 - Participao nos servios

Figura 14 - Uso de Solicitao - "Service" e "Request"

Figura 15 - coreografia Multi-partido

Figura 16 - Contrato de prestao de servios multi-partidria e as interfaces

2.8. Recursos
ServiceArchitectures e servicecontracts fornecer uma maneira formal de identificar os papis desempenhados pelas partes ou pelos participantes, suas responsabilidades, e como eles tm a inteno de interagir, a fim de atender os objetivo usando servios. Isto muito til em alguma "necessidade" ou contexto de montagem. No entanto, quando re-arquitetamos aplicativos existentes para servios ou construmos a partir do zero, mesmo os participantes abstratos ainda no pode ser conhecido. Nestas situaes til tambm para expressar uma arquitetura de servios em termos das capacidades lgicas dos servios, mesmo que os consumidores do servio no devam se preocupar com a forma como um servio implementado, importante ser capaz de especificar o comportamento de um servio ou recurso que vai realizar ou implementar um ServiceInterface. Isso feito dentro de SoaML.

Figura 19 - Capacidades de servio para o processamento de pedidos de compra

Conforme a figura acima, alm de especificar as habilidades dos participantes, de um ou mais recursos, podemos utilizar para especificar o comportamento e a estrutura necessria para suportar a ServiceInterface. A Figura 6.20 mostra a capacidade do transporte realizar o ServiceInterface Shipping. Assim, a Capability permite a especificao de um servio sem levar em conta como esse servio pode ser implementado e, posteriormente, oferecido aos consumidores por um participante. Ele permite que os arquitetos analisem a forma de como os servios esto relacionados e como eles podem ser combinados para formar uma capacidade maior antes da alocao de cada participante.

Figura 20 - ServiceInterface realizado por um Recurso

Recursos podem ser realizados com um participante, quando o prprio Recurso realiza uma ServiceInterface, que ser normalmente do tipo de um servio do Participante. Como mostra a Figura 6.21.

Figura 21 - O participante Shipper percebe a Recurso do transporte

Recursos tambm podem ser usados para especificar as partes dos participantes, os recursos que realmente prestam aos seus servios. A figura abaixo (Figura 22) mostra o Participante Productions com duas partes digitadas pelo Capabilities. O Servio productionoffice delegando pedidos para a parte programador que digitado pela capacidade de programao. Isso normalmente indicam que a capacidade de programao percebe o ServiceInterface SchedulingService.

Figura 6.22 - Productions Participante com duas partes especificadas pelo Capabilities

ServiceInterfaces tambm pode expor Capabilities. Isso feito dentro de SoaML com a dependncia Expose. A Figura 23 apresenta um exemplo de uma tal situao.

Figura 23 - ServiceInterface expondo as vendas e capacidade de marketing

Cada recurso pode possuir comportamentos que so mtodos de suas operaes previstas. Estes mtodos seriam usados para especificar como os recursos poderiam ser implementados, e para identificar outros recursos necessrios. Alternativamente, ServiceInterfaces pode simplesmente expor recursos de um participante.

2.9. O Perfil SoaML de UML

Os esteretipos, a seguir, definem como utilizar SoaML em UML com base no conjunto de esteretipos definidos no perfil SoaML.

Figura 24 - Integrao BMM

Figura 25 Contratos

Figura 26 Servios

Figura 27 - Dados de Servios

Figura 28 Milestones

Figura 29 Capacidades

2.10.

Descries esteretipo

2.10.1.

Agente Um agente uma classificao de entidades autnomas que podem

adaptar-se e interagir com o ambiente. Ele descreve um conjunto de instncias de agentes que tm caractersticas, restries e semntica em comum. Agentes em SoaML tambm so participantes, fornecendo ou utilizando servios.

Descrio Em geral, os agentes podem ser agentes de software, agentes de hardware, firmware agentes, agentes robticos, agentes humanos, e assim por diante. Estas propriedades so principalmente cobertas por um conjunto de aspectos centrais, cada um focando em diferentes pontos de vista de um sistema de agentes. Mesmo que estes aspectos no aparecem diretamente no metamodelo SoaML, podemos associa-los com conceitos SoaML relacionados. Cada aspecto de um agente pode ser expresso como uma arquitectura de servios.

Dependendo do ponto de vista de um sistema de agentes, vrios aspectos so importantes. Mesmo que estes aspectos no aparecem diretamente no metamodelo SoaML, podemos relacion-las com conceitos de SoaML relacionados (aspecto Agent, aspecto de colaborao, Papel aspecto, aspecto de Interao, aspecto comportamental, Organizao / Grupo aspecto). O propsito de um agente especificar uma classificao de entidades autnomas (instncias do agente) que podem se adaptar e interagir com seu meio ambiente, e para especificar as caractersticas, limitaes e semnticas que caracterizam os casos de agentes.

Restries

O isActive propriedade deve ser sempre verdadeira.

Notao

Um agente pode ser designado usando o componente ou a notao de Classe / Classificador incluindo o Agente palavra-chave ou o cone de decorao Agent no compartimento o nome do classificador.

Figura 6.30 notao do agente

Adies ao UML2

Agente um novo esteretipo em SoaML estendendo UML2, um componente com novas capacidades.

2.10.2.

Anexo Uma parte de uma mensagem que est ligada ao invs de contida na

mensagem.

Estende Metaclass Property

Descrio Um anexo denota algum componente de uma mensagem que um anexo a ela (ao contrrio de uma parte direta da prpria mensagem). Em geral, este no susceptvel de ser usado em atividades de design de nvel superior, mas para muitos processos de dados importante diferenciar a partir dos dados de mensagens embutidas. Por exemplo, um servio de catlogo pode retornar detalhes gerais do produto como uma parte da mensagem, mas as imagens estruturadas como anexos de mensagem. O que tambm permite denotar que a codificao das imagens feita de forma binria (por oposio codificao da mensagem principal). Os anexos podem ser usados para indicar a parte de dados de servio que podem ser acedidos separadamente, reduzindo os dados enviados entre os consumidores e fornecedores, a menos que seja necessrio.

Atributos codificao: String [0 .. 1] denota o mecanismo de codificao plataforma usar para gerar o esquema para a mensagem; exemplos podem ser SOAP RPC, DocLiteral, ASN.1, etc mimeType: String [0 .. 1] Indica a iana MIME tipo de mdia para a fixao

Notation Anexos usam a notao usual UML2 para DataType com a adio de um "Anexo" esteretipo.

Examples A Figura 31 mostra um anexo InvoiceContent ao MessageType fatura. Este anexo contm informaes detalhadas sobre a fatura.

Figure 31 - InvoiceContent

Adies ao UML2 Estende UML2 para distinguir anexos de mensagens de outras propriedades da mensagem.

2.10.3. Recurso Um Recurso a capacidade de agir e produzir um meio que consegue um resultado. Pode-se especificar uma capacidade geral de um participante, bem como a capacidade especfica para fornecer um servio.

Extends Metaclass Class

Descrio

Um recurso a capacidade de agir e produzir um resultado que atinge outro resultado. Esse elemento permite a especificao de recursos e servios, sem levar em conta como um determinado servio pode ser implementado e posteriormente oferecido aos consumidores por um participante. Ele permite que arquitetos analisem como os servios so relacionados e como eles podem ser combinados para formar alguma capacidade maior antes da alocao de um determinado participante. .

Notao Um Recurso indicado o uso de uma classe ou componente com a Recurso chave ou Recurso cone decoration:.

Exemplos A Figura 19 mostra os recursos que foram identificados como necessrios para o processamento de ordens de compra. Ver tambm a Figura 23. Adies ao UML2 Recurso um novo esteretipo usado para descrever a capacidade de servio.

2.10.4.

Consumidor Modelos de consumo do tipo de um consumidor de servio. O

consumidor usado como o tipo de papel num contrato de servio e identifica o tipo de porta de um participante.

Extends Metaclass Interface (no caso de um contrato de servio no composto) Class (no caso de um contrato de servio composto)

Descrio Um modelo Consumidor de interface fornecida pelo consumidor de um servio recebe os resultados da interao do servio. O consumidor ser normalmente aquele que inicia a interao de servio. Interfaces de

consumo so usados como um tipo de ServiceContract e est sujeito aos termos e condies do contrato de servio.

Restrio

O Consumidor obrigado pelas restries a ter comportamento do tipo ServiceContract.

Notao Um Consumidor indicado para usar uma classe ou interface com o Consumidor esteretipo.

Examples

O diagrama acima mostra uma interface consumidor usando o papel de consumidor no contrato de servio. Esta interface do consumidor do tipo de porta de um participante que consome este servio.

O diagrama acima mostra o tipo de porta de um participante, onde o servio consumido.

2.10.5.

Colaborao A Colaborao estendida para indicar se o papel de ligaes parte de

CollaborationUses, onde rigorosamente inserids por uma colaborao aplicada ou no.

Extends Metaclass Collaboration

Descrio

Um colaborao, ServiceContract, ou ServicesArchitecture representa um padro de interao entre os papis. Essa interao pode ser informal e vagamente definida como um esboo exigncias. Ou pode representar acordos formais ou exigncias que devem ser cumpridas fielmente. A propriedade isstrict de colaborao estabelece o valor padro de isstrict para qualquer CollaborationUse inserido pela Colaborao. Como o ServiceContract vinculativo para o ServiceInterfaces nomeado em contrato, a CollaborationUse no necessria se os tipos so compatveis.

Atributos isStrict: Boolean = true Indica se esta colaborao a inteno de representar um padro rigoroso de interao. Estabelece o valor padro para qualquer CollaborationUse digitada por esta colaborao.

2.10.1.

CollaborationUse

CollaborationUse estendido para indicar se o papel para ligaes de peas so rigorosamente aplicadas ou soltas.

Estende Metaclass CollaborationUse

Descrio

A CollaborationUse uma declarao sobre a capacidade de um classificador capaz de fornecer ou utilizar recursos, e se comporta de uma maneira consistente com o que expressa em seu tipo de Colaborao. uma afirmao sobre a

estrutura e o comportamento do classificador. Contm a adequao de suas partes para desempenhar papis de uma finalidade especfica.

Atributos isstrict: Boolean Indica se este cumprimento especial se destina a ser rigoroso.

Semntica - pontos de variao Conformidade entre tipos nomeados - Colaborao na utilizao de papeis em um ponto de variao semntica, que ser determinada por modeladores ou ferramentas.

Examples A Figura 32 apresenta uma ServiceInterface ShippingService que preenche a colaborao ShippingContract. O ShippingService contm uma

CollaborationUse que vincula as partes que representam, os consumidores e fornecedores da ServiceInterface aos papis que desempenham na colaborao ServiceContract. A parte do transporte est vinculado ao papel do transporte e da parte ordenador est vinculado ao papel ordenador. Estas peas devem ser compatveis com as funes que desempenham.

Figura 32 - Cumprindo a ServiceContract ShippingContract

A Figura 33 mostra um participante que rene e conecta uma srie de outros participantes, a fim de aderir ao fabricante Arquitetura

ServicesArchitecture. Neste caso, os papis do ServicesArchitecture so inseridos por qualquer ServiceInterfaces ou participantes da arquitetura especifica, a interao esperada entre os participantes, a fim de conseguir o resultado desejado.

Figura 6.33 - Cumprindo o Processo de Ordem de Compra Contrato

A parte OrderProcessor est vinculado ao papel orderHandler no ServicesArchitecture. Esta parte capaz de desempenhar o papel, porque tem as mesmas caractersticas que o papel na arquitectura. A parte Invoicer est vinculado ao papel Invoicer do ServicesArchitecture. Esta parte capaz de desempenhar este papel, pois fornece um servio cuja ServiceInterface o mesmo que o tipo de papel no ServicesArchitecture. Os papis de agendamento e transporte so semelhantes. Adies ao UML2 CollaborationUse estende UML2 CollaborationUse para incluir o isstrict propriedade.

References
http://eprints.ecs.soton.ac.uk/825/05/html/chap3.htm, http://en.wikipedia.org/wiki/ http://www.sce.carleton.ca/netmanage/docs/AgentsOverview/ao.html. http://www.iana.org/assignments/media-types/.
ttp://www.omg.org/spec/SoaML/20120501
http://www.omg.org/spec/SoaML/20120501/SoaMLMetamodel.xmi http://www.omg.org/spec/SoaML/20120501/SoaMLProfile.xmi

http://www.ibm.com/developerworks/br/rational/library/09/modelingwithsoamlhttp://translate.google.com.br/#en/pt/ (brincadeira)