Download - Modelagem através de SOAML
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)