Web Services Equipe: Cláudia Brito Lyra Nunes da Silva

Apresentação em tema: "Web Services Equipe: Cláudia Brito Lyra Nunes da Silva"— Transcrição da apresentação:

1 Web Services Equipe: Cláudia Brito Lyra Nunes da Silva
Clindemberg Mendes Patrício Luiz Eugênio Fernandes Tenório Marcelo Faro do Amaral Lemos Marco Antônio Costa Simões Paula Geralda Barbosa Coelho Simith

2 Tópicos Web Services CORBA e Web Services SOAP & WSDL UDDI WSFL ebXML

3 Web Services

4 Integração de Aplicações
O desafio da interoperação entre ambientes heterogêneos

5 Integração de Aplicações
Diversidade de componentes EJB, CORBA, DCOM ... Diversidade de linguagens Java, C/C++, C# ... Firewalls Falta de padrões para interoperação

6 Integração de Aplicações
Definindo o formato para troca de dados

7 Business-to-Business
Aplicações se conhecem e conversam entre si

8 Web Services Aplicações oferecem serviços que podem ser acessados dinamicamente

9 Web Services Próxima geração de serviços baseados na internet que utiliza padrões da indústria, como XML, SOAP, UDDI e ebXML, para conectar aplicações e provê novos serviços via Internet serviços mais robustos e integrados Nova “onda” de componentes serviços como componentes reutilizáveis “blocos” que integrados produzirão novos serviços

10 Web Services Definição Modelo computacional distribuído
fracamente acoplado utiliza mecanismos de transporte padrão (HTTP e HTTPS) modelo de programação síncrona e assíncrona utiliza XML para o transporte de dados Descrito através de metadados (XML) Localizável através de pesquisas em diretórios de serviços

11 Web Services Service-oriented Serviços inteligentes Tecnologia
paradigma de orientação a serviços Serviços inteligentes coarse grained services Tecnologia basicamente é XML sobre HTTP XML: porque o mercado concorda HTTP: livre acesso através de firewalls

12 Web Services A web “costumava” ter foco em pessoas
A web está se tornando um plataforma A2A (application-to-application) B2B é um caso especial Web Services é a plataforma computacional distribuída sobre a qual aplicações A2A serão construídas

13 Arquitetura Típica de uma Aplicação Web
Web Services

14 Web Services

15 Web Services

16 Web Services pode ser visto como middleware ?

17 Tecnologias Web Services
Any technology-service paradigm Tipicamente SOAP: transporte de dados (XML/HTTP) WSDL: descrição dos serviços UDDI: registro e busca de serviços ebXML: framework para e-commerce WSFL: composição de Web Services

18 SOAP Simple Object Access Protocol
Modelo de mensagens independente do protocolo de transporte suporte para HTTP Modelo de codificação para tipos do sistema exemplo: XML para objetos Java, e vice-versa RPC sobre HTTP

19 WSDL Web Services Definition Language
Provê descrição funcional de serviços IDL description Protocol and deployment details idealmente deveria provê todas as informações necessárias para acessar o serviço (programaticamente) Machine-readable description

20 UDDI Universal Description, Discovery and Integration
Coleção de diretórios (peers) que contém informações sobre negócios e serviços Conjunto de especificações baseadas em padrões para a descrição e pesquisa de serviços

21 UDDI

22 WSFL Web Services Flow Language Composição de Web Services
controle do fluxo de mensagens Construída sobre WSDL Modelos de utilização Flow Model compõe serviços existentes em novos serviços, definindo o workflow entre os serviços compostos Global Model descreve a interação entre serviços sem definir a função (serviço) composto

23 Web Services Papéis Operations Service provider Service broker
Service requester Operations Publish Find Bind

24 Business Web Novo tipo de aplicação

25 Business Web É um Web Services composto por outros Web Services

26 Business Web

27 Que tipos de aplicações utilizarão Web Services?

28 Web Services Benefícios baixo acoplamento entre aplicações
evolução independente de aplicações B2B a baixo custo (reuso) EAI (Enterprise Application Integration) não intrusiva diversidade de componentes não afeta interoperabilidade diversidade de linguagens não afeta interoperabilidade padronização (futura)dos mecanismos de interoperação

29 Web Services em Java

30 Web Services em Java Estende HTTP e Servlets/JSP para suportar “program-to-program” ou “business-to-business” (Re)utiliza a infra-estrutura J2EE

31 WebServices Pack Empacotamento de todas as tecnologias necessárias para o desenvolvimento de web services WebService Pack Tomcat JAX Pack Java Server Faces JSP TagLibrary

32 Web Services Companhias estão anunciando sua estratégia para Web Services IBM, Sun, Oracle, HP, ... duas plataformas devem dominar o mercado: a plataforma Java e .NET Novos servidores de aplicação já oferecem soluções para o desenvolvimento de web services WebSphere 4.0 (IBM) WebLogic 6.1 (BEA) ...

33 Web Services Considerações
operações precisam ser restringidas por mecanismos de segurança negociáveis Encriptação, autenticação, autorização ... requer padrões bem definidos e largamente adotados performance Transformação XML <->

34 Web Services Conclusão
é uma forma nova de utilizar tecnologias e conceitos já existentes viabilizada pelo contexto tecnológico e comercial atual

35 CORBA e Web Services

36 CORBA e Web Services Características benéficas a integração:
Um middleware para middleware Pode ser utilizado com um middleware existente (ex. COM/DCOM, J2EE, CORBA) CORBA: Uma arquitetura aberta composta de ~42 interfaces definidas para serviços horizontais e verticais Independência de protocolo de aplicação com a utilização de mapeamentos para GIOP

37 CORBA e Web Services Possíveis cenários de integração:
Implementando objetos CORBA utilizando Web Services; Implementando Web Services utilizando objetos CORBA; Expondo objetos CORBA como Web Services;

38 CORBA e Web Services Implementado objetos CORBA usando Web Services:

39 CORBA e Web Services Implementado Web Services usando objetos CORBA:

40 CORBA e Web Services Expondo objetos CORBA como Web Services:

41 CORBA e Web Services Comparação entre protocolos de transporte:
GIOP/IIOP SOAP/HTTP Codificação das mensagens - CDR - Menor tamanho (sintaxe binária) - XML - Maior legibilidade * (sintaxe texto) Complexidade de empacotamento - Simples/Média - Complicado - Devido ao uso de parsers XML Suportado na Internet - Tráfego não permitido na maioria dos firewalls - Utiliza protocolos de aplicação conhecidos na Internet (ex. HTTP) Interoperabilidade com middlewares existentes - Utilizando outros mapeamentos (ex. DCE CIOP) - Utilizando bridges (ex. DCOM) - Mapeamento mais simples - Ubiquitous industry support

42 SOAP

43 SOAP – Simple Object Access Protocol
Definição: É um protocolo que descreve mensagens trocadas entre processos, chamadas remotas a métodos e padrões para transporte via HTTP. Baseado em XML Se propõe a desempenhar o mesmo papel do IIOP (padrão CORBA), ORPC (padrão DCOM) e JRMP(padrão Java RMI) para Sistemas Distribuídos na Internet. ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo prover uma infraestrutura aberta baseada em XML, possibilitando a prática global do comércio eletrônico de uma forma consistente, segura e interoperável por todas as partes.

44 Para que mais um protocolo ?
SOAP é baseado em texto (XML) enquanto os demais protocolos (IIOP,JRMP,ORPC) são binários Vantagens: facilidade de depuração e maior adaptabilidade aos firewalls Desvantagem: tamanho da mensagem SOAP é bem maior que os protocolos binários podendo gerar perda de performance Padrão aberto e independente de plataforma ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

45 Arquitetura do SOAP Um envelope que descreve o conteúdo da mensagem e como processá-la Um conjunto de regras de codificação que descrevem como os tipos de dados definidos na aplicação são serializados Uma convenção para representar chamadas remotas a métodos (RPC) e suas respostas

46 Exemplo de Mensagem SOAP
<SOAP-ENV:Envelope xmlns:SOAP-ENV=“ xmlns:xsi=“ xmlns:xsd=“ <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Notar 3 seções bem definidas: Envelope, Header e Body No Envelope, são efetuados os mapeamentos dos namespaces padrão do SOAP que são usados em todos os documentos No Header, são encapsuladas informações que não estão direcionadas com nenhum método em particular. São informações contextuais, por exemplo: ID de transação ou informações de segurança. No Body, estão informações específicas do método (Ver exemplo no próximo slide)

47 Exemplo: SOAP Body <SOAP-ENV:Body> <ns1:sayHelloTo
xmlns:ns1=“Hello” SOAP-ENV:encodingStyle=“ <name xsi:type=“xsd:string”>Maria</name> </ns1:sayHelloTo> Este exemplo ilustra a chamada a um método sayHelloTo pertencente a uma interrace Hello que foi mapeada como o namespace ns1. O método recebe um parâmetro name, do tipo String e que está recebendo o valor “Maria” encodingStyle informa ao servidor onde está definido o padrão de codificação(serialização) utilizado.

48 Implementando um Web Service SOAP
A Especificação SOAP restringe-se aos detalhes da mensagem que é trocada entre os processos Não há qualquer padronização quanto às API’s para implementar Serviços ou clientes Existem uma série de ferramentas disponíveis: MS SOAP Toolkit, IBM WSTK, Apache-SOAP, GLUE, etc

49 Pré-Requisitos O requisito básico é possuir um Servidor Web com suporte para servlets O Serviço pode ser implementado em diversas linguagens de programação e de script Tomando Java como exemplo, um serviço é uma classe Java comum sem qualquer alteração adicional

50 Exemplo de Serviço public class HelloServer {
public String sayHelloTo(String nome) { return "Ola "+nome+", como vai ?"; } public String sayHelloTo(Name nome) { return "Ola "+nome.getName()+", como vai ?";

51 O Cliente O mesmo serviço pode ser publicado utilizando ferramentas de apoio diferentes sem sofrer qualquer alteração. O Cliente, entretanto, pode mudar bastante entre pacotes diferentes. A seguir será exemplificado um cliente para o serviço anterior usando o Apache-SOAP e outro utilizando o GLUE.

52 Cliente Apache-SOAP Call call = new Call();
call.setTargetObjectURI("urn:Hello"); call.setMethodName("sayHelloTo"); call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC); Vector params = new Vector(); params.addElement(new Parameter("nome",String.class,nome,null)); call.setParams(params);

53 Cliente Apache-SOAP Response resp = null;
try { resp = call.invoke(url,""); } ... Parameter ret = resp.getReturnValue(); Object value = ret.getValue(); System.out.println(value);

54 Cliente GLUE IHelloServerService server = HelloServerHelper.bind();
System.out.println(server.sayHelloTo(“Maria”)); A interface IHelloServerService pode ser gerada com o utilitário wsdl2java fornecido junto com o pacote; O mesmo utilitário gera também a classe HelloServerHelper. O GLUE exige que o Serviço publique a sua interface WSDL para que o cliente utilize como base Se o serviço for publicado utilizando o Servidor Web do próprio GLUE, este gera o WSDL dinamicamente

55 Tratamento de Exceções
A Especificação SOAP prevê que os métodos remotos retornem Exceções para os clientes através do rótulo <Fault> Ou seja, qualquer exceção lançada pelo Serviço será convertida em uma seção <Fault> no envelope SOAP de resposta

56 Tratamento de Exceções
Da mesma forma que a API do cliente não é padronizada, a forma como as exceções serão capturadas e tratadas também não é estabelecida No Apache-SOAP, o Fault é extraído do objeto Response que é retornado No GLUE, deve ser capturada uma exceção WrappedException que contém uma SOAPException encapsulada contendo as informações do Fault

57 WSDL

58 Porque Web Services? Resolve o conceito de aplicações distribuídas pela Internet: Baseiam-se no protocolo HTTP Utiliza um protocolo de mensagens e tipo de dados: O SOAP que permite a ativação remota de objetos Utiliza WSDL(Web Services Description Language) baseado em XML Utiliza o protocolo Disco (Discovery Protocol) que permite descobrir quais são os serviços disponíveis na URL Utiliza o UDDI (Universal Discovery, Description and Integration) que permite aos fornecedores de serviços anunciarem os seus Web Services aos desenvolvedores Acho interessante colocar uma apresentação deste tipo(pode modificar) que mostra os termos mais utilizados em Web Services. E o porque deste conceito.

59 WSDL – Web Services Description Language
Definição: É a especificação publicada para um diretório UDDI(Universal Description Discovery). Tem uma interface e implementação de detalhes específicos dos serviços da Web disponíveis e dos respectivos proprietários Baseada em XML, descreve a interface, protocolos, ligações, detalhes de visualização, tipos de dados e localização Auto-explicativa

60 A Dupla SOAP e WSDL O SOAP foi criado pela Microsoft/IBM
O WSDL foi criado para descrever os contratos(interfaces) dos serviços WEB invocados através do SOAP Estes contratos de serviços indicam à aplicação que pretende chamar os serviços, quais são as suas interfaces, incluindo parâmetros de chamada e retorno Resolvem os problemas de interoperabilidade das plataformas, mas o aspecto dinâmico ainda não foi inteiramente solucionado Auto-explicativa

61 IDL (Interface Definition Language)
Definida juntamente com o CORBA 1.1 em 1991 Descreve as interfaces que são chamadas pelos clientes e fornecidas pelas implementações O mapeamento IDL foi estabelecido primeiramente com a utilização da linguagem C++ Auto-explicativa

62 IDL X WSDL Padrão de Mapeamento SIM NÃO Protocolo de Mensagens IIOP
SOAP Registro dos Serviços - UDDI Fornece Localização (URL) Complexidade de Programação Esta comparação de IDL x WSDL foi o que consegui pensar. Quanto ao padrão de mapeamento, por enquanto WSDL não tem nenhum definido. As duas tem o mesmo propósito, porém WSDL permite localização. Na minha opinião, e em outros artigos li que o XML é difícil de ser programado, como WSDL baseia-se em XML, também é complexa a programação,veja slides seguintes com o mapeamento de IDL para WSDL. Em IDL vc pode usar outras linguagens de programação mais simples. Se não concordar com estes tópicos, pode alterar.

63 Exemplo de IDL UMA INTERFACE SIMPLES CONTENDO UMA OPERAÇÃO:
Module Exmodule { structure ExStuct{ short structMember1; float structMember2; }; exception ExException{ string excepMember1; long excepMember2; interface Exinterface { string ExOp( in long inParam1, out float outParam2, inout Exstruct inoutParam3) raises(ExException); } Checar a nota do exemplo de WSDL, página 48 do PDF em anexo. Acho que seria bom imprimir esta página e ler a nota, que é a definição para a comparação dos dois códigos.

64 Mapeamento o Exemplo de IDL -> WSDL
<?xml version=”1.0” ?> <wsdl:definitions name=”ExInterfaceService” (1) targetNamespace =” xmlns:tns=” (2) xmlns:xds=” (3) xmlns:defs=” (4) xmlns:soap=” (5) xmlns:scoap=” (6) xmlns:wsdl=” (7) <wsdl:importnamespace = “ schemas.omg.org/scoap/encoding” (8) location=”http: //localhost/schemas/omg/scoap.xsd “ /> <wsdl:importnamespace = “ example.com/ExModule/chemas” (9) location=”http: //localhost/schemas/ExModule/ExModule.xsd “ /> <wsdl:message name = “ ExException” (10) <wsdl:part name=”Exception” type=”defs:ExException” /> </wsdl:message> Espero que estas próximas páginas continuem na apresentação, pois deu um trabalhão para digitar e Carlos Ferraz tinha pedido uma comparação entre as duas.

65 Mapeamento IDL -> WSDL
<wsdl:message name = “ ExOpInput” (11) <wsdl:part name=”InParam1” type=”scoap:long” /> <wsdl:part name=”InoutParam3” type=”defs:ExStruct” /> </wsdl:message> <wsdl:message name = “ ExOpOutput” (12) <wsdl:part name=”_return” type=”scoap:string” /> <wsdl:part name=”OutParam2” type=”scoap:float” /> <wsdl:message name = “ InterfaceType” (13) <wsdl:part name=”RepID” type=”defs:ExInterfaceRepId” /> <wsdl:porttype name = “ ExInterface” (14) <wsdl:operationname=”ExOp” /> (15) parameterOrder = “inParam1 outParam2 inoutParam3” > <wsdl:input message=”tns:ExOpInput” /> <wsdl:output message=”tns:ExOpOutput” /> <wsdl:fault message=”tns:ExException” /> </wsdl:operation> </wsdl:portType>

66 WSDL

67 UDDI

68 UDDI (Universal Description, Discovery and Integration)
Permite informações sobre negócio e serviços sejam eletronicamente publicadas e consultadas. “Register once, published everywhere” Define como os negócios interagem sobre a internet e compartilham informações em uma arquitetura de registro global. É um framework para integração de Web Services. UDDI Project( participam a IBM, Microsoft e Ariba.

69 UDDI (continuação) UDDI é uma especificação global. Toda empresa espalhada pelo mundo é capaz de se registrar em um UDDI Business Registry. Business Registry implementa a especificação UDDI. Nos Registries ocorre uma sincronização de seus conteúdos regularmente. Permissões de acesso – Somente o usuário com as credenciais que conferem com as credenciais usadas para criação dos registros.

70 Benefícios imediatos de UDDI
A capacidade de negócios rapidamente e dinamicamente descobrir outros e interagir na internet. Agregar valor aos serviços já fornecidos aos seus clientes. Potencializar o crescimento do comércio B2B. Ressalva: A especificação UDDI ainda não foi submetida a organizações de padronização. A versão utilizada pelos desenvolvedores é a 1.0(Draft).

71 UDDI Informação fornecida a um registro UDDI consiste de três componentes: White pages Informações de contato da empresa. Yellow pages Categorização dos serviços pela taxonomia padrão. Green pages Informações técnicas sobre o serviço exposto(regras de negócio, descrição do serviço,...) Taxonomia: NAICS – Sistema de classificação industrial Norte-Americano UNSPSC – Classificação de produtos e serviços de padrão universal. GSC – Sistema de classificação geográfico.

72 UDDI Define quatro elementos básicos: businessEntity businessService
Possui as descrições e informações técnicas dos serviços. Cada businessEntity possui uma única chave que identifica o negócio/dado (Modela a informação de negócio). businessService Representa os serviços ou processos de negócio fornecidos pelo businessEntity (Definição de alto-nível dos serviços).

73 UDDI (elementos) bindingTemplate tModel
Apresenta os dados que descrevem as características técnicas de uma dada implementação de serviço(Mapeamento entre businessService e tModel). tModel Modela um tipo de tecnologia ou serviço.

74 UDDI (elementos)

75 Implementações de UDDI
jUDDI(“judy”) Desenvolvida pela Bowstreet. Foi uma das primeiras implementações de UDDI. Uddi4J Desenvolvida pela IBM. Está presente IBM WSTK 2.1(Web Service Toolkit).

76 WSFL

77 WSFL Web Service Flow Language Definição Modelo de fluxo Modelo global
WSFL é uma linguagem XML para descrição de composição de Web Services. WSFL suporta dois tipos de de composições: Modelo de fluxo: descreve como usar as funcionalidades fornecidas por uma coleção de Web Services para alcançar um particular negócio. Modelo global: Descreve como o conjunto de Web Services interagem entre si. Resumindo: O WSFL permite devenvolvedores facilmente criar, executar, e combinar Web Services em complexos processos e workflows

78 Processo Negócio O processo negócio é qualquer coleção de atividades que quando combinadas realizam um objetivo de negócio dado. Para o exemplo, processar um número de cartão do crédito, empregar novo um funcionário. A modelagem do Processo negócio começa com um diagrama do que ele se assemelha como um todo (fig). É importante observar que o modelo do processo negócio é uma seqüência de eventos que devem ocorrer não importando os detalhes específicos como a plataforma (Java, web services). O WSFL cria uma reapresentação XML do modelo negócio. O que você necessita, então, é compreender como traduzir um diagrama do modelo do processo negócio em um modelo de fluxo WSFL. Porém uma vez que ferramentas se tornarem disponíveis esta gerará automaticamente modelo de fluxo WSFL baseado no diagrama do processo negócio.

79 Modelo de Fluxo <flowModel name="bookTickets" serviceProviderType="airlineFlow">   <flowSource name="ticketFlowSource">     <output name="processInstanceData" message="tio:receivedTicketOrder"/>   </flowSource>   <serviceProvider name="agent" type="agentType"/>   <serviceProvider name="traveler" type="travelerType"/>   <activity name="reserveSeats">     <input name="reserveSeatsInput" message="tio:receivedTicketOrder"/>     <output name="reserveSeatsOutput" message="tio:reservation"/>     <performedBy serviceProvider="local"/>     <implement>       <internal>         <!-- .. call to credit card service .. -->       </internal>     </implement>   </activity> No diagrama, existem três funções ou papéis distintos através das quais as atividades(os retângulos) são executadas. Estes papéis representam quem é responsável por executar uma atividade específica. Para o exemplo, o viajante planeja a viagem, a linha aérea emite o bilhete eletrônico .... WSFL requer que você especifique explicitamente estes papéis como parte da implementação do processo. No WSFL usa-se o elemento serviceProviderType. Este elemento especifica a interface Web service (na forma do elemento WSDL PortType) na qual deve ser implementado por um provedor de Web Service. Resumindo cada papel (viajante,agente,linha aérea) é implementado como um provedor de Web service. É importante também ressaltar que cada atividade representa uma operação ou uma combinação de operações dentro de um portType dado.

80 Modelo Global <globalModel name="bookTripNTickets" serviceproviderType="agentType">   <serviceProvider name="travelAgent" serviceProviderType="tio:agentType">     <export>       <source portType="tio:tripHandler" operation="sendItinerary"/>       <target portType="tio:tripNTicketHandler" operation="sendItinerary"/>     </export>       <source portType="tio:tripHandler" operation="receiveTripOrder"/>       <target portType="tio:tripNTicketHandler" operation="receiveTripOrder"/>     <locator type="static" service="abc:agent"/> <locator type="uddi" bindTime="startup" selectionPolicy="first">     <uddi-api:find_service businessKey="uuid_key"         generic="1.0" xmlns:uddi-api="urn:uddi-org:api">     </uddi-api:find_service> </locator>  </serviceProvider> Pela definição o modelo global descreve como o conjunto de Web Services interagem entre si. WSDL fornece todas as informações necessárias para permitir que as aplicações cliente invoquem Web Service. No caso de um workflow WSFL, os " clientes " serão outros Web services. Uma vez que o WSDL é criado, necessita ser disposto em alguma localização acessível na rede. Resumindo, como o modelo global trata da interação de web services providers logo os web services precisam ser localizados para que a interação aconteça. Como definido pelo modelo global WSFL, há quatro maneiras diferentes para os Web services posa ser localizados: estaticamente, localmente, através de UDDI, ou dinamicamente enquanto o processo negócio está sendo executado. Falar sobre cada um entraríamos Nos detalhes do WSFL o que não é o caso

81 ebXML

82 ebXML Definição: Objetivo:
Conjunto de especificações que juntas possibilitam um framework para comércio eletrônico. Objetivo: Prover uma infraestrutura aberta baseada em XML, possibilitando a prática global do comércio eletrônico de uma forma consistente, segura e interoperável por todas as partes. ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo prover uma infraestrutura aberta baseada em XML, possibilitando a prática global do comércio eletrônico de uma forma consistente, segura e interoperável por todas as partes.

83 ebXML A que se propõe: Criar padrões para definir:
Transações comuns de negócios Formatos comuns de troca de dados Um mecanismo que possibilite descrever o perfil das companhias Um mecanismo que permita organizações descobrirem outras companhias e ter acesso ao seu perfil ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

84 ebXML Um mecanismo que permita duas organizações estabelecerem acordos (contratos) antes de iniciarem as transações Um mecanismo de transporte comum para a troca de mensagens entre as organizações Um framework seguro e confiável ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

85 ebXML Componentes ebXML Registry and Repository
Meio de compartilhar informação entre empresas Registry: Serviço similar ao UDDI Repository: Armazena informações de como a empresa trabalha: processos, documentos e perfis de negócio ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo prover uma infraestrutura aberta baseada em XML, possibilitando a prática global do comércio eletrônico de uma forma consistente, segura e interoperável por todas as partes.

86 ebXML Componentes CPP (Collaboration Protocol Profile)
Descreve o Web service (nome do serviço, parâmetros requeridos, forma de acessá-lo) Permite a empresa descrever o seu perfil CPA (Collaborative Partner Agreement) Acordo estabelecido entre duas organizções Baseado no CPP de ambas Adminstra as transações entre elas ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo prover uma infraestrutura aberta baseada em XML, possibilitando a prática global do comércio eletrônico de uma forma consistente, segura e interoperável por todas as partes.

87 ebXML Componentes ebXML Messaging Service
Qualquer transporte pode ser usado Qualquer tipo de informação pode ser roteada ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo prover uma infraestrutura aberta baseada em XML, possibilitando a prática global do comércio eletrônico de uma forma consistente, segura e interoperável por todas as partes.

88 ebXML (Visão geral de um sistema ebXML)
Fase de implementação Durante essa fase a organização deve: Solicitar as especificações ebXML e entendê-las Implementar um sistema ebXML Publicar seu perfil (CPP) de negócio no repositório ebXML, permitindo que outras organizações o acesse. ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

89 ebXML (Visão geral de um sistema ebXML)
Fase de implementação ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

90 ebXML (Visão geral de um sistema ebXML)
Fase de negociação Durante essa fase a organização deve: Recuperar do repositório ebXML o perfil de uma organização com a qual ela pretende realizar negócios Verificar se a organização provê os serviços que ela deseja Enviar a organização um contrato (CPA) ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

91 ebXML (Visão geral de um sistema ebXML)
Fase de negociação ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

92 ebXML (Visão geral de um sistema ebXML)
Fase de transação Depois que as duas organizações estiverem de acordo com o CPA as transações podem ser efetuadas. Essas transações consistem em mensagens ebXML, que são enviadas através do serviço de mensagens do padrão ebXML. ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

93 ebXML (Visão geral de um sistema ebXML)
Fase de transação ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.

94 ebXML (Visão geral de um sistema ebXML)
ebXML é um conjunto de especificações que juntas possibilita um framework para comércio eletrônico, tendo como objetivo criar um mercado eletrônico global único.