Modelagem com o SoaML, a Linguagem de Modelagem de Arquitetura Orientada a Serviços: Parte 1. Identificação do Serviço

Este é o primeiro de uma série de cinco artigos a respeito do desenvolvimento de software baseado na Arquitetura Orientada a Serviços (SOA). Ele mostra como utilizar modelos UML estendidos com o padrão OMG SoaML para desenvolver uma solução SOA que esteja conectada aos requisitos da empresa e ao mesmo tempo seja independente da implementação da solução. O autor descreve as metas e objetivos de negócio e os processos de negócios implementados para que se alcance esses objetivos. Ele então explica como utilizar os processos para identificar os serviços relevantes ao negócio necessários para preencher os requisitos que eles representam.

Jim Amsden, Senior Technical Staff Member, IBM

Jim AmsdenJim Amsden é um membro sênior da equipe técnica da IBM e possui mais de 20 anos de experiência projetando e desenvolvendo aplicativos e ferramentas para a indústria de desenvolvimento de software. Ele possui mestrado em ciência da computação pela Universidade de Boston. Ele se interessa por arquitetura empresarial, desenvolvimento baseado em contratos, programação de agentes, desenvolvimento voltado aos negócios, Java Enterprise Edition, UML e arquitetura orientada a serviços. Ele co-escreveu Enterprise Java Programming com IBM WebSphere (IBM Press, 2003) e o padrão OMG SoaML. Atualmente, sua atenção está voltada para encontrar maneiras de integrar ferramentas para dar melhor suporte aos processos de desenvolvimento ágeis. Jim é atualmente responsável pelo desenvolvimento da estratégia e suporte de ferramentas do Gerenciamento Colaborativo de Arquitetura do software IBM Rational.



16/Mar/2010

Como a modelagem melhora o SOA

O poder da Arquitetura Orientada a Serviços (SOA) está na capacidade de dar agilidade aos negócios por meio de processos de negócios. O SOA atinge esses objetivos por meio de duas maneiras: Encorajando soluções organizadas em torno de serviços reutilizáveis que encapsulam recursos funcionais separados de suas implementações e fornecendo recursos para o gerenciamento de acoplamento entre recursos funcionais. A modelagem pode ser usada para ligar os requisitos de negócios às soluções baseadas em serviços implementadas. Os modelos SoaML aumentam o nível de abstração para permitir o foco nos serviços de negócios. As abordagens Model Driven Development podem ser usadas para gerar as implementações das soluções desenvolvidas para plataformas como o Java™ Platform, Enterprise Edition (JEE), IBM® CICS®, e Web-Oriented Architectures (WOA) por meio da utilização de serviços da Web RESTful que alcançam os objetivos funcionais e não-funcionais e ao mesmo tempo garantem agilidade ao negócio.

O termo Arquitetura Orientada a Serviços (SOA) possui várias conotações. 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. Essas são perspectivas úteis focadas na tecnologia, mas que sozinhas, não são o suficiente.

Para atingir seu potencial, uma infraestrutura de TI baseada em SOA (doravante referido simplesmente como SOA) necessita ser relevante aos negócios, e portanto, dirigida pelo negócio e implementada para oferecer suporte aos negócios. Há a necessidade de um modo de desenvolver soluções SOA que estejam conectadas aos requisitos dos negócios que elas preenchem. 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.

É preciso que haja uma maneira de formalizar os requisitos de negócios e aumentar o nível de abstração para que o SOA possa assemelhar-se mais aos serviços de negócios e como esses serviços podem alcançar as metas e os objetivos. Isso liga a solução empregada a seu valor de negócios desejado. Ao mesmo tempo, é necessário que haja uma maneira de isolar os interesses de negócios das plataformas SOA em evolução que os suportam.

A modelagem e o model-driven development (MDD) podem ajudar a atingir esses objetivos. Os modelos nos permitem separar os detalhes da implementação e focar nas questões que levam às decisões de negócios e de arquitetura. Até certo ponto, a abordagem que será descrita aplica um dos princípios fundamentais do SOA para os negócios e o desenvolvimento de soluções: separação de interesses e acoplamento solto. Aqui, separamos as tarefas e responsabilidades dos analistas de negócios das dos membros da equipe de TI.

A criação de soluções de TI ágeis, adequadas e reutilizáveis para os problemas do negócio pode ser difícil. Ela requer foco na arquitetura que separa os interesses e reduz o acoplamento entre as partes, especialmente quando os componentes da solução pertencerem a diferentes organizações. Ser capaz de responder rapidamente a mudanças através de soluções de negócio integradas é ainda mais difícil. Integração e interoperabilidade requerem padrões para os componentes desenvolvidos por diferentes organizações em épocas diferentes para serem conectados juntos a novas soluções. SoaML (Service-Oriented Architecture Modeling Language) é um padrão de Grupo de Gerenciamento de Objetos (OMG) que tem como objetivo fazer conexão e ajudar na percepção do potencial do SOA. SoaML é um pequeno conjunto de extensões UML para oferecer suporte à modelagem SOA. Ele fornece uma abstração de SOA focada na descrição das necessidades e recursos dos participantes e conectando-os nas cadeias de valor do serviço.

A SoaML oferece vários benefícios

  • Permite a interoperabilidade e integração no nível do modelo
  • 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
  • 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
  • Habilita o SOA tanto nas plataformas existentes como entre elas, através de model-driven architecture (MDA)
  • Permite a escolha de plataformas flexíveis
  • Desacopla implementações de soluções de plataformas de arquitetura para prevenir que as soluções existentes impeçam a evolução da plataforma
  • Alavanca e se integra a padrões OMG existentes para o desenvolvimento e gerenciamento de ciclos de vida de ponta a ponta

Sobre esta série a respeito da modelagem SOA

Esta série de artigos mostra como utilizar modelos UML que são estendidos com o perfil OMG SoaML para desenvolver uma solução SOA que esteja conectada aos requisitos do negócio e seja independente da implementação da solução. Geralmente é mais fácil de se entender conceitos por meio de exemplos concretos, típicos e completos. Será essa a abordagem utilizada aqui. Não perderemos muito tempo lidando com detalhes do SoaML. Ao invés disso, focaremos em como se pode utilizar o SoaML para ajudar no projeto e desenvolvimento.

Apesar de esta série de artigos ser a respeito de soluções para serviços da Web a partir de modelos SoaML, começaremos focando nas metas e objetivos de negócios que estamos tentando alcançar, para que nossa solução seja direcionada para se alcançar algo de valor para o negócio. Então exploraremos o processo de negócios que modela o que foi feito no negócio para se atingir essas metas e objetivos. Isso fornecerá os requisitos funcionais de negócio que essa solução deve alcançar. Então utilizaremos o processo de negócios para ajudar a identificar os requisitos de negócios necessários que podem ser concebidos como serviços em uma solução desenvolvida que alcance os requisitos de negócios.

Nos artigos seguintes desta série, criaremos especificações e implementações de serviços que preencham esses requisitos com uma arquitetura que possibilita uma futura reutilização e agilidade do negócio. Finalmente, usaremos o MDD para gerar soluções para serviços da Web que possam ser implementados e executados.

Para tornar o exemplo ainda mais real, utilizaremos ferramentas IBM® Rational® existentes para construir artefatos de soluções e ligá-los entre si para que possamos verificar a solução de acordo com os requisitos e gerenciar mudanças de maneira mais eficaz. Além disso, estendemos a Linguagem de Modelagem Unificada (UML) para serviços de modelagem por meio da adição do Perfil OMG SoaML a modelos UML no IBM® Rational® Software Architect. A Tabela 1 fornece um sumário de processo geral que será usado para desenvolver o exemplo e as ferramentas usadas para construir os artefatos.

Tabela 1. Funções do Processo de Desenvolvimento, tarefas e ferramentas
FunçãoTarefaFerramentas
Executivo de negóciosCondução das metas e objetivos de negócioIBM® Rational® Requirements Composer
Analista de negóciosAnálise dos requisitos de negóciosIBM Rational Requirements Composer
Arquiteto de softwareProjeto da arquitetura da soluçãoIBM® Rational® Software Architect
Desenvolvedor de serviços da WebImplementação da soluçãoIBM® Rational® Application Developer

Esta série de artigos focará em como capturar requisitos de negócios, construir modelos de serviços que os preencham e criar e implementar soluções que concretizem esses projetos. Também realçaremos as ferramentas de suporte demonstrando os recursos de modelagem de serviços atualmente oferecidos pelas ferramentas IBM listadas na Tabela 1. Estes artigos não focarão muito nos métodos ou técnicas para se descobrir requisitos, abordagens para analisar e avaliar as soluções de serviços ou abordagens para se particionar serviços em várias camadas de arquitetura. Para mais informações a respeito desses tópicos importantes, leia o IBM® Rational Unified Process® (RUP®) for SOMA (consulte Recursos para obter os links). Esses plug-ins IBM® Rational® Method Composer fornecem processos de desenvolvimento, orientação, mentores de ferramentas e artigos que explicam as maneiras adicionais de se usar as ferramentas para o desenvolvimento completo de modelos e soluções de serviços.


Exemplo do Processo de Ordem de Compra

Este exemplo é baseado no exemplo do Processo de Ordem de Compra tirado do padrão OMG SoaML e é baseado em um exemplo na especificação BPEL 1.1 (consulte Recursos). A especificação BPEL 1.1 contém somente uma solução parcial, pois os conjuntos de correlações não estão definidos, os dados do negócio não estão completos e não há manipulações ou compensações falhas. Esta versão do exemplo inclui dados inventados para que esteja completo — em particular, dados necessários para a correlação.

O exemplo começa utilizando o IBM Rational Requirements Composer para descrever a motivação do negócio que estabelece as metas e objetivos a serem alcançados. Isso é seguido por um processo de negócio de alto nível também capturado usando o Rational Requirements Composer que esboça os requisitos organizacionais e operacionais do negócio necessários para que se atinja as metas e objetivos. Essas motivações e modelos de processos estabelecem um contexto para a identificação de serviços que estão conectados aos requisitos do negócio.

Após entendermos os requisitos do negócio, podemos seguir para o desenvolvimento de serviços que preencham esses requisitos. O primeiro passo de uma solução SOA é identificar os serviços. Para fazer isso, trataremos do processo de negócio como um contrato de Requisitos de Serviços. Então, especificações e provedores de serviços serão desenvolvidos e conectados de maneira que se preencham os requisitos do negócio enquanto tratam dos interesses da arquitetura de software.

Esse processo de identificação dos serviços candidatos de um modelo de negócios é conhecido como decomposição de domínio. IBM Rational Unified Process (RUP) para SOMA descreve a decomposição de domínio e várias outras abordagens que, quando usadas de maneira coletiva, fornecem garantias elevadas na identificação de todos os recursos e serviços necessários ao negócio.

Requisitos do Negócio

Geralmente, os analistas de negócios focarão nos requisitos organizacionais e operacionais do negócio necessários para atingir as metas e objetivos que alcancem a visão do negócio. Geralmente, eles não estão preocupados (nem suficientemente qualificados para lidarem) com interesses de TI, tais como a reutilização, coesão e acoplamento, segurança, persistência, integridade de dados, concorrência, recuperação de falhas e assim por diante. Além disso, as ferramentas de modelagem de processos de negócios nem sempre possuem os recursos necessários para tratar desses interesses e, se possuírem, provavelmente não seriam ferramentas eficazes para os analistas de negócios. Nesta seção, usaremos esboços de modelos de processo de negócios para identificar recursos de negócios necessários para se atingir os objetivos de negócio.

Cenário: Um consórcio de empresas decidiu colaborar para a produção de um serviço reutilizável para o processamento de ordens de compra. Estes são os objetivos deste projeto:

  • Estabelecer meios comuns de se processar as ordens de compra
  • Assegurar que as ordens sejam processadas de maneira adequada e entreguem os produtos pedidos
  • Ajudar a minimizar os produtos em estoque e custos de manutenção de estoque
  • Minimizar os custos de produção e entrega

A Figura 1 mostra os requisitos capturados no Rational Requirements Composer. Note que o caso de uso de negócios do Processo de Ordem de Compra atinge todas as nossas metas de negócio.

Figura 1. Requisitos de negócios mostrados no Rational Requirements Composer
Artifacts tab view

Visualização mais ampla da Figura 1.

Também podemos criar um objetivo específico (ou indicador-chave de desempenho) que quantifique a meta "Timely order processing", ou "Processamento Adequado do Pedido" (veja a Figura 2).

Figura 2. Objetivos quantificam metas
Timely Order Processing requirement description onscreen

Visualização mais ampla da Figura 2.

Este objetivo será algo que gostaríamos de observar no modelo de processo de negócios que concretiza o caso de uso de negócios, se tornará uma restrição em nossa solução SOA e será algo que é monitorado em nosso serviço da Web implementado. Isso permitirá a monitoração e gerenciamento do serviço para se assegurar que as metas e objetivos de negócios sejam realmente alcançadas.

Processos organizacionais de negócio

Os analistas de negócios de uma empresa membro analisaram os requisitos e determinaram que o seguinte processo de negócio BPMN (Notação para a Modelagem de Processos de Negócio) capturado no Rational Requirements Composer atinge os objetivos de negócio e também os limitadores de operação do negócio. Esse processo é planejado para ser suficientemente completo e detalhado para que ele possa ser usado como base para um contrato de serviço entre as partes. Assim, nossa solução SOA que alcança esses requisitos de negócio deve se prender perfeitamente a esses requisitos (Figura 3).

Figura 3. Modelo de processo de negócios do Processo de Ordem de Compra
BPMN diagram of Purchase Order Process

Visualização mais ampla da Figura 3.

O Processo de Ordem de Compra inicia três atividades paralelas: uma para gerenciar o planejamento de produção e entrega, outra para o cálculo do preço e fatura e uma terceira para a entrega dos produtos pedidos. O processamento começa ao se iniciar o cálculo do preço baseado no pedido dos produtos. Entretanto, o preço ainda não está completo, pois a fatura total depende de onde os produtos são produzidos e o valor do custo de entrega. Ao mesmo tempo, o pedido é enviado à produção para determinar quando os produtos estarão disponíveis e em quais locais. Em paralelo, o processo solicita a entrega e então espera por um planejamento de entrega ser enviado pelo provedor de planejamento de entregas. Quando o planejamento de entrega estiver disponível, a fatura pode ser completada e enviada de volta ao cliente.

Também ligamos o Processo de Ordem de Compra ao caso de uso de negócios do Processo de Ordem de Compra para indicar que o processo concretiza o caso de uso (Figura 4). Realização é um termo formal utilizado em modelagem de casos de uso que indica a relação entre uma especificação de algo e suas várias implementações.

Figura 4. Ligando processos de negócios a casos de uso de negócios que eles implementam
Diagram of the flow from process to requirement

Você pode usar este link para navegar entre os processos de negócio e os casos de uso de negócios que ele realiza.

A próxima seção trata do processo de negócio como uma especificação de requisitos de negócios e mostra como identificar recursos e serviços necessários para preencher os requisitos operacionais do negócio.


Organização do projeto de serviços

Agora estamos prontos para criar um modelo que atenda a esses requisitos. Nossa solução preencherá esses requisitos identificando os recursos, expondo os recursos adequados como serviços e então definindo a arquitetura para a maneira como esses serviços interagem. Quando projetamos uma solução, precisamos especificar os serviços, projetar suas interfaces e decidir como eles serão implementados (quais provedores de serviços fornecem quais serviços e de que maneira). Isso estabelece as dependências entre os participantes do serviço e estabelece o acoplamento no sistema. O gerenciamento deste acoplamento é uma parte importante no projeto de serviços baseados em SOA. Ao separar os requisitos de negócios dos serviços, temos a flexibilidade de projetar o SOA para atender tanto aos requisitos do negócio quanto aos do sistema de TI. Isso impede os requisitos de negócio de limitar excessivamente a solução SOA, o que poderia levar a uma menor reutilização e agilidade do negócio.

Primeiro, criamos projeto de modelagem de serviços Rational Software Architect com o nome de PurchaseOrderProcess. Esse projeto contém um modelo de serviços chamado PurchaseOrderProcess. Esse modelo compreende um modelo de informações para serviços, dados do serviço, especificações das interfaces fornecidas e necessárias e componentes que fornecem os serviços necessários. Mas, no momento, focaremos na identificação do serviço.

Como mostra a Figura 5, há cinco pacotes principais no modelo PurchaseOrderProcess:

  • org::ordermanagement contém elementos relacionados ao gerenciamento do pedido.
  • org::crm contém o modelo de dados e interfaces comuns para algum padrão de gerenciamento de relação com o cliente com o qual os clientes do serviço e provedores de serviços concordaram para o desenvolvimento de serviços compartilhados.
  • com::acme::credit contém elementos relacionados ao faturamento e gerenciamento de crédito.
  • com::acme::productions contém elementos relacionados à produção e planejamento.
  • com::acme::shipping contém elementos relacionados à entrega.

Esses pacotes dividem o domínio do problema em diferentes áreas funcionais. Isso ajuda a gerenciar complexidades, estabelecer espaços de nomes necessários, facilitar a reutilização e manter interesses separados em pacotes diferentes (veja a Figura 7).

Figura 5. Diagrama das dependências de pacote
Diagram of UML package dependencies

Essa organização pode ser chamada de organização dominante do modelo de serviço. Pacotes de perspectiva podem ser usados para documentar outras maneiras de se organizar os mesmos elementos do modelo, como através do método SOMA, por exemplo.


Identificação do Serviço

Alguns processos de negócio podem ser executados diretamente em plataformas como o IBM® WebSphere® Process Server. Mas há situações nas quais os processos de negócio não atenderam aos interesses de TI de maneira adequada e poderiam possivelmente ser refatorados para serem mais bem reutilizados e tratar dos requisitos não-funcionais, tais como performance, escalabilidade e segurança. Nesse caso, os processos de negócio podem ser pensados como especificações dos requisitos para o que uma solução TI deve fazer.

Requisitos identificando serviços candidatos

Iniciamos o modelo de serviço identificando os recursos que estão envolvidos no processamento de uma ordem de compra. Neste momento, os detalhes sobre o que os serviços fazem ou como eles interagem não são importantes. Queremos somente criar um esboço de quais são os recursos necessários e uma ideia de alto-nível de como eles podem interagir para identificar qualquer recurso adicional.

Os detalhes sobre a maneira como esses recursos foram identificados estão fora do escopo deste artigo. IBM RUP para SOMA (consulte Recursos) fornece um processo, métodos e orientação para a maneira de se identificar recursos de motivação de negócios e estratégia, áreas funcionais de negócio, processos de negócio e ativos existentes. O IBM SOMA descreve três técnicas:

  • Modelagem de serviços orientada pelos objetivos, que identifica recursos necessários para realizar requisitos de negócios tais como estratégias e objetivos
  • Decomposição de domínio, que utiliza atividades em processos de negócio e outras descrições de funções de negócio para identificar recursos necessários
  • Análise de ativos existentes, que extrai recursos de aplicativos existentes

Ao utilizar modelagem de serviços orientadas pelos objetivos e técnicas de decomposição de domínio, podemos identificar os recursos necessários para processar ordens de compra. A Figura 6 a seguir é um diagrama de classes simples sobre o Rational Software Architect que mostra os recursos identificados. A única informação a respeito do recurso dada é o seu nome. Esses recursos são identificados pela análise dos processos de negócio e organização das tarefas em operações de recursos identificadas por cada raia no processo.

O uso de dependências no diagrama mostram como esses recursos devem se relacionar uns aos outros. Neste momento, não sabemos quais recursos podem estar expostos como serviços, não possuímos especificações de serviços completas nem sabemos quais participantes do serviço fornecerão ou necessitarão de quais serviços. Também não fizemos a modelagem de nenhuma implementação desses serviços. Assim, essas dependências de uso são simplesmente uma indicação de relações antecipadas entre os recursos que podem ou não ser verdadeiros quando completarmos as especificações e implementações de serviços. Entretanto, essas dependências são de valor neste alto nível, pois elas começam a identificar usos e fazer o acoplamento entre sistemas que precisa ser gerenciado cuidadosamente.

Figura 6. Recursos de serviço
Diagram shows related service capabilities

Possuímos os recursos para o Processo de Ordem de Compra dos requisitos e processos de negócio do Rational Requirements Composer. A identificação do serviço consiste em determinar quais recursos devem ser expostos como serviços. O método IBM SOMA fornece um Teste de Serviço Litmus que pode ser aplicado aos recursos para determinar quais devem ser expostos como serviços. Não cobrimos todos os detalhes aqui. Consulte RUP para SOMA para maiores informações.

O Teste de Serviço Litmus examinará cada recurso e aplicará métricas configuráveis para determinar qual deve ser exposto como serviços. A Figura 7 mostra os serviços que foram identificados que expõem os recursos. Por exemplo, a interface de serviço InvoicingService exporá o recurso de faturamento. Isso significa que qualquer participante que fornece este serviço fornecerá o recurso e qualquer participante que o solicite usará o recurso.

Figura 7. Serviços identificados para o processamento de ordens de compra
Diagram shows exposed capabilities

Arquitetura dos Serviços

O SoaML fornece várias maneiras de identificar serviços. Os requisitos do processo de negócio podem ser vistos como uma arquitetura de serviço e, dessa maneira, indicar os participantes no processo de negócio, os contratos de serviços que especificam a modo de interação e a coreografia de seus serviços e solicitações.

Uma arquitetura de serviço é uma especificação formal dos requisitos de negócios que são executados pela interação dos participantes do serviço, sem tratar de qualquer questão de arquitetura ou de implementação de TI. Nesse caso, a arquitetura do serviço contém a mesma informação que o processo de negócio original e pode ser tratada como uma especificação pela maneira como realiza esse processo de negócio.

A Figura 8 mostra a arquitetura de serviço para o processamento de ordens de compra no IBM® Rational® Software Modeler. Os detalhes para o ServeceContracts mostrados na Figura 8 não são cobertos neste artigo, mas serão tratados nos próximos artigos desta série. Por enquanto, esses ServiceContracts simplesmente indicam as interações com as quais os participantes que executam as funções indicadas na arquitetura de serviço concordaram.

Figura 8: Arquitetura de serviços para o processamento de ordens de compra
Services architecture diagram for the manufacturer

Visualização mais ampla da Figura 8.

Seria útil passar um tempo maior para entender esse diagrama, pois veremos diagramas similares quando desenvolvermos a solução SoaML.

A Arquitetura do Fabricante «ServicesArchitecture» corresponde ao processo de negócio do Processo de Ordem de Compra.

Observação:
A arquitetura do serviço é mostrada usando-se uma notação classificadora (um retângulo particionado), ao invés de notação de elipse tracejada usual para uma colaboração UML. O UML 2 permite qualquer uma das duas. Esse exemplo utiliza notações retangulares por terem mais espaço para as funções.

Na modelagem de requisitos de serviços ou requisitos de serviços deriváveis de processos de negócio, uma arquitetura de serviços responde a essas questões:

  • Qual resultado o requisito pretendem atingir? Esse é o nome da arquitetura de serviço que corresponde aos requisitos de negócio. Esses nomes são, geralmente, frases verbais que incluem o que as funções de colaboração pretendem cumprir.
  • Quem participa para que isso seja feito?As funções da arquitetura de serviço especificam os participantes que interagem para atingir os resultados desejados.
  • Quais as responsabilidades das funções? Os tipos das funções representam os participantes do serviço. As responsabilidades dos participantes são especificadas pelos contratos de serviço e estão conectadas a eles. Qualquer coisa em nossa solução de serviços que execute uma função deve ser capaz de assumir essas responsabilidades. Ou seja, elas devem implementar operações especificadas pelos contratos de serviço
  • Quais funções interagem? Ou seja, quais funções devem se comunicar com outras funções? Isso estabelece dependências entre as funções. Essa interação é mostrada por meio de referências aos contratos de serviços definindo as interações permitidas entre os participantes.
  • Quais são as regras de interação das funções? Esse é o comportamento que cabe à arquitetura de serviço. O comportamento poderia ser uma atividade, interação máquina de estado ou comportamento opaco (um código, por exemplo). Esse comportamento diz quando os serviços das funções são solicitados e pode indicar as informações trocadas entre eles.
  • Como avaliamos se os requisitos foram cumpridos? Uma arquitetura de serviço pode possuir limitadores que especificam as condições que devem ser verdadeiras para que os requisitos sejam cumpridos. Esses limitadores correspondem aos objetivos de negócio.

O Processo de Ordem de Compra é uma arquitetura de serviço com quatro funções, incluindo uma executada pelo próprio processo. Essas funções podem ser derivadas do processo de negócios examinando-se as tarefas designadas às funções nas raias do processo de negócio. O Rational Requirements Composer utiliza uma visão de requisitos de negócios centrada no processo de Notação para a Modelagem de Processos de Negócio; ao passo que a arquitetura de serviço exerce uma visão centrada na função. Isso fornece uma visão de requisitos de negócios mais orientada a serviços, o que torna mais fácil a ligação entre os requisitos de processo e as soluções de arquitetura orientadas a serviços. De maneira alternativa, a arquitetura de serviço poderia ter sido projetada para realizar os recursos que foram identificados a partir dos processos e requisitos de negócios. Na verdade, uma arquitetura de serviço pode ser uma visão diferente de um processo de negócio BPMN.

Essa arquitetura de serviços pode possuir limitadores derivados de objetivos de negócio. Esses limitadores indicam com o que a arquitetura de serviços pretende cumprir e como medir o sucesso.

A arquitetura de serviços pode também realizar casos de uso que capturaram informações sobre requisitos funcionais e não-funcionais de alto nível para processos de negócio a partir das perspectivas das partes interessadas chave externas ou agentes. Esses casos de uso podem ser vistos nos diagramas de casos de uso no Rational Requirements Composer ou Rational Software Architect. Isso mantém o link entre o contrato de requisitos de serviços, processos de negócio, caso de uso do negócio e as metas e objetivos de negócio.

O uso de recursos de negócios ou arquiteturas de serviços, ou ambos, para identificar serviços candidatos é uma questão de preferência pessoal. A modelagem de recursos de negócio é uma maneira direta de decompor um negócio em competências, identificando os recursos e operações do negócio e as relações entre os recursos necessários para se atingir os objetivos de negócio. A modelagem da arquitetura de serviços fornece uma maneira mais formal de se especificar os participantes e os contratos que governam suas interações. As duas abordagens podem ser utilizadas em conjunto. Utilize a abordagem que melhor lhe satisfaça.


O que vem a seguir

Neste artigo, estruturamos uma técnica para identificar recursos que são necessários para cumprir os requisitos de negócio. Iniciamos pela captura das metas e objetivos de negócio para a visão de negócio. Então foi feita a modelagem das operações e processos de negócios necessários para se atingir as metas e objetivos. Então utilizamos o processo de negócio para identificar os recursos necessários. Isso fornece uma maneira formal de se identificar recursos relevantes ao negócio que estão ligados às metas e objetivos de negócio que pretendemos cumprir.

O próximo artigo desta série, "Parte 2. Especificação do Serviço", examina os recursos e determina quais devem ser expostos como serviços. Mostraremos as interfaces de serviço com maiores detalhes. Essas interfaces indicarão as interfaces fornecidas e necessárias, as funções que os clientes e provedores participantes exercem na interface de serviços e as regras ou protocolo do modo de utilização das operações de serviços.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=474983
ArticleTitle=Modelagem com o SoaML, a Linguagem de Modelagem de Arquitetura Orientada a Serviços: Parte 1. Identificação do Serviço
publish-date=03162010