Modelagem através de SOAMLOq acha do titulo?

Claudia Goetz, Henrique Zmuda da Silva

Instituto de Informática – 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 (Service-Oriented 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 através de comentários e exemplos a utilização de SoaML (Service-Oriented Architecture Modeling Language) com é um padrão OMG que tem como objetivo trazer esclarecimento do conteúdo e ajudar na percepção do potencial do SOA. SoaML é um pequeno conjunto de extensões UML que oferecem suporte à modelagem SOA, assim como uma abstração de SOA enfatizando a descrição das necessidades e recursos dos participantes e ligando-os nas cadeias de valor do serviço.

1. Introdução á SoaML

1.1. SOA e SoaML

A Arquitetura Orientada a Serviço (SOA) é uma forma simples de

descrever e compreender as organizações, 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 operação de sistemas de TI

que são construídos utilizando esse estilo de arquitetura. Permitindo oferecer os

nossos recursos em troca de algum valor, estabelecendo assim, uma comunidade,

processo ou mercado, facilitando a integrações de aplicações existentes, bem

como na criação e integração de novas aplicações.

Para atingir seu potencial, uma infraestrutura de TI baseada em SOA

necessita ser relevante aos negócios, e portanto, dirigida pelo negócio e

implementada para oferecer suporte aos negócios. Isso é muito difícil de se

conseguir se os requisitos dos negócios forem uma simples lista de requisitos e o

nível de abstração do SOA for capturado em vários documentos XML que

representam uma coleção de serviços da Web. Então, SOA é utilizado para

modelar como as pessoas, organizações e sistemas fornecem e utilizam os

serviços para alcançar resultados.

SoaML fornece um modo padrão para soluções SOA usando o Unified

Modeling Language (UML). Utilizando por exemplo, os mecanismos de

extensão 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 avançada. A SoaML oferece vários benefícios:

Permite a escolha de plataformas flexíveis

Permite a interoperabilidade e integração no nível do modelo

Trata dos interesses da integração de negócios e interação de serviços no nível

da arquitetura utilizando a arquitetura como ponto entre requisitos de negócios e

soluções de TI automatizadas

Fornece um nível mais alto de abstração separado da variabilidade da plataforma

e da complexidade dos padrões dos documentos XML de serviços da Web de

nível inferior

Desacopla implementações de soluções de plataformas de arquitetura para

prevenir que as soluções existentes impeçam a evolução da plataforma

Habilita o SOA tanto nas plataformas existentes como entre elas, através de

model-driven architecture (MDA)

Alavanca e se integra a padrões OMG existentes para o desenvolvimento e

gerenciamento de ciclos de vida de ponta a ponta

1.2. Prestando suporte as perspectivas de negócios em SOA

A utilização de SOA com uma variedade de abordagens e tecnologias,

demostra uma opinião expressa de sua importância 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 negócios,

arquiteturas de missão da comunidade, ou arquiteturas de sistemas de tecnologia

da informação - tudo pode ser igualmente orientada a serviços. A abordagem

para a arquitetura SOA ajuda a separar as preocupações 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" são muito focados á tecnologia e

em lidar com os "bits e bytes" de computação distribuída. Estas preocupações de

tecnologia são importantes e se unem, mas não são o único foco de SOA como

expresso por SoaML. Essas tecnologias também podem ser suportados pela

SoaML através de perfis de tecnologia e vários "Modelos Dirigidos a

Arquitetura" métodos para a implementação de soluções baseadas em modelos

(como serviços web e CORBA).

SoaML explora a tecnologia como um meio para um fim, mas não se

limita a arquitetura de tecnologia. Na verdade, a maior alavancagem da

contratação de SOA vem do entendimento de uma comunidade, processo, ou da

empresa como um conjunto de serviços inter-relacionados e de apoio que a

empresa orientada a serviços tem com sistemas de serviços habilitados.

1.3. Abordagem baseada em interface para SOA

SoaML integra capacidades de modelagem e de apoio utilizando SOA

em diferentes níveis 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 sobrepõem aos elementos de perfil. Antes de

abordar as diferenças, vamos rever algumas das semelhanças e terminologia:

• Participantes - Os participantes são entidades ou tipos específicos de entidades

que fornecem ou usam os serviços. Os participantes podem representar pessoas,

organizações ou componentes de sistemas de informação. Os participantes

podem fornecer qualquer número de serviços e consumir qualquer número de

serviços.

• Portas - participantes fornecem ou consomem serviços através de portas. A

porta é a parte ou característica de um participante que é o ponto de interação

para um serviço - onde é fornecido ou consumido. A porta é onde um serviço é

oferecido podendo ser designado como uma porta "Serviço", e onde um serviço

é consumido pode ser designado como uma porta "Request".

• Descrição do serviço - a descrição de como o participante interage para

fornecer ou utilizar um serviço é encapsulado em uma especificação para o

serviço - existem três maneiras de especificar uma interação de serviço - uma

interface UML, um ServiceInterface e um ServiceContract. Estas formas

diferentes para especificar um serviço relacionam com a abordagem SOA e a

complexidade do serviço, mas em cada caso, resultar em interfaces e

comportamentos que definem a forma como o participante irá fornecer ou

utilizar um serviço através de portas. As descrições de serviços são

independentes, mas consistente de como o provedor fornece o serviço ou como

(ou porque) o consumidor consome. Esta separação de interesses entre a

descrição do serviço, e como ele é implementado é fundamental para SOA. A

especificação do serviço especifica a forma de como os consumidores e os

prestadores devem interagir através de seus portos para decretar um serviço, mas

não como eles fazem isso.

• Recursos - os participantes que fornecem um serviço devem ter a capacidade

de fornece-lo, mas diferentes fornecedores podem ter diferentes recursos para

prestar o mesmo serviço – podendo alguns até "terceirizar" ou delegar a

execução do serviço por meio de um pedido de serviço a outros. Os recursos de

trás do serviço irão fornecer o serviço de acordo com a sua descrição e também

podendo ter dependências em outros serviços para fornecer essa capacidade. Os

recursos de serviço são muitas vezes parte integrante do processo de negócio do

provedor, podendo ser visto a partir de duas perspectivas: as capacidades de um

participante que podem ser exploradas para a prestação de serviços, bem como

os recursos necessários para a empresa que podem ser utilizados para identificar

candidatos de serviços.

Estas abordagens para especificar um serviço podem ser resumidas como:

• Interfaces simples - a interface simples chama a atenção para a interação one-

way fornecido por um participante em uma porta representado como uma

interface UML. O participante recebe operações nesta porta e pode fornecer

resultados para o chamador. Este tipo de interface de um modo pode ser usado

com chamadas "anônimas" e o participante não faz suposições sobre o chamador

ou a coreografia do serviço. O serviço one-way corresponde mais diretamente ao

simples "serviços web estilo RPC”. Interfaces simples são muitas vezes

utilizados para expor a capacidade de "raw" de sistemas existentes ou para

definir alguns serviços que não possuam protocolos. Os casos degenerados do

ServiceInterface e do ServiceContract, onde o serviço é unidirecional, o

consumidor chama operações no fornecedor e o fornecedor não retorna a

chamada do consumidor, não podendo mesmo saber se o consumidor está

disponível.

• ServiceInterface - Uma abordagem baseada em ServiceInterface permite

serviços bidirecionais, onde há "callbacks" do fornecedor para o consumidor

como parte de uma conversa entre as partes. Uma interface de serviço é definida

em termos pelo prestador do serviço que especifica como a interface do

fornecedor será oferecida, bem como a interface, quando houver, esperada por

parte do consumidor. A interface do serviço também pode especificar a

coreografia do serviço, onde as informações serão enviadas entre o fornecedor e

o consumidor e em que ordem. A ServiceInterface é um tipo de porta "serviço"

em um provedor e um tipo de porta "Request" para o consumidor. Em resumo, o

consumidor se compromete a utilizar o serviço, conforme definido pela sua

interface de serviço, e o fornecedor se compromete a fornecer o serviço de

acordo com a sua interface de serviço. A compatibilidade de interfaces de

serviço determina se estes acordos são consistentes e podem, portanto, serem

ligados. A abordagem ServiceInterface é mais aplicável onde as capacidades

existentes estão diretamente expostas como serviços e então usado de várias

maneiras, ou em situações que envolvam uma ou duas partes no protocolo de

atendimento.

• ServiceContract - Uma abordagem baseada em contrato de serviço define as

especificações de serviço (o contrato de serviços) que detalham como

prestadores de serviços, consumidores e outros papéis trabalharam juntos para

realizar as trocas de valor, onde a troca de valor é a promulgação do serviço. A

abordagem do contrato de serviço define os papéis de cada participante

desempenha (como provedor e consumidor) e as interfaces que implementam o

desempenho dos papeis nesse serviço. Estas interfaces são os tipos de portas do

participante, o que o obriga a ser capaz de desempenhar esse papel em que o

contrato de serviço. O contrato de serviço representa um acordo entre as partes

para a forma como o serviço será prestado e consumido. Este acordo inclui as

interfaces, coreografia, e quaisquer outros termos e condições. O acordo pode

ser afirmado com antecedência ou dinamicamente, contanto que um acordo

existe no momento em que o serviço entra em vigor. Se um provedor e

consumidor possuir diferentes contratos de serviços, deve haver um acordo ou

determinação de que seus contratos de serviço mesmo diferentes são

compatíveis e coerentes com outros compromissos dos mesmos participantes. Os

contratos de serviços são frequentemente parte de uma ou mais arquiteturas de

serviço, definidos como um conjunto de participantes que fornecem e utilizam

os serviços para um determinado proposito de negócio ou processo. Em resumo,

a abordagem do contrato de serviço é baseado na definição do contrato de

serviço "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 aplicável quando uma empresa define os serviços

construídos ou adaptados para operar dentro da arquitetura acordada, ou quando

há mais de duas partes envolvidas no serviço.

A diferença fundamental na abordagem baseada em contratos de

interface é que na interação entre os participantes é definida separadamente dos

participantes de um ServiceContract que define as obrigações e solicitações de

todos, individualmente ou em serviço.

1.4. Desenvolvimento para SOA

A SoaML pode ser usada para serviços básicos de contextos

independentes, concentrando-se na especificação de um único serviço sem levar

em conta o seu contexto ou dependências. Podendo-se também ser usado "na

grande" onde estamos permitindo que uma organização possa trabalhar de forma

mais eficaz através de um conjunto inter-relacionado de serviços. Tais serviços

são executados no contexto deste empreendimento, processo ou da comunidade

e por isso dependem de acordos capturados na arquitetura de serviços da

comunidade. A ServicesArchitecture SoaML mostra como vários participantes

trabalham em conjunto, fornecendo e utilizando serviços para permitir que os

objetivos ou processos de negócios sejam atendidos.

Os serviços de tecnologia podem ser identificados, especificados,

implementados e eventualmente executados em alguns ambiente . Há uma

variedade de abordagens para a identificação de serviços que são suportados

pelo SoaML. Estas diferentes abordagens são destinadas a apoiar a variabilidade

observada no mercado, permitindo a identificação de alguns os serviços:

• projetos de arquiteturas de serviços que especificam uma comunidade de

participantes interagindo, e os contratos de serviços que refletem os acordos para

a forma de como pretendem interagir para alcançar algum objetivo comum.

• Organizar as funções individuais em capacidades dispostas em uma hierarquia,

mostrando as dependências de uso esperadas e usando esses recursos para

identificar as interfaces de serviços que os expõem por meio dos serviços.

• Usando um processo de negócio para identificar os recursos funcionais

necessárias para realizar algum propósito, bem como os papéis desempenhados

pelos participantes. Processos e serviços são 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

serviços.

• Identificar os serviços de ativos existentes que podem ser utilizados pelos

participantes para adaptar esses recursos e retorna-los como serviços.

• Identificar dados comuns e fluxos de dados entre as partes e agrupando-as em

serviços.

Independentemente da forma como os serviços são identificados, eles são

formalizados por meio de descrições de serviços. Como alternativa, o acordo

entre a solicitação do consumidor e prestador de serviços podem ser capturadas

em um contrato de serviço comum, definida em um só lugar, restringindo tanto

interface de serviço do consumidor e interface de serviço do provedor.

Os serviços são prestados pelos participantes que são responsáveis pela

execução dos serviços e, possivelmente usando outros serviços. Implementações

de serviços podem ser especificado por meio de métodos que são os

comportamentos dos participantes expressas utilizando interações, atividades,

máquinas de estado ou comportamentos opacos. Os participantes também podem

delegar implementações de serviço para as peças de sua estrutura interna, que

representam um conjunto de outros participantes de serviço ligados em conjunto

para proporcionar uma solução completa.

Os serviços podem ser realizados por implementações de participantes que

podem ser executados em algum ambiente de execução manual ou automatizado.

SoaML se baseia em técnicas MDA OMG que separa a implementação lógica de

um serviço a partir de suas possíveis realizações físicas em várias plataformas.

Esta separação de preocupações tanto mantém os modelos de serviços mais

simples e mais resistentes a mudanças de plataforma subjacente e a ambientes de

execução. Usando MDA os modelos de arquiteturas SoaML podem suportar

uma variedade de implementações de tecnologia e suporte das ferramentas

ajudando a automatizar estes mapeamentos de tecnologia.

1.5. Conceitos fundamentais de serviços básicos

Um conceito fundamental é o de serviços. Serviço é definido como a

entrega de valor para outro partido, ativado por uma ou mais capacidades. Aqui,

o acesso ao serviço é prestado através de um contrato prescrito e é exercida de

acordo com as restrições e políticas, conforme especificado pelo contrato de

serviço. O serviço é fornecido por um participante que atua como o provedor do

serviço para uso por outros. Os eventuais consumidores do serviço não podem

ser conhecidos ao prestador do serviço e pode demonstrar a utilização do serviço

para além do âmbito originalmente concebido pelo provedor. [OASIS RM]

Como mencionado anteriormente, o provedor e o consumidor podem ser

pessoas, organizações, componentes de tecnologia ou sistemas - nós chamamos

estes de participantes. Os participantes oferecem serviços através de portas que

podem utilizar o estereótipo de "Serviço" e solicitar serviços de Portas como o

"Request". Estas portas representam características dos participantes, onde o

serviço é oferecido ou consumido.

A figura abaixo (Figura 1) mostra um "Productions" participante da prestação de

um serviço "agendamento". O tipo de porta de serviço é a interface UML

"Agendamento", que tem duas operações, "requestProductionScheduling" e

"sendShippingSchedule." A interface define como um consumidor de um serviço

de agendamento deve interagir enquanto a porta de serviço especifica que

participante "Productions" tem o recurso para oferecer o serviço, o que poderia,

por exemplo, ser descrita em um repositório UDDI. Percebese que um

participante pode também oferecer outros serviços em outras portas de serviço.

O participante "Productions" tem dois comportamentos que são os métodos das

operações previstas através do serviço de agendamento.

Figura 1 - Serviços e participantes do serviço

2. Uso da interface simples para definir os participantes

Interfaces simples definem os serviços de uma maneira que não

necessitam de um protocolo. Esses serviços podem ser definidos com apenas

uma única interface UML e depois fornecido em uma porta "Serviço" e

consumido em uma porta "Request".

Figura 2 - Interface Simples

A interface acima define totalmente o serviço, tornando-o apto a seu

usado inclusive no ServiceInterface ou ServiceContract - mas isso não é

obrigatório. A interface UML pode ser usado como o tipo de porta de «Serviço»

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 «serviço» e de «Pedido», que quando são utilizados na porta de

«Serviço» da interface é liberado e quando são utilizados na porta de «Pedido» o

serviço é utilizado e as portas resultantes são compatíveis.

2.1. Interface baseada em SOA

A ServiceInterface é uma classe UML e define funções específicas a

cada participante desempenha na interação de serviço, onde cada papel têm 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 serviço.

Figura 4 – Definição de interface de serviço

Analisando cada parte individualmente:

• «ServiceInterface» Lugar da Ordem de Serviço - Esta é a raiz da interface de

serviço e representa o serviço em si, contedo os termos, as condições em que o

serviço pode ser promulgadas e os resultados do serviço. A interface do serviço

pode estar relacionada com os objetivos de negócio ou requisitos. A interface de

serviço também pode ser utilizada em arquiteturas de serviços para mostrar

como vários serviços e como os participantes trabalham em conjunto para

alcançar os objetivos de negócio ou requisitos. Esta interface de serviço é

definida a partir da perspectiva do prestador do serviço - o tomador de ordem.

• Fornecedor: Order Taker - isto define o papel do provedor de serviço de ordem

(interface que um provedor vai exigir uma porta para prestar este serviço). O

provedor é o participante que oferece algo de valor para o consumidor.

• Consumidor: Order Placer - este é o papel do consumidor de serviço de ordem .

O consumidor é o participante que tem alguma necessidade e solicita um serviço

de um provedor. Esta é a interface que um consumidor irá implementar em uma

porta para consumir esse serviço (no caso de um serviço unidirecional, pode não

haver uma relação de consumo).

2.2. Especificando a coreografia

Figura 5 - Lugar coreografia ordem

A coreografia de serviço acima é um comportamento da propriedade da

interface de serviço e define as interações necessárias e opcionais entre o

prestador e o consumidor. Há dois conjuntos de interações primárias - O pedido

de citação, resultando em uma citação e da ordem, resultando em uma

confirmação do pedido.

Neste caso, essas interações podem ser definidas através de sinais, o que

torna esta interface de serviço assíncrona e o documento orientado.

2.3. O uso da interface de serviço para definir participantes

Os participantes definem os tipos de organizações, funções

organizacionais, ou componentes pelos papéis que desempenham em

arquiteturas de serviços e os serviços que prestam e usam. Por exemplo, na

Figura 6, a figura da direita, ilustra um participante “fabricante” que oferece um

serviço “comprador”. Participantes fornecem recursos através de portas de

serviço geridas pelo ServiceInterfaces ou em casos simples, UML interfaces que

define os seus recursos fornecidos ou oferecidos.

O serviço utiliza o conceito de UML de uma porta e indica o ponto de

função ou interação através do qual um classificador interage com outros

classificadores (ver Figura 6). Uma porta digitada por um ServiceInterface e

designada com o «Serviço» é conhecida como uma porta de serviço. A porta de

serviço é a característica que representa o ponto de interação em um participante

na qual um serviço é efectivamente prestado. Em outras palavras, a porta de

serviço é o ponto de interação para envolver os participantes em um serviço via

suas interfaces de serviço.

Assim como queremos definir os serviços prestados por um participante

usando uma porta de serviço, queremos definir quais os serviços que um

participante precisa ou consome. Quando um participante expressa suas

necessidades, fazendo um pedido para os serviços de algum outro participante,

sua solicitação é definida usando uma porta estereotipada como uma porta

«pedido».

O ServiceInterface é usado para gerar portas de «Serviço» e de

«Pedido» dos participantes. O prestador do serviço usa uma porta «serviço» e o

consumidor do serviço usa uma porta «pedido». As portas de «Serviço» e

«Pedido» são os pontos de interação para o serviço.

Vejamos alguns participantes:

Figura 6 - Participação nos serviços

Nota-se que tanto o revendedor e o fabricante tem uma porta "Place

Order Service", o fabricante é o prestador do serviço possuindo uma porta

«serviço», e o revendedor é um consumidor do serviço possuindo a porta

«Request». Percebe-se também que a porta do fabricante fornece uma interface

"Taker Ordem" e exige a interface "Placer Ordem".

2.4. Conceitos-chave da arquitetura de serviços

Um dos principais benefícios do SOA é a capacidade de permitir que

uma comunidade, organização ou conjunto de sistemas possam trabalhar em

conjunto de forma mais coesa utilizando serviços sem ficar excessivamente

acoplado. Isso requer uma compreensão de como as pessoas, organizações e

sistemas trabalham em conjunto, ou colaboram para algum propósito.

Nós permitimos esta colaboração, criando um modelo de arquitetura de

serviços. A arquitetura de serviços coloca um conjunto de serviços no contexto e

mostra como os participantes trabalham juntos para apoiar a comunidade de

objetivos.

A ServicesArchitecture (ou SOA) é uma rede de papéis de participantes

fornecendo e consumindo serviços para cumprir um propósito. A arquitetura de

serviços define os requisitos para os tipos de participantes e realizações de

serviços que cumprem essas funções. A arquitetura de serviços também pode ter

um processo de negócio para definir as tarefas e orquestração de fornecer esse

valor. A arquitetura de serviços é uma visão de alto nível de como os serviços

trabalham juntos para um propósito. Os mesmos serviços e participantes podem

ser utilizados em muitas arquiteturas, proporcionando reutilização.

A arquitetura de serviços tem componentes em dois níveis de

granularidade: A arquitetura de serviços à comunidade é uma visão de "nível

superior" de como os participantes independentes trabalham coordenadamente.

Não assumindo ou exigindo qualquer entidade ou processo de controle, mas

modelando com componentes como de colaboração estereotipados como

«ServicesArchitecture».

Um participante pode também ter uma arquitetura que especifique sub-

serviços que trabalham juntos para fornecer os serviços de o participante possui.

A arquitetura de um participante é mostrada como uma arquitetura de serviços,

realizada por uma classe UML ou componente e, frequentemente, tem um

processo de negócio associado.

Os participantes que realizam esta especificação devem aderir à

arquitetura especifica. A ServicesArchitecture (veja a Figura 7) é definido

usando uma colaboração UML.

Figura 7 - Exemplo de arquitetura de serviços da comunidade com funções e

serviços participantes.

  A arquitectura de serviços serve para definir as características de cada

um dos participantes, seus papéis, como são preenchidos pelos participantes,

quais portas de serviço são exigidas nas entidades que preenchem esses papéis

e, em seguida, estão vinculados às arquiteturas de serviços em que participam.

Podemos utilizar a ServicesArchitecture para especificar a arquitetura

dentro de um participante (onde existe um conceito de "gestão" existe uma

arquitetura de serviços ) mostrando como perceber os participantes e

colaboradores externos atuações e o acompanhamento do processo de negócio.

A ServicesArchitecture ou classe especificação pode ser composto a partir de

outras arquiteturas de serviços e contratos de serviços.

Figura 8 - Exemplo de arquitetura de serviços para um participante

A Figura 8 ilustra a arquitetura de serviços para um determinado

participante " Manufacturer", indicando que esta arquitetura consiste de uma

série de outros participantes interagindo através de contratos de serviços. A

arquitetura de serviços participante “Fabricação” incluiria um processo de

negócio que especifica como estes participantes interagem a fim de proporcionar

um serviço de compra.

Esta arquitetura de serviços é a arquitetura para um fabricante

específico, compreendendo as exigências do fabricante em geral. Nota-se que os

papéis "de fora" do fabricante são indicados pelos papéis com linhas tracejadas

(:Dealer and :Shipper) sendo "agregação compartilhada" em UML. Um

componente pode então realizar e/ou utilizar esta arquitetura de serviços.

O efeito líquido é que as arquiteturas de serviços podem ser usadas para

especificar como é o trabalho do conjunto de sistemas (todo o caminho), não

prendendo-se a componentes de tecnologia.

2.5. Contratos de serviço e contrato com base SOA

Uma parte fundamental de um serviço é o ServiceContract ( Figura 9).

Figura 9 - Exemplo ServiceContract

A ServiceContract contem os termos, condições, interfaces e

coreografias que interagem com os participantes (direta ou indiretamente) .

Definindo a especificação completa de um serviço que inclui todas as

informações, e quaisquer outros termos e condições do serviço. Ela é vinculativa

para os provedores e consumidores desse serviço ,ou a todos os participantes no

caso de um serviço multipartidário. A base do contrato de serviço também é uma

colaboração UML que está focada nas interações envolvidas no fornecimento do

serviço. Um participante joga um papel no âmbito maior de uma

ServicesArchitecture e também desempenha um papel como o fornecedor de

serviços ou do utilizador especificados por ServiceContracts.

A coreografia é uma especificação do que é transmitido, e quando ela é

transmitida entre as partes para aprovar um serviço de troca. A coreografia

especifica o intercâmbio entre as partes - os dados, ativos e obrigações que vão

entre elas. Definindo o que acontece entre o fornecedor e os participantes de

consumo, sem definir os seus processos internos - seus processos internos têm

que ser compatíveis com suas ServiceContracts. Uma coreografia

ServiceContract é um comportamento UML, tal como pode ser mostrado no

diagrama de interação 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 operações ou recepções de sinais necessários para os tipos de papel

desempenhados - estes conterão cada obrigação, ativo, ou parte dos dados que a

entidade pode enviar ou receber como parte do contrato de serviço. Fornecendo

o uso de interfaces UML correspondentes, desta forma montando a "liga dos

pontos" entre o contrato de serviço e os requisitos para qualquer participante a

desempenhar um papel no serviço de provedor ou consumidor.

Um dos recursos importantes de SOA é que ele pode trabalhar "na

grande", onde entidades independentes estão interagindo através da Internet para

os departamentos e processos internos. Isto sugere que existe um caminho para

decompor um ServicesArchitecture e visualizar como os serviços podem ser

implementados usando ainda outros serviços. Um participante podem ainda ser

descritos pela sua arquitetura interna de serviços ou por um componente

composto. Tal participante também pode usar os serviços internos ou externos,

montar outros participantes, processos de negócios e outras formas de

implementação. SoaML mostra como a estrutura interna de um participante é

descrita usando outros serviços. Isto é feito através da definição de um

ServicesArchitecture para participantes de uma arquitetura de serviços mais

granular (escala maior), como é mostrado na Figura 7 e a Figura 8.

A especificação de um SOA quando apresentado como um modelo UML

esses modelos são geralmente considerado estático, no entanto, qualquer das

construções SoaML poderia muito bem ser construído dinamicamente em resposta às

mudanças nas condições. A semântica de SoaML são independentes do tempo de

design, ou a tomada de tempo de execução. Por exemplo, um ServiceContract novo ou

especializado poderia ser negociado em tempo real e imediatamente utilizados entre os

participantes específicos. A capacidade de infra-estrutura tecnológica para suportar tal

comportamento dinâmico é apenas emergente, mas SoaML pode apoiá-lo em seu

cresciento.

2.6. Exemplo de Contrato com base SOA

Um contrato de serviço é representada como uma colaboração UML e

define funções específicas a cada participante jogando no contrato de serviço.

Esses papéis têm um nome, um tipo de interface que pode ser estereotipado

como o "provedor" ou "Consumidor." O consumidor está prevista para iniciar o

serviço, chamando o provedor para fornecer algo de valor para o consumidor.

Figura 11 – Coreografia - Ordem de Serviço Contrato

A figura acima ilistra a coreografia de um contrato de serviço, neste há dois

conjuntos de interação principais:

1) a solicitação de cotação, resultando em uma citação, e

2) a ordem, resultando em uma confirmação do pedido. Neste caso, essas

interações podem ser definidas através de sinais, o que torna este serviço

contrato assíncrono e documento orientado, um mainstream melhores práticas

SOA.

Vamos dar uma olhada em algumas das partes deste contrato de serviço.

Figura 12 – Interface de Colaboração – Contrato de serviço

O diagrama de interação na Figura 12 é parte da ordem colaboração contrato de

serviço. Esta colaboração liga as partes do contrato de serviço. As peças incluem

o diagrama de interação, descrevendo as funções do serviço, e as interfaces que

definem as operações e recepções de sinal, podendo ser recebido pelos

participantes de cada função.

2.7. Exemplos graficos de uso de contratos de serviço

Figura 13 - Participação nos serviços

Figura 14 - Uso de Solicitação - "Service" e "Request"

Figura 15 - coreografia Multi-partido

Figura 16 - Contrato de prestação de serviços multi-partidária e as interfaces

2.8. Recursos

ServiceArchitectures e servicecontracts fornecer uma maneira formal de

identificar os papéis desempenhados pelas partes ou pelos participantes, suas

responsabilidades, e como eles têm a intenção de interagir, a fim de atender os

objetivo usando serviços. Isto é muito útil em alguma "necessidade" ou contexto

de montagem. No entanto, quando re-arquitetamos aplicativos existentes para

serviços ou construímos a partir do zero, mesmo os participantes abstratos ainda

não pode ser conhecido. Nestas situações é útil também para expressar uma

arquitetura de serviços em termos das capacidades lógicas dos serviços, mesmo

que os consumidores do serviço não devam se preocupar com a forma como um

serviço é implementado, é importante ser capaz de especificar o comportamento

de um serviço ou recurso que vai realizar ou implementar um ServiceInterface.

Isso é feito dentro de SoaML.

Figura 19 - Capacidades de serviço para o processamento de pedidos de compra

Conforme a figura acima, além de especificar as habilidades dos participantes,

de um ou mais recursos, podemos utilizar para especificar o comportamento e a

estrutura necessária para suportar a ServiceInterface. A Figura 6.20 mostra a

capacidade do transporte realizar o ServiceInterface Shipping.

Assim, a “Capability” permite a especificação de um serviço sem levar

em conta como esse serviço pode ser implementado e, posteriormente, oferecido

aos consumidores por um participante. Ele permite que os arquitetos analisem a

forma de como os serviços estão relacionados e como eles podem ser

combinados para formar uma capacidade maior antes da alocação de cada

participante.

Figura 20 - ServiceInterface realizado por um Recurso

Recursos podem ser realizados com um participante, quando o próprio

Recurso realiza uma ServiceInterface, que será normalmente do tipo de um

serviço do Participante. Como mostra a Figura 6.21.

Figura 21 - O participante Shipper percebe a Recurso do transporte

Recursos também podem ser usados para especificar as partes dos participantes,

os recursos que realmente prestam aos seus serviços.

A figura abaixo (Figura 22) mostra o Participante “Productions” com

duas partes digitadas pelo “Capabilities”. O Serviço “productionoffice”

delegando pedidos para a parte programador que é digitado pela capacidade de

programação. Isso normalmente indicam que a capacidade de programação

percebe o ServiceInterface SchedulingService.

Figura 6.22 - Productions Participante com duas partes especificadas pelo Capabilities

ServiceInterfaces também pode expor “Capabilities”. Isso é feito dentro

de SoaML com a dependência Expose. A Figura 23 apresenta um exemplo de

uma tal situação.

Figura 23 - ServiceInterface expondo as vendas e capacidade de marketing

Cada recurso pode possuir comportamentos que são métodos de

suas operações previstas. Estes métodos seriam usados para especificar como os

recursos poderiam ser implementados, e para identificar outros recursos

necessários. Alternativamente, ServiceInterfaces pode simplesmente expor

recursos de um participante.

2.9. O Perfil SoaML de UML

Os estereótipos, a seguir, definem como utilizar SoaML em UML com base no

conjunto de estereótipos definidos no perfil SoaML.

Figura 24 - Integração BMM

Figura 25 – Contratos

Figura 26 – Serviços

Figura 27 - Dados de Serviços

Figura 28 – Milestones

Figura 29 – Capacidades

2.10. Descrições estereótipo

2.10.1. Agente

Um agente é uma classificação de entidades autônomas que podem

adaptar-se e interagir com o ambiente. Ele descreve um conjunto de instâncias

de agentes que têm características, restrições e semântica em comum. Agentes

em SoaML também são participantes, fornecendo ou utilizando serviços.

Descrição

Em geral, os agentes podem ser agentes de software, agentes de

hardware, firmware agentes, agentes robóticos, agentes humanos, e assim por

diante. Estas propriedades são 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 não aparecem diretamente no metamodelo

SoaML, podemos associa-los com conceitos SoaML relacionados. Cada aspecto

de um agente pode ser expresso como uma arquitectura de serviços.

Dependendo do ponto de vista de um sistema de agentes, vários

aspectos são importantes. Mesmo que estes aspectos não aparecem diretamente

no metamodelo SoaML, podemos relacioná-las com conceitos de SoaML

relacionados (aspecto Agent, aspecto de colaboração, Papel aspecto, aspecto de

Interação, aspecto comportamental, Organização / Grupo aspecto).

O propósito de um agente é especificar uma classificação de entidades

autônomas (instâncias do agente) que podem se adaptar e interagir com seu meio

ambiente, e para especificar as características, limitações e semânticas que

caracterizam os casos de agentes.

Restrições

O isActive propriedade deve ser sempre verdadeira.

Notação

Um agente pode ser designado usando o componente ou a notação de

Classe / Classificador incluindo o «Agente» palavra-chave ou o ícone de

decoração Agent no compartimento o nome do classificador.

Figura 6.30 – notação do agente

Adições ao UML2

Agente é um novo estereótipo em SoaML estendendo UML2, um

componente com novas capacidades.

2.10.2. Anexo

Uma parte de uma mensagem que está ligada ao invés de contida na

mensagem.

Estende Metaclass

• Property

Descrição

  Um anexo denota algum componente de uma mensagem que é um

anexo a ela (ao contrário de uma parte direta da própria mensagem). Em geral,

este não é susceptível de ser usado em atividades de design de nível superior,

mas para muitos processos de dados é importante diferenciar a partir dos dados

de mensagens embutidas. Por exemplo, um serviço de catálogo pode retornar

detalhes gerais do produto como uma parte da mensagem, mas as imagens

estruturadas como anexos de mensagem. O que também permite denotar que a

codificação das imagens é feita de forma binária (por oposição à codificação da

mensagem principal).

Os anexos podem ser usados para indicar a parte de dados de serviço

que podem ser acedidos separadamente, reduzindo os dados enviados entre os

consumidores e fornecedores, a menos que seja necessário.

Atributos

• codificação: String [0 .. 1] denota o mecanismo de codificação plataforma usar

para gerar o esquema para a mensagem; exemplos podem ser SOAP RPC, Doc-

Literal, ASN.1, etc

• mimeType: String [0 .. 1] Indica a iana MIME tipo de mídia para a fixação

Notation

Anexos usam a notação usual UML2 para DataType com a adição de um

"Anexo" estereótipo.

Examples

A Figura 31 mostra um anexo InvoiceContent ao MessageType fatura. Este

anexo contém informações detalhadas sobre a fatura.

Figure 31 - InvoiceContent

Adições 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 específica para fornecer um serviço.

Extends Metaclass

• Class

Descrição

Um recurso é a capacidade de agir e produzir um resultado que atinge

outro resultado. Esse elemento permite a especificação de recursos e serviços,

sem levar em conta como um determinado serviço pode ser implementado e

posteriormente oferecido aos consumidores por um participante. Ele permite que

arquitetos analisem como os serviços são relacionados e como eles podem ser

combinados para formar alguma capacidade maior antes da alocação de um

determinado participante.

.

Notação

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 necessários para o

processamento de ordens de compra. Ver também a Figura 23.

Adições ao UML2

Recurso é um novo estereótipo usado para descrever a capacidade de serviço.

2.10.4. Consumidor

Modelos de consumo do tipo de um consumidor de serviço. O

consumidor é usado como o tipo de papel num contrato de serviço e identifica o

tipo de porta de um participante.

Extends Metaclass

• Interface (no caso de um contrato de serviço não composto)

• Class (no caso de um contrato de serviço composto)

Descrição

Um modelo «Consumidor» de interface fornecida pelo consumidor de

um serviço recebe os resultados da interação do serviço. O consumidor será

normalmente aquele que inicia a interação de serviço. Interfaces de

consumo são usados como um tipo de «ServiceContract» e está sujeito aos

termos e condições do contrato de serviço.

Restrição

O «Consumidor» é obrigado pelas restrições a ter comportamento do

tipo ServiceContract.

Notação

Um Consumidor é indicado para usar uma classe ou interface com o

«Consumidor» estereótipo.

Examples

O diagrama acima mostra uma interface “consumidor” usando o papel

de consumidor no contrato de serviço. Esta interface do consumidor é do tipo de

porta de um participante que consome este serviço.

O diagrama acima mostra o tipo de porta de um participante, onde o serviço é

consumido.

2.10.5. Colaboração

A Colaboração é estendida para indicar se o papel de ligações parte de

CollaborationUses, onde é rigorosamente inserids por uma colaboração aplicada

ou não.

Extends Metaclass

• Collaboration

Descrição

Um colaboração, ServiceContract, ou ServicesArchitecture representa

um padrão de interação entre os papéis. Essa interação pode ser informal e

vagamente definida como um esboço exigências. Ou pode representar acordos

formais ou exigências que devem ser cumpridas fielmente. A propriedade

“isstrict” de colaboração estabelece o valor padrão de “isstrict” para qualquer

CollaborationUse inserido pela Colaboração.

Como o ServiceContract é vinculativo para o ServiceInterfaces nomeado em

contrato, a CollaborationUse não é necessária se os tipos são compatíveis.

Atributos

• isStrict: Boolean = true

Indica se esta colaboração é a intenção de representar um padrão rigoroso de

interação. Estabelece o valor padrão para qualquer CollaborationUse digitada

por esta colaboração.

2.10.1. CollaborationUse

CollaborationUse é estendido para indicar se o papel para ligações de peças são

rigorosamente aplicadas ou soltas.

Estende Metaclass

• CollaborationUse

Descrição

A CollaborationUse é uma declaração 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 Colaboração. É uma afirmação sobre a

estrutura e o comportamento do classificador. Contém a adequação de suas

partes para desempenhar papéis de uma finalidade específica.

Atributos

• isstrict: Boolean

Indica se este cumprimento especial se destina a ser rigoroso.

Semântica - pontos de variação

Conformidade entre tipos nomeados - Colaboração na utilização de papeis em

um ponto de variação semântica, que será determinada por modeladores ou

ferramentas.

Examples

A Figura 32 apresenta uma ServiceInterface ShippingService que preenche a

colaboração ShippingContract. O ShippingService contém uma

CollaborationUse que vincula as partes que representam, os consumidores e

fornecedores da ServiceInterface aos papéis que desempenham na colaboração

ServiceContract. A parte do transporte está vinculado ao papel do transporte e da

parte ordenador está vinculado ao papel ordenador. Estas peças devem ser

compatíveis com as funções que desempenham.

Figura 32 - Cumprindo a ServiceContract ShippingContract

A Figura 33 mostra um participante que reúne e conecta uma série de

outros participantes, a fim de aderir ao fabricante Arquitetura

ServicesArchitecture. Neste caso, os papéis do ServicesArchitecture são

inseridos por qualquer ServiceInterfaces ou participantes da arquitetura

especifica, a interação 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 características 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 serviço cuja ServiceInterface é o

mesmo que o tipo de papel no ServicesArchitecture. Os papéis de agendamento

e transporte são semelhantes. Adições 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/modelingwithsoaml-

http://translate.google.com.br/#en/pt/ (brincadeira)