CURSO DE LICENCIATURA EM TECNOLOGIAS DA INFORMAÇÃO E COMUNICAÇÃO

e-Business

COLIGIDO POR:
Natércia Oliveira
Mário Mineiro

7 JANEIRO 2011
ESCOLA SUPERIOR DE TECNOLOGIA DE ABRANTES
INSTITUTO POLITÉCNICO DE TOMAR

Tecnologias de Informação e Comunicação

e-Business

ebXML - e-business XML

AUTORES
13286 - Natércia Oliveira
natercialuzia@hotmail.com

13310 - Mário Mineiro

mineiro.mario@gmail.com

DOCENTES
Mário Macedo - ESTA/IPT

7 Janeiro 2011
 e-Business

<LISTA DE ILUSTRAÇÕES/>

ILUSTRAÇÕES

Ilustração 1- Abstracto XML ................................................................................................................................................ 8

Ilustração 2 – XML Abstracto ............................................................................................................................................ 10
Ilustração 3 – Abstracto Integração .................................................................................................................................. 23
Ilustração 4 – Abstracto XML ............................................................................................................................................ 24
Ilustração 5- Abstracto XML ............................................................................................................................................. 26
Ilustração 6 - Exemplo de um documento XML ................................................................................................................. 32
Ilustração 7 - Exemplo de um XML Schema ...................................................................................................................... 34
Ilustração 8 - Tecnologias em Torno do XML .................................................................................................................... 35
Ilustração 9 - Exemplo de um documento XML utilizando XInclude.................................................................................. 36
Ilustração 10 - Exemplo de um documento WSDL ............................................................................................................ 41
Ilustração 11 - Cenário inicial de ebXML Fonte: www.ebxml.org ..................................................................................... 49
Ilustração 12 - Relação entre o registo e o repositório (Ariza & Martins) ....................................................................... 53

ESQUEMAS

Esquema 1 - Modelo de armazenamento de dados corporativos (CUMMINS, 2002) ....................................................... 18

Esquema 2- Modelo de armazenamento de dados corporativos (CUMMINS, 2002) ....................................................... 22
Esquema 3 - Tríade de tecnologias que compõe os web services ..................................................................................... 42
Esquema 4 - Modelo Open-EDI ......................................................................................................................................... 50
Esquema 5 - Meta modelos UMM (Ariza & Martins) ....................................................................................................... 52

TABELAS

Tabela 1 - Arquivo texto txt versus documento ................................................................................................................ 44

XML & ebXML 3

 e-Business

<ÍNDICE/>

<Lista de Siglas e Abreviaturas/> ........................................................................................................................ 7

<Resumo/> ................................................................................................................................................................... 8

<Introdução/> ............................................................................................................................................................. 9

<Integração de Sistemas de Informação/>.................................................................................................... 11

Sistemas de Informações Inter-organizacionais ......................................................................... 11

Tipos de sistemas inter-organizacionais: .................................................................................. 12

Sistemas Legados e COTS ................................................................................................................ 13

EAI – Integração de Aplicações Organizacionais .................................................................... 13

Estratégia de Integração ....................................................................................................................... 14

Disciplinas do Conhecimento para integração............................................................................. 16

Modelos de Integração .......................................................................................................................... 17

Modelo de rede .................................................................................................................................... 17

Modelo de processo de fluxo de trabalho.................................................................................. 17

Modelo BSD ........................................................................................................................................... 18

Modelo de armazenamento de dados corporativos .............................................................. 18

Modelo de acesso ao conhecimento: ........................................................................................... 19

BSD – Dominio de Sistema de Negócio............................................................................................ 20

Um Cenário para integração Organizacional ................................................................................ 21

Intercâmbio de Dados ....................................................................................................................... 24

<XML/>........................................................................................................................................................................ 25

História do XML........................................................................................................................................ 25

Vantagens da XML: ............................................................................................................................. 26

XML & ebXML 4

 e-Business

Linguagem XML ........................................................................................................................................ 26

Características do XML .......................................................................................................................... 27

Simplicidade ......................................................................................................................................... 27

Extensibilidade .................................................................................................................................... 28

Interoperabilidade ............................................................................................................................. 28

Abertura ................................................................................................................................................. 29

Experiência............................................................................................................................................ 29

As Principais Utilizações da XML ...................................................................................................... 30

Alguns Conceitos da XML ..................................................................................................................... 31

A Validação de Documentos XML ...................................................................................................... 33

DTD .......................................................................................................................................................... 33

XML Schema .......................................................................................................................................... 34

O que há em torno da xml .................................................................................................................... 35

XPath........................................................................................................................................................ 35

XPointer .................................................................................................................................................. 36

XInclude .................................................................................................................................................. 36

XQuery ..................................................................................................................................................... 37

XSL ............................................................................................................................................................ 37

APIS XML ................................................................................................................................................ 38

SAX............................................................................................................................................................ 38

DOM ......................................................................................................................................................... 38

<Troca de Documentos Electrónicos via XML /> ........................................................................................ 39

Conceitos Iniciais das Arquitecturas de Comunicação ............................................................. 39

Web Services ........................................................................................................................................ 39

SOAP ........................................................................................................................................................ 40

WSDL ....................................................................................................................................................... 41

XML & ebXML 5

 e-Business

UDDI ......................................................................................................................................................... 42

SOA ........................................................................................................................................................... 42

BPM .......................................................................................................................................................... 43

Outras tecnologias para troca de documentos electrónicos ................................................... 44

Arquivos Texto TXT (flat file) ........................................................................................................ 44

EDI ............................................................................................................................................................ 45

Técnicas de segurança na troca de documentos Electrónicos via xml ............................... 45

XML Signature ...................................................................................................................................... 46

XML Encryption ................................................................................................................................... 47

<ebXML />.................................................................................................................................................................. 48

Funcionamento e Conceitos de ebXML ........................................................................................... 48

Descrição do cenário apresentado:.............................................................................................. 49

Arquitectura de ebXML ......................................................................................................................... 50

Visão Operacional de ebXML .......................................................................................................... 51

Visão Funcional de ebXML .............................................................................................................. 51

Componentes principais ebXML ........................................................................................................ 52

Processos de Negócios ...................................................................................................................... 52

O Registo e o Repositório................................................................................................................. 53

Serviços de Mensagens ..................................................................................................................... 53

<Conclusão/> ............................................................................................................................................................ 54

<Referências Bibliográficas/> ............................................................................................................................ 55

<Recursos na Internet/> ...................................................................................................................................... 56

XML & ebXML 6

 e-Business

<LISTA DE SIGLAS E ABREVIATURAS/>

XML Extensible Markup Language Linguagem de Marcação Extensível

EAI Enterprise Application Integration - Integração de Aplicações Empresariais,
IOS Interorganizational Information System -Sistemas de Informações Inter-organizacionais
EFT Electronic Funds Transfer - Transferência Electrónica de Fundos.
COTS Commercial off-the-Shelf -Sistemas Pacotes.
CRM Corporate Resource Management – Gestão de Recursos de Equipas
BI Business Intelligence
ERP Enterprise Resource Planning - Sistemas Integrados de Gestão Empresarial
HTTP Hyper Text Markup Language
BSD Bussiness System Domain – Dominio de Sistema de Negócio
GML General Markup Language – Linguagem de Marcação Genérica
ISO International Organization for Standardization – Organização Internacional para Padronização)
SGML Standard Generalized Markup Language - Linguagem Padrão de Marcações Genéricas
HTML Hypertext Markup Language - Linguagem de Marcação de Hipertexto
W3C World Wide Web
DTD DocumentTtype Definition - Definição de Tipo de Documento
URI Uniform Resource Identifier
SQL Structure Query Languange
XSL Extensible Stylesheet Language – Linguagem de Estilo Estendida
CSS Cascading Style Sheets - Folhas de Estilo em Cascata
SAX Simple API for XML
DOM Document Object Model
TCP/IP Transfer Control Protocol/Internet Protocol
CORBA Common Object Request Broker Architecture
COM Component Object Model
SOAP Simple Object Access Protocol
WSDL Web Services Description Language - Linguagem de Definição de Serviços web
UDDI Universal Description, Discovery and Integration - Descrição, Descoberta e Integração Universais
SOA Service Oriented Architecture - Arquitectura Orientada a Serviços
BPM BusinessProcess Modeling – Modelagem de Processos de Negócio
BPEL Business Process Execution Language - Linguagem para a Execução de Processos de Negócio
BPMS Business Process Management System – Sistema de Modelagem de Processos de Negócio
EDI Electronic Data Interchange – Troca de Dados Electrónicos
ebXML Eletronic Business Extensible Markup Language
TA Technical Architecture
BPSS Business Process Specification Schema
RIM Registry Information Model
RS Registry services specification
CPPA Collaboration Protocol Profile and Agreement Specification
MS Message Service Specification
UML Unified Modeling Language
UMM Unified Modeling Methodology
CPA Collaboration Protocol Agreements
UN-EDIFACT United Nations/Electronic Data Interchange For Administration, Commerce and Transport

XML & ebXML 7

 e-Business

<RESUMO/>

A carência de integração dos sistemas de informação nas empresas é uma actual e

crescente preocupação com o constante aumento do número de plataformas e diferentes
arquitecturas. Os ambientes são cada vez mais heterogéneos e difíceis de integrar. A XML
(Extensible Markup Language), e todas as tecnologias que lhe são associadas, surgiu para
simplificar, promovendo um padrão de integração na troca de documentos electrónicos inter-
organizacionais, de forma textual, simples, estruturada, extensível, flexível, semanticamente
rica e com uma segurança adequada.
A XML não funciona sozinha, mas sim com um mundo de tecnologias à sua volta, uma
imensa quantidade de possibilidades, de maneiras mais fáceis e interessantes de trabalhar
com os dados e, definitivamente, uma forma avançada para tratar a informação, que é na
verdade o objectivo da informática em geral. A XML não é uma linguagem, e sim várias
linguagens, não é uma sintaxe, e sim várias e não é uma maneira inteiramente nova de
trabalhar, e sim uma maneira mais refinada que permite que todas as anteriores se possam
comunicar entre si sem problemas, já que os dados necessitam de sentido.
XML é interessante no mundo da Internet e do
e-bussiness, já que existem muitos sistemas distintos
que têm de se comunicar entre si, porém, como se
pode imaginar, interessa igualmente a todos os ramos
da informática e do tratamento de dados
promovendo resultados como a redução de custos e a
aceleração de processos.

Ilustração 1- Abstracto XML

(Fonte Google Imagens 2010)

Palavras-Chave: e-Business, XML, ebXML

XML & ebXML 8

 e-Business

<INTRODUÇÃO/>

Actualmente e de um modo geral, as empresas em todo o mundo necessitam de sistemas

de informação, quer utilizem tecnologias de informação, ou não. Todas as empresas têm
dados, desde o mais pequeno negócio, até a mais diversificada multinacional, e estes precisam
ser alimentados, processados, armazenados e apresentados, convertendo-se em informações
confiáveis, para atingir os objectivos estabelecidos. Assim são visíveis resultados mais
positivos desde produtos de alta qualidade, serviços entregues nos prazos, precisão no
armazenamento das informações, redução de custos, pequena carga de trabalho manual,
aumento da produtividade, até a tomadas de decisões mais direccionadas e acertadas.
As empresas não sobrevivem isoladas, precisam da troca de informações entre si, é por
isso que a integração dos sistemas inter-organizacionais se torna tão importante. Existem
muitos padrões diferentes, criam-se tecnologias que mais tarde caem em desuso, e mais
problemático é quando os sistemas não se conseguem comunicar entre si. Assim a integração
de sistemas é fundamental para a utilização e transformação dos dados. Os sistemas legados,
ainda com grande utilização nas empresas, necessitam trocar informações com os novos
sistemas, que por vezes têm arquitecturas diferentes.
Mesmo com todo este cenário de carência de integração, a troca de documentos
electrónicos é fundamental, por isso o intercâmbio de dados num ambiente EAI (enterprise
application integration - integração de aplicações empresariais), dentro da mesma empresa ou
empresas inter-organizacionais, é hoje mais fácil pela adopção de determinadas linguagens,
entre as quais o uso da XML, que se tornou a sintaxe preferida para troca de mensagens
empresariais.
Embora que os sistemas de informação contribuam para a solução de vários problemas
empresariais, a manipulação de um grande volume de informações, a complexidade nos
processamentos, a convivência com sistemas não integrados e a falta de padrões entre os
clientes e fornecedores envolvidos, torna-se um problema.
Assim a XML atende a uma falha que os tradicionais arquivos de texto têm, a de não
indicar o significado dos campos, nem mostrar se os dados fazem parte de uma ou mais

XML & ebXML 9

 e-Business

tabelas. Neste campo, a XML é capaz de representar os dados de uma maneira muito mais rica
e estruturada.
Basicamente a XML estrutura documentos de forma textual, com uma simplicidade
sintáctica e uma forte semântica contida na sua hierarquia. A sua aplicação à troca de dados, e
a interface com os utilizadores está bem definida. Existe a possibilidade de implementar
tecnologias de segurança nas trocas de documentos.
A população mundial cresce rapidamente, e junto com ela, a quantidade e diversidade
nos negócios, em especial os negócios que envolvem tecnologia. Assim a troca de documentos
deixou de ser um problema interno das organizações, mas uma procura de todo o mercado.
Embora as empresas necessitem de sistemas diferentes para atender a diferentes níveis
e funções empresariais, as vantagens que a integração trás dentro dessas empresas é
fundamental. Esta integração, se utilizada inadequadamente, poderá ser bastante complexa e
com altos gastos. No entanto, com a utilização de tecnologias como o XML, e com a internet, as
vantagens serão imensas.

Ilustração 2 – XML Abstracto

(Fonte: Google Imagens 2010)

XML & ebXML 10

 e-Business

<INTEGRAÇÃO DE SISTEMAS DE INFORMAÇÃO/>

SISTEMAS DE INFORMAÇÕES INTER-ORGANIZACIONAIS

Uma empresa classifica-se como um conjunto de pessoas, equipamentos, dados,

recursos, políticas e procedimentos que existem para suprir os seus produtos e serviços, com
o objectivo de obter lucro. (Resende & Abreu, 2003)
As aplicações dos sistemas no nível organizacional classificam-se em duas categorias:
aplicações localizadas e sistemas interdepartamentais.
A categoria de sistemas de informação de aplicações localizadas inclui sistemas pessoais
e de grupo. Estes sistemas têm como característica os utilizadores de um grupo de trabalho
conhecerem cada um dos membros pessoalmente. Envolvem poucos utilizadores, e estes
gerem poucos dados, às vezes simples e poucos heterogéneos. Envolve apenas subfunções da
empresa.
Já a proposta de sistemas interdepartamentais é integrar as actividades de diferentes
departamentos num só sistema de negócio, produzindo respostas apropriadas e coordenadas
para o meio ambiente da empresa. Permitem a integração de actividades de departamentos
separados de modo que os departamentos respondam de maneira consistente e coordenada.
Envolvem bases de dados centralizadas e partilhadas pelos departamentos, o que permite que
cada departamento registe resultados do seu trabalho. É aconselhada uma padronização
nestes sistemas, e um forte controle de mudanças, exigindo uma gestão dos sistemas
organizacionais. Os utilizadores envolvidos nestes sistemas, às vezes centenas ou milhares,
podem estar a distâncias continentais, e ainda assim utilizar um grande volume de dados
complicados e heterogéneos.
Tanto os sistemas localizados quanto os interdepartamentais, envolvem muito poucas
alterações nos processos de negócio. Eles dão unicamente suporte às actividades da empresa
do modo como elas já existiam anteriormente. (Zaidan, 2006)
Durante muitos anos, os sistemas de informação foram utilizados dentro das
organizações. A ligação de duas ou mais organizações era efectuada através dos sistemas de
informação inter-organizacionais, para suporte do fluxo de informações. Mesmo assim, eram

XML & ebXML 11

 e-Business

restritos a empresas de viagens, bancos e grandes corporações. (Turban, Rainer Jr, & Potter,
2005)
Os sistemas envolvendo duas ou mais organizações podem ser bastante complexos,
porém as vantagens são significativas com a internet e a XML. Como objectivo desses sistemas
temos o processamento eficiente de transacções, como a transmissão de pedidos, facturas e
pagamentos. Um IOS (interorganizational information system - sistemas de informações inter-
organizacionais) pode ser local ou global, voltado a uma única actividade (transferência de
fundos) ou a várias (facilitar as negociações, a comunicação e a colaboração).
A ligação entre organizações satisfaz duas pressões comerciais: redução de custos e
aumento da eficiência e oportunidade dos processos empresariais. Por consequência, com a
melhoria da qualidade, diminuiu-se o tempo de ciclo de realização das transacções
empresariais, eliminando o uso de papéis, e as ineficiências e custos associados, e acima de
tudo, eliminando erros.
Necessita-se de uma determinação prévia da relação entre cliente/fornecedor, com
expectativa de continuidade, e um acordo entre as organizações acerca da natureza e do
formato dos documentos a serem trocados. A rede de comunicação também precisa ser
conhecida por ambas as partes, onde um acordo prévio é estabelecido para a padronização.
(Zaidan, 2006)

TIPOS DE SISTEMAS INTER-ORGANIZACIONAIS :

 Sistemas de negociação B2B: Projectados para facilitar a negociação entre

parceiros comerciais. Estes podem estar no mesmo país ou em países diferentes.
 Sistemas globais: Ligam duas ou mais empresas, em dois ou mais países. Desde
empresas internacionais a empresas virtuais globais.
 EFT: (Eletronic funds transfer - transferência electrónica de fundos).
Transferência de dinheiro entre instituições financeiras.
 Groupware: Tecnologia para facilitar a colaboração entre organizações.
 Envio integrado de mensagens: Através de um único sistema de transmissão,
ocorre a remessa de correio electrónico e documentos de fax, entre organizações.
 Base de dados partilhados: Bases de dados que podem ser partilhados entre
parceiros comerciais, permitindo a actividade colaborativa.

XML & ebXML 12

 e-Business

 Sistemas que suportam corporações virtuais: Dois ou mais parceiros

comerciais em diferentes locais, partilhando custos e recursos para fornecer um
produto ou serviço.

SISTEMAS LEGADOS E COTS

Sistemas legados: ainda em grande uso nas organizações, são os sistemas criados com
uma tecnologia antiga, que não evoluíram com o passar dos anos. Com as mudanças das
tecnologias, estes sistemas tornaram-se desactualizados, de difícil operação e integração. A
evolução tecnológica contribuiu para a fragmentação de sistemas. A arquitectura
cliente/servidor muitas vezes piorou esta fragmentação. Os sistemas que utilizam uma
tecnologia mais antiga não podem ser implantados utilizando as tecnologias de ponta dos
sistemas modernos. Tem de ser feito Existirá um novo desenvolvimento que torna inviável a
actualização directa. Os sistemas legados incluem todas as aplicações existentes e que
precisem estar vinculadas a outros sistemas. As arquitecturas são as mais variadas e
abrangem um grande número de tecnologias. Com relação à integração dos sistemas legados,
os requisitos necessários são exclusivos.
COTS: (commercial off-the-shelf -Sistemas de Pacotes). São sistemas comerciais que são
comprados nas prateleiras das lojas de venda de programas de computador. Num primeiro
momento os COTS podem representar uma redução de custos de aquisição e manutenção.
Não é recomendável que sejam feitas alterações nem extensões para personalizar os
COTS, evitando trabalho adicional para cada nova versão, comprometendo a confiabilidade.
(CUMMINS, 2002)

EAI – INTEGRAÇÃO DE APLICAÇÕES ORGANIZACIONAIS

O aparecimento de EAI (enterprise application integration - integração de aplicações

empresariais) surgiu pela necessidade de integrar aplicações, como os COTS. E com o
aparecimento de várias aplicações específicas de negócio, como fabricação, pessoal,
contabilidade, etc., a necessidade de integração aos sistemas legados e COTS era eminente.
EAI é a prática de vinculação destes sistemas.
A abordagem básica é a transferência de dados store-and-forward (armazenar e mandar)
entre sistemas. Também são utilizadas outras tecnologias, como fila de espera de mensagens.
EAI pode incorporar estes recursos, fornecendo adaptadores para várias aplicações de

XML & ebXML 13

 e-Business

negócio, que fazem a ligação com as filas de mensagens e realizam algumas transformações
nos dados. Os produtos EAI também podem fornecer ferramentas e componentes para
facilitar a implementação de adaptadores a sistemas legados. Ainda que novos sistemas sejam
adquiridos e desenvolvidos pelas organizações, sempre haverá sistemas legados a integrar.
(CUMMINS, 2002)
A implementação de EAI é um início de um processo em melhoria progressiva e não uma
transformação única. Os detalhes da arquitectura, durante o processo de implementação,
poderão estar em mudança contínua. As vantagens serão conhecidas quando a sinergia de
várias aplicações começarem a aparecer. A seguir temos alguns factores de sucesso para uma
implantação de sucesso da EAI: (Zaidan, 2006)
 Visão da integração partilhada com todos da empresa, inclusive o alto escalão
 Compromisso com os padrões
 Empresas orientadas ao serviço para concretizarem as suas responsabilidades
empresariais
 Infra-estrutura partilhada para dar suporte a todas as aplicações
 Conhecimento de dados acessíveis podem ser acedidos a qualquer momento e de
qualquer parte que seja necessário, para dar suporte às necessidades comerciais
do alto escalão de gestão para operadores de produção. Os dados deverão ser
comunicados entre sistemas em tempo útil, sem a necessidade de interpretação
ou intervenção humana.

ESTRATÉGIA DE INTEGRAÇÃO

A integração empresarial fará com que as empresas dependam mais de seus sistemas,
pois seus processos estarão mais automatizados, as funções de negócio estarão mais
dinâmicas. Para tal, como estratégia de integração empresarial, devem ser utilizadas
economias de escala. Não basta simplesmente interligar sistemas, são necessárias várias
coisas entre elas: tornar a empresa mais produtiva; ir em busca de novas soluções; minimizar
as falhas; eliminar esforços repetitivos; reduzir a complexidade; aproveitar ao máximo os
conhecimentos dos profissionais treinados. Uma empresa bem integrada deverá ter um custo
menor para operar e adaptar-se-á às necessidades comerciais em constante mudança.
(Zaidan, 2006)

XML & ebXML 14

 e-Business

Existem várias oportunidades importantes que devem ser observadas para obtenção de
economia de escala: (CUMMINS, 2002)
 Padrões: os padrões são os factores que mais contribuem para a economia de
escala. Eles resultam da partilha de recursos, que podem ser: materiais, pessoas,
equipamentos, sistemas ou instalações. Os padrões para integração empresarial
devem-se concentrar nos dados, nas interfaces e nas práticas. Se não forem
definidos padrões para troca de dados, estes não estarão prontos para serem
utilizados para a sua finalidade, o que fará com que exista possibilidade de
incompatibilidade, originando resultados incorrectos, e gasto e esforço
desnecessário para manter programas de conversão. Os padrões de interface
incorporam especificações de dados e incluem: modo de comunicação –
assíncrono ou síncrono; protocolo de comunicação; sequência e forma de troca
de informação; formato e significado de entrada e saídas.
 Reutilização de software: a utilização de um componente ou sistema de
software para solucionar o mesmo problema num contexto distinto. É necessária
que a sua utilização seja feita mais de uma vez para que se possa obter economia
de escala.
 Infra-estrutura comum: é o complexo de computadores, redes, softwares e
serviços associados que dão suporte à operação e à interconexão de muitos
sistemas, visando a reduzir a carga e promover a sinergia entre os sistemas. Uma
infra-estrutura deste tipo pode gerar economias substanciais de escala.
 Operações de sistemas consolidados: tradicionalmente, as aplicações
empresariais eram executadas em centros de dados centralizados. Estes centros
de dados permitiam a partilha do computador, cujo custo era elevado, para obter
grande utilização. Com a tecnologia dos microprocessadores, tem-se uma
alternativa com um custo menor, possibilitando a implantação mais rápida e
sistemas mais amistosos. O foco mudou de informática empresarial para sistemas
cliente/servidor. Mas, a internet e o comércio electrónico reverteram esta
tendência de redução de custo. Sistemas que precisam operar 24 horas, 7 dias
por semana, interligados, com segurança, disputaram profissionais cada vez mais
valorizados. Os microcomputadores passaram a desempenhar papéis específicos:
servidores de bases de dados, servidores de directórios, servidores de segurança,

XML & ebXML 15

 e-Business

servidores Web, entre outros. Neste caso, a economia provém da consolidação de

serviços, tanto operacionais quanto de sistemas. Algumas economias de escalas
serão obtidas em detrimento da flexibilidade.

DISCIPLINAS DO CONHECIMENTO PARA INTEGRAÇÃO

Segundo alguns autores as disciplinas do conhecimento necessárias para execução da

integração de sistemas corporativos são: (PARREIRAS, 2006)
 Gestão de projectos: Identificar os riscos pertinentes na integração de sistemas,
fundamentado nas áreas de gestão de projectos.
 Segurança de sistemas: Utilizar os conceitos de segurança para a
implementação de sistemas integrados.
 Aplicações baseadas em componentes: Abordar conceitos de objectos
distribuídos.
 Desenvolvimento de documentos estruturados: Oferecer conhecimento
aprofundado das principais tecnologias derivadas da XML.
 Gestão de fluxo de trabalho: Aborda os aspectos da gestão de fluxo de trabalho.
 Sistemas avançados de gestão: Apresentar conceitos que envolvem os temas,
processos para implantação, das opções disponíveis, como ERP (Enterprise
Resource Planning - Sistemas Integrados de Gestão Empresarial) CRM (Corporate
Resource Management – Gestão de Recursos de Equipes), Data Warehouse e BI
(business intelligence).
 Serviços Web: Apresentar o modelo de integração por serviços web e trabalhar
nessa arquitectura.
 Integração de bases de dados: Utilizar técnicas, métodos e ferramentas para a
integração de bases de dados heterogéneos.
 Inteligência empresarial: Fornecer uma visão estratégica da organização e
abordar a inteligência competitiva, gestão do conhecimento e capital intelectual.
 Modelo e ferramentas de integração: Apresentar os diversos modelos de
integração disponíveis, como: modelo de infra-estrutura de integração, modelo
de rede, modelo de armazenamento de dados corporativos, serviços de
mensagens e portais corporativos.

XML & ebXML 16

 e-Business

MODELOS DE INTEGRAÇÃO

Modelo da infra-estrutura de integração entende-se como o conjunto de recursos

partilhados, que permitem o trabalho em conjunto de vários sistemas
É necessário definir a arquitectura de integração empresarial com base nas tecnologias
actuais, tendo em conta as tendências do sector.
É possível o suporte a integração de sistemas, mesmo em arquitecturas distintas.
A empresa incorporará muitos sistemas. Esses sistemas terão diversas formas e
tamanhos. Algumas serão aplicações legadas, algumas serão aplicações COTS
(commercial-off-the-shelf) adquiridas e outras serão aplicações personalizadas
desenvolvidas para satisfazer as necessidades específicas. Ainda que esses sistemas
possam ser desenvolvidos independentemente, existe a possibilidade de fornecer recursos
comuns que dêem suporte à sua integração e obtenham economias de escala. Esses
recursos comuns fornecerão flexibilidade na operação global do negócio, reduzirão o
custo de desenvolvimento e implementação de novas aplicações e possibilitarão o uso de
diversas tecnologias para a solução de problemas de negócio específicos.
(CUMMINS, 2002)

MODELO DE REDE

Os elementos corporativos devem ser vinculados através de redes. O modelo de rede é

subdividido em três domínios: sistemas internos, aplicações Web públicas e a internet
pública. Como exemplos de categorias, numa perspectiva de rede, encaixando nestes
domínios, podemos citar: recursos de internet, serviços de troca de mensagens, serviço de
segurança, troca de mensagens HTTP (hyper text markup language), firewall, servidor de
acesso remoto.

MODELO DE PROCESSO DE FLUXO DE TRABALHO

Segundo (CUMMINS, 2002), os processos de negócios executam acções no nível da

empresa, como preenchimento de um pedido de cliente, e alguns processos que automatizam
processos triviais, como aprovação de uma passagem. Os sistemas de gestão de fluxo de
trabalho que automatizam tais processos de negócio. Os componentes desse modelo são:
definição do processo, instância do processo, actividade, solicitador, lista de trabalho pessoal,
gerente do processo e interoperabilidade do processo.

XML & ebXML 17

 e-Business

MODELO BSD

O modelo BSD está num nível central da hierarquia de sistemas de negócio. Ele está
presente na integração empresarial no comércio electrónico e incorpora processos, aplicações
e componentes de negócio. O BSD pode incluir aplicações legadas, COTS ou aplicações para
novas funções de negócio.

MODELO DE ARMAZENAMENTO DE DADOS CORPORATIVOS

Segundo (CUMMINS, 2002), o modelo de armazenamento de dados corporativos é a base

para observação do estado actual da empresa e também as actividades históricas. Dá suporte
à monitorização, planeamento e tomada de decisão. A figura abaixo mostra os componentes
desse modelo.

Esquema 1 Modelo de armazenamento de dados corporativos (CUMMINS, 2002)

Aplicações de negócio: são SW que realizam o negócio, e contêm as informações mais

actuais do estado da empresa.
 Gestão de documentos: Controla arquivos que contêm documentos ou estruturas
mais complexas como especificações de produtos ou modelos.
 Armazenamento de dados operacionais: Oferece acesso a dados relativamente
actualizados no que se refere ao estado das operações de negócios em lugar do
acesso directo das aplicações. Pode reunir dados de diversas aplicações de modo a
oferecer uma visão integrada da situação actual da empresa. Pode ser requerida a
traduções e limpeza de dados, para garantir a consistência de dados.

XML & ebXML 18

 e-Business

 Base de dados corporativos principais: Dados relativamente estáveis podem ser

partilhados por vários sectores da empresa ou replicados para outros locais, a fim
de evitar o overhead e evitar falha. Neste caso uma base de dados será definida como
corporativo principal.
 Arquivos e documentos principais: Esses documentos serão expressos em XML e
deverão preservar o mesmo formato em que foram assinados.
 Metadados: Dentro deste contexto, há dois tipos de metadados: o técnico e o
comercial. Os técnicos definem tipos e estruturas de dados armazenados, com o
objectivo da gestão de dados. Já os metadados comerciais fornecem informações
sobre a origem, precisão e confiabilidade dos dados.
 Data warehouses (armazém de dados): Armazena o acúmulo de dados históricos.
Pode conter dados por muitos anos, com tamanho de armazenamento muito grande.
Normalmente depois do fim das transacções comerciais na aplicação ou no
armazenamento de dados operacionais, elas são transferidas para o warehouse.
 Data marts: A análise de dados históricos pode envolver o exame e reestruturação
de dados de várias maneiras. A análise normalmente não é feita a partir do data
warehouse. Os dados seleccionados são extraídos periodicamente a partir de um
warehouse para vários data marts. (Zaidan, 2006)

MODELO DE ACESSO AO CONHECIMENTO :

Conhecimento dentro de uma empresas, são as informações sobre a empresa e suas

tecnologias. Podem ser armazenadas em bases de dados. Muitas vezes não são armazenadas
de forma estruturada, e são mantidas nas memórias dos trabalhadores. O grande desafio da
gestão do conhecimento é a captura e preservação do conhecimento corporativo, de modo
que ele fique acessível e não se perca quando houver apagamento de memória ou saída de
pessoas da empresa. (CUMMINS, 2002)

XML & ebXML 19

 e-Business

BSD – DOMINIO DE SISTEMA DE NEGÓCIO

Os BSDs são o local em que o verdadeiro trabalho de informática da empresa

acorre. É neles que os dados são capturados, os cálculos são feitos, os registos são
actualizados e os resultados são produzidos. Muitas aplicações actuais podem ser
caracterizadas como BSDs. Em geral, essas aplicações empresariais desempenham
funções de negócio primárias, como contabilidade, gestão de recursos humanos,
planeamento de produção, agendamento e controle. Normalmente, esses sistemas são
altamente integrados entre si e parcialmente integrados com outras aplicações da
empresa.
(CUMMINS, 2002)
Classificam-se os BSDs como um nível central da hierarquia de sistemas de negócio. Ele
está presente na integração empresarial, que fornece um ambiente comum de integração e
suporte aos BSDs. Os BSDs podem ser aplicações legadas, COTS ou aplicações para novas
funções de negócio. Um BSD pode ser um sistema bem simples, mas espera-se que inclua
processos de negócio e que coordenem os diversos segmentos da empresa.
Para dar suporte à infra-estrutura empresarial, de acordo com (CUMMINS, 2002), os
seguintes componentes relacionam-se com o BSD:
 Intranet: Principal meio que os utilizadores, outros BSDs e serviços de infra-
estrutura, dispõem para comunicar com outros BSDs.
 Computadores pessoais: São uma plataforma para interfaces de utilizadores e
BSDs.
 Troca de mensagens: As mensagens são transformadas, conforme necessário, e são
distribuídas para os destinatários.
 Gestão de sistemas: A gestão de sistemas da infra-estrutura deve coordenar a
resolução de problemas e alterações que afectam os BSDs.
 Segurança: O BSD usará certificados digitais.
 Organização: O BSD deve basear-se no directório organizacional da infra-estrutura
para poder fazer uma representação actual da empresa e dos seus funcionários.
 Arquivo: Um BSD não pode ter documentos electrónicos para serem arquivados; do
contrário, poderia arquivá-los localmente.
 Repositório de metadados: Nem todos BSDs necessitarão de metadados. Se forem
usados com muita frequência, pode ser utilizados data warehouses.
 Gestão do conhecimento: Um BSD deverá fornecer mecanismos para captura de
conhecimento, como parte do processo de negócio, e torná-los disponíveis.

XML & ebXML 20

 e-Business

 Portais: Os utilizadores externos (por exemplo, clientes, colaboradores e

investidores), os BSDs deverão dar acesso em portais apropriados.
 B2B: Deverá ser utilizado o serviço de troca de mensagens da infra-estrutura. Para
fins de compatibilidade, aconselha-se que as mensagens deverão estar no formato
XML (Zaidan, 2006)

UM CENÁRIO PARA INTEGRAÇÃO ORGANIZACIONAL

Com o intuito de abandonar a abstracção da integração empresarial, e vincular os

conceitos com o mundo real, e segundo (CUMMINS, 2002), conforme a figura abaixo é
demonstrado um cenário de negócios de uma empresa dedicada a vendas online. Um cliente
acede ao portal de vendas da empresa, selecciona um produto para a compra. O portal de
vendas é uma aplicação acessível publicamente que possui informações sobre produtos e
preços, e onde são feitas encomendas. O portal não é vinculado a outras aplicações devido ao
risco de intrusos comprometerem a segurança dos sistemas corporativos. O pedido é
preenchido e comunicado para a BSD de processamento de pedidos. Essa BSD é interna da
empresa. A BSD de processamento de pedidos valida o pedido e envia uma solicitação para a
BSD de warehouse. O pedido que o cliente recebe é um contrato de compra. A BSD de
warehouse verifica o stock e envia uma resposta que está disponível. O funcionário prepara
para a encomenda para o envio através de uma transportadora. O status do pedido poderá ser
alterado. O BSD de processamento de pedidos, quando recebe o aviso da encomenda, enviará
ao serviço de cobrança externa à empresa para a factura. Isto é feito através da internet
pública. A cobrança externa notifica o sector de contas a receber. O cliente poderá entrar em
contacto e indagar sobre o status do pedido. O pedido também poderá ser rastreado, para ver
mais detalhes. Neste caso acima, o produto encontra-se em stock, mas, se o produto estiver
esgotado, este deverá ser solicitado ao fornecedor, onde a BSD de warehouse inicia uma
solicitação de compra.

XML & ebXML 21

 e-Business

Quando o processamento do pedido se completar, a BSD de processamento registará a

transacção como completa, mantendo os históricos para análise futura. (Zaidan, 2006)

Esquema 2- Modelo de armazenamento de dados corporativos (CUMMINS, 2002)

Muitos requisitos de integração empresarial estão implícitos neste exemplo, assim como
uma infra-estrutura de integração. Os mais importantes são:
 Mensagens entre BSDs: os BSDs podem se comunicar entre si. Os links entre
sistemas foram-se desenvolvendo conforme a necessidade, variando os recursos e
tecnologias.
 Solicitações e eventos: a comunicação por solicitação é feita através do
preenchimento e processamento do pedido e requerem uma resposta. Os eventos
são enviados para fornecer informações sobre alterações de estado.

XML & ebXML 22

 e-Business

 Comunicações confiáveis: as comunicações, na forma de solicitações ou eventos,

deverão se confiáveis. Caso os eventos se percam, o cliente não poderá ser cobrado,
e as facturas dos fornecedores poderão não ser pagas.
 Terciarização potencial: o serviço de cobrança representa uma terciarização em
potencial, deixando de ser, tradicionalmente, interna das organizações.
 Integração na cadeia de abastecimento: fica claro a necessidade de incluir
fornecedores e transportadoras no design da integração empresarial. Uma boa
integração com fornecedores permitirá que a empresa trabalhe com stocks
reduzidos, sem a necessidade de armazenar produtos.
 Gestão de relacionamento com clientes: a interface com o cliente é um elemento
fundamental para a sua satisfação. O processo deverá ser agilizado, reconhecendo os
clientes antigos, não pedindo novamente dados já registados. O cliente poderá
conferir o status do pedido ou da sua conta. Uma base de dados de gestão de clientes
torna-se imprescindível.
 Informações de gestão: inclui-se análise de desempenho, das tendências e dos
relacionamentos. Essa integração de informações requer uma definição consistente
dos dados.
 Registos legais: a troca de registos com entidades externas representa os
documentos legais. Por exemplo, o pedido do cliente e do fornecedor, representam
os contratos. Estes documentos podem tornar-se assunto de litígio. São necessárias
assinaturas electrónicas para estabelecer a validade e os documentos devem ser
preservados na forma original. (Zaidan, 2006)

Ilustração 3 – Abstracto Integração

(Fonte: Google Imagens 2010)

XML & ebXML 23

 e-Business

INTERCÂMBIO DE DADOS

A arquitectura de integração empresarial depende da adopção e da aplicação de

padrões. Os melhores padrões são os definidos por um consórcio, que representa um grupo
distinto de participantes, e não uma única empresa. Para demonstrar que a XML é o padrão
mais aceitável para a troca de dados.
A XML (Extensible Markup Language) está a tornar-se rapidamente no formato
dominante para o intercâmbio de dados entre sistemas, sejam trocas EAI e B2B. A
utilização de documentos XML fornece uma melhor flexibilidade e um formato que pode
ser trocado facilmente na Internet e através de firewalls usando o protocolo HTTP
(HyperText Transfer Protocol). Além disso, existem funções comuns de software
disponíveis para a manipulação e a transformação de documentos XML
(CUMMINS, 2002)
Várias empresas de padronização estão definir especificações com base na XML, para
diversos tipos de troca de documentos electrónicos. Se as organizações não explorarem estes
padrões, a longo prazo podem-se ter custos adicionais e flexibilidade reduzida.(Zaidan, 2006)

Ilustração 4 – Abstracto XML

(Fonte: Google Imagens 2010)

XML & ebXML 24

 e-Business

<XML/>

HISTÓRIA DO XML

A história da XML foi iniciada nos anos 70, quando a IBM inventou a linguagem GML
(General Markup Language – linguagem de marcação genérica). Esta surgiu com a necessidade
da empresa em armazenar uma grande quantidade de informações. Com a GML, a IBM
conseguiria classificar e processar rapidamente todos os documentos. Esta linguagem atraiu a
ISO (International Organization for Standardization – organização internacional para
padronização), uma entidade que se encarrega de normalizar processos, e em 1986, esta
linguagem foi padronizada. Foi então criada a SGML (Standard Generalized Markup Language -
Linguagem Padrão de Marcações Genéricas), que era na realidade a GML, mas com padrão. A
SMGL é uma linguagem poderosa, com bastante adaptabilidade.
Em 1989, foi criado o HTML (Hypertext Markup Language - linguagem de marcação de
hipertexto). Linguagem para a para o âmbito da rede Internet. A HTML, derivada da SGML,
teve uma rápida aceitação, sendo rapidamente adoptada pela comunidade.
Em 1994, surge uma entidade chamada W3C (World Wide Web). Este consórcio
formalizou as regras para o HTML, para que estas se tornassem um padrão. Mesmo assim, o
HTML não cumpriu tudo o que foi proposto e planeado para a Internet, e cresceu de uma
forma descontrolada e desordenada. O HTML continua em constante evolução, contudo, não
consegue suprir tudo que as aplicações necessitam. Assim surge, em 1996, a XML.
Quando foi criada, pensou-se que o propósito da XML seria de substituição da HTML.
Este pensamento errado estendeu-se em meios desinformados, até à actualidade. A XML
pretendia solucionar problemas que o HTML não resolvia. (Zaidan, 2006)
 No HTML, o conteúdo das páginas mistura-se com as tags e estilos que se deseja
apresentar;
 O HTML, não permite a partilha de informações, seja entre computadores,
telefones móveis ou dispositivos móveis portáteis;
 No HTML, a apresentação depende do visor.

XML & ebXML 25

 e-Business

VANTAGENS DA XML:

 XML é para estruturar dados;

 XML parece-se com o HTML;
 XML é texto, mas não é para se ler;
 XML é prolixo de propósito;
 XML é uma família de tecnologias;
 XML é modular; Ilustração 5- Abstracto XML
 XML é a base da Web Semântica; (Fonte: Google Imagens 2010)

 XML é livre de licenças, independente de plataforma e é bem suportada.

LINGUAGEM XML

A linguagem XML (Extensible Markup Language) é uma tecnologia muito simples que
utiliza outras tecnologias que a complementam e a fazem muito maior e com possibilidades
muito mais amplas, ou seja XML é na realidade uma linguagem de marcação de dados (Meta-
Markup Language) que fornece um formato para descrever dados estruturados. Isso facilita
declarações mais precisas do conteúdo e resultados mais significativos de busca através de
múltiplas plataformas. No futuro o XML também vai permitir o surgimento de uma nova
geração de aplicações de manipulação e visualização de dados via internet.
O XML permite a definição de um número infinito de tags. Enquanto no HTML, se as tags
podem ser usadas para definir a formatação de caracteres e parágrafos, o XML provê um
sistema para criar tags para dados estruturados.
Um elemento XML pode ter dados declarados como sendo preços de venda, taxas de
preço, um título de livro, a quantidade de chuva, ou qualquer outro tipo de elemento de dado.
Como as tags XML são adoptadas por intranets de organizações, e também via Internet,
haverá uma correspondente habilidade em manipular e procurar por dados
independentemente das aplicações onde os quais são encontrados. Uma vez que o dado foi
encontrado, ele pode ser distribuído pela rede e apresentado num browser como o Internet
Explorer de várias formas possíveis, ou então esse dado pode ser transferido para outras
aplicações para futuro processamento e visualização.
XML, com todas as tecnologias relacionadas, representa uma maneira distinta de fazer as
coisas, mais avançada que consiste em permitir partilhar os dados com os quais se trabalha a

XML & ebXML 26

 e-Business

todos os níveis, por todas as aplicações e suportes. Sendo assim, o XML tem um papel
importantíssimo no mundo actual, que tende à globalização e à compatibilidade entre os
sistemas, já que é a tecnologia que permitirá partilhar a informação de uma maneira segura,
confiável e fácil. Além disso, XML permite ao programador e aos suportes dedicação total às
tarefas importantes como o trabalho com os dados, já que as tarefas trabalhosas como a
validação dos dados ou o percorrer as estruturas fica a cargo da linguagem e está especificada
pelo padrão, para que o programador não tenha que se preocupar com isso.
Vemos assim que XML não está só, e sim inserido num mundo de tecnologias á sua volta,
com imensas possibilidades, maneiras mais fáceis e interessantes de trabalhar com os dados
e, definitivamente, de forma avançada na hora de tratar a informação, que é na realidade o
objectivo da informática em geral. XML, ou melhor dizendo, o mundo XML não é uma
linguagem, e sim várias linguagens, não é uma sintaxe, e sim várias e não é uma maneira
totalmente nova de trabalhar, e sim uma maneira mais refinada que permitirá que todas as
anteriores se possam comunicar entre si sem problemas, já que os dados necessitam de
sentido.

CARACTERÍSTICAS DO XML

SIMPLICIDADE

A linguagem XML fornece tanto a programadores como autores de documentos um

ambiente do ponto de vista informático. O rígido conjunto de regras da XML ajuda a tornar os
documentos mais fáceis de serem lidos quer seja por humanos, quer seja por máquinas. A
sintaxe de documentos em XML contém um conjunto de regras relativamente pequeno,
possibilitando as pessoas que desenvolvem aplicações, uma simples iniciação na linguagem.
DTDs (definição de tipo de documento) podem ser desenvolvidos através de processos
padronizados, impostos por especialistas, ou através da experiência, baseada em estruturas
de documentos que funcionam bem.
Um documento em XML é construído sobre um conjunto principal de estruturas
amarradas. Enquanto estas estruturas podem crescer em graus de complexidade como
camadas, e camadas de detalhe podem ser adicionadas, os mecanismos por detrás destas

XML & ebXML 27

 e-Business

estruturas requerem muito pouco esforço de implementação, sejam por parte de autores ou
por parte de programadores.

EXTENSIBILIDADE

A linguagem XML é extensível de duas formas. Primeiro, ela permite aos programadores
a criação de seus próprios DTDs, através da criação de conjuntos marcas “extensíveis” que
podem ser usadas para múltiplas aplicações. Segundo, a XML propriamente dita está a ser
estendida com uma série de padrões adicionais que adicionam propriedades de estilo, link-
agem e referenciação ao conjunto básico de capacidades desta linguagem.
A criação de DTDs próprios é o que os criadores da XML tinham como ideia principal
quando lhe chamaram de “Linguagem de Marcação Extensível”. A XML é, portanto, uma
metalinguagem, um conjunto de regras que pode ser utilizado para a criação de conjuntos de
regras para documentos. De certo modo, não há, na verdade, um documento XML; todos os
documentos que utilizam a sintaxe XML estão é a utilizar aplicações da XML, com conjuntos de
marcas escolhidas pelos seus criadores para aquele documento em particular. A facilidade
proporcionada pela XML para a criação de DTDs dá aos construtores de padrão um conjunto
de ferramentas para especificar como as estruturas de um documento devem aparecer no
documento, tornando mais fácil a definição do conjunto de estruturas. Estas estruturas podem
ser usadas como ferramentas da XML para a criação, interpretação e processamento, e usadas
pelas aplicações como um guia para os dados que estas devem aceitar.

INTEROPERABILIDADE

A XML pode ser utilizada sobre uma grande variedade de plataformas e interpretada por
uma grande variedade de ferramentas. Devido ao comportamento consistente das estruturas
de documentos, os navegadores que as interpretam podem ser desenvolvidos com um custo
relativamente baixo para um grande número de linguagens. A XML suporta um grande
número de padrões para a codificação de caracteres, permitindo-lhe ser usada num vasto
leque de diferentes ambientes. A XML também é um excelente complemento do Java, e um
considerável número de desenvolvimentos para a XML foi mesmo feito através de Java.

XML & ebXML 28

 e-Business

ABERTURA

Embora tenham havido algumas dúvidas a respeito do processo utilizado para a criação
da XML, o processo padrão é completamente aberto e está total e gratuitamente disponível na
Web. Os membros do W3C tiveram pronto acesso ao processo padrão, e uma vez que este foi
completado, os resultados tornaram-se públicos. Mais, todos os avanços obtidos pelo XML
Working Group do W3C costumam ser levados a público, possibilitando o acompanhamento
de seus progressos.
Os documentos em XML são consideravelmente mais abertos que suas contrapartes
binárias. Qualquer um é capaz de interpretar um documento XML do tipo “well-formed”, e sua
validação requer apenas que seja providenciado um DTD adequado. Enquanto as companhias
podem criar um documento XML que se comporte de maneira específica no que tange as suas
aplicações, os dados nele incluídos estão disponíveis para quaisquer outras aplicações. Os
programadores podem criar DTD’s obscuros ou mesmo criptógrafar os dados de uma forma
exclusiva, no entanto dessa forma abdicam de um dos maiores benefícios da utilização da
XML. Esta linguagem não impede a criação de formatos exclusivos, mas a sua abertura é uma
de suas principais vantagens. Os programadores podem assim dividir tarefas entre várias
ferramentas, possivelmente até de diferentes concorrentes, permitindo assim que estes
operem no mesmo conjunto de estruturação de dados.

EXPERIÊNCIA

O desenvolvimento de aplicações de sucesso para a XML requer um conhecimento na

modelação de um novo conjunto de ferramentas. As especificações iniciais da XML foram
criadas em grande parte pelos integrantes da chamada comunidade SGML e, deste modo, já se
pode dizer que existe um grande grupo de especialistas em XML. Mais, as companhias que
trabalham com SGML têm vindo a procurar adaptar, através da simplificação, as suas
ferramentas permitindo a utilização da XML.

XML & ebXML 29

 e-Business

AS PRINCIPAIS UTILIZAÇÕES DA XML

A troca de documentos electrónicos e o intercâmbio de dados com formato neutro, na

mesma empresa ou empresas inter-organizacionais, utiliza a XML como a sintaxe preferida
para troca de mensagens empresariais.
Basicamente, onde existe a necessidade de troca de documentos electrónicos, de maneira a
automatizar os processos de negócio entre duas ou mais organizações, utiliza-se a XML.
Assim as principais possibilidades de utilizações da XML são: (FURGERI, 2001)
 A troca de dados devido à grande diversidade de computadores, sobre
diferentes sistemas, em diferentes plataformas, sistemas e bases de dados que
contêm dados em formatos incompatíveis. Pelo facto do conteúdo básico do
documento XML ser apenas texto, esta linguagem apresenta-se como a principal
possibilidade de computadores diferentes trocarem dados pela internet. Neste
caso, basta converter o formato da base de dados em texto, seguindo regras
estabelecidas nos documentos XML.
 A melhoria da busca de informações: a busca na Internet, com um grande
número de páginas, sem padronização, é um sério problema. Utilizando a XML,
tem-se um serviço de busca mais inteligente, evitando a procura dentro dos
documentos HTML, onde estão misturados a apresentação e o conteúdo.
 A automatização da Web: devido ao facto da XML permitir a definição dos
marcadores, os dados armazenados têm significado, permitindo linguagens, como
o Java, manipular seu conteúdo, facilitando a pesquisa, inclusão, alteração e
exclusão de dados.
 A utilização em conjunto com documentos HTML: desta forma podem-se
interligar a apresentação (contida nos documentos HTML), com os dados
contidos nos documentos XML. Com isto, a mudança nos dados, no arquivo XML,
reflectirá directamente sobre o HTML, eliminando a necessidade da sua
actualização.
 O desenvolvimento de catálogos: catálogos são documentos formados por
conteúdo texto, altamente estruturados, mas que proporcionam um fácil
tratamento por parte da XML. Estes podem ter várias dimensões e serem
constituídos por texto, elementos gráficos ou imagens. Se escrito em linguagem
XML & ebXML 30
 e-Business

XML, os catálogos poderão ter uma grande variedade de métodos de acesso e

formas de apresentação, uma vez que diversas ferramentas podem analisar o seu
conteúdo e apresenta-lo. Um catálogo on-line, escrito em XML, é uma das partes
mais importantes de um site, pois contém informações que os clientes desejam
como produtos, fotos e preços.
 A automação da cadeia de suprimentos: enquanto os ERP´s realizam a
integração total dos sectores de uma empresa, os sistemas desenvolvidos a partir
da XML realizam a integração da empresa. A automação do processamento de
compra, maior flexibilidade na escolha de fornecedores e mudança na cadeia de
suprimentos.

ALGUNS CONCEITOS DA XML

De acordo com alguns autores uma das principais regras de sintaxe da linguagem XML é
a da boa formatação. Um documento bem formatado significa que é sintacticamente correcto.
XML é uma linguagem de marcação não definida o que possibilita ao autor do documento
projectar sua própria marcação. A especificação do XML define um dialecto simples do SGML,
permitindo o processamento dos documentos na Internet e utilizando-se de recursos
inexistentes no HTML. Torna-se assim simples a transmissão e partilha desses documentos
via Internet. (Daum & Merten, 2002)
Elementos são identificáveis dentro de um documento com tags delimitadoras de início
e fim. Mas, de maneira diferente do HTML, uma tag de início precisa sempre ter uma de fim.
XML e é case sensitive.
Alguns conceitos da linguagem XML: (PINHEIRO, 2003)
 Árvore: toda estrutura da sintaxe XML gira em torno de uma árvore. Um
documento XML tem um, e apenas um, elemento raiz, e dentro deste, um número
indefinido de outros elementos, distribuídos em níveis, também indefinidos.
 Elemento: é cada um dos componentes de um documento. Deve ser delimitado
com tags de início e fim, e possuir um conteúdo.
 Nomes: os nomes das tags são livres, portanto, não existem nomes predefinidos.
Cada elemento deve possuir um nome.

XML & ebXML 31

 e-Business

 Tags: em XML são as marcações propriamente ditas, portanto, delimitam um

elemento, e deve ter um nome de acordo com as regras estabelecidas. Como no
HTML, as tags são sempre delimitadas pelos caracteres de abertura de fecho “<” e
“>”.
 Conteúdo de um elemento: é a porção de dados delimitados, peças ou
marcações de início e fim. Porém, há uma excepção para elementos vazios, que
pode ser fechado com a própria tag de abertura, com o carácter “/” antes do
delimitador “>”. O conteúdo do elemento pode conter qualquer coisa, inclusive
outros elementos, criando o conceito recursivo, que gera uma estrutura em
árvore.
 Atributos: são dados adicionais que podem ser atribuídos a um determinado
elemento. São fornecidos na forma de pares: nome e valor, separados por um
carácter “=”. Os nomes de atributos seguem as mesmas regras dos nomes dos
elementos. Os valores são delimitados por aspas (“) ou apóstrofes (‘).
 Primeira linha do documento: precisa conter uma declaração XML, na qual
identifica um documento XML, e determina a versão da XML, bem como,
opcionalmente, qual o conjunto de caracteres padrão.
 Comentários: o que estiver inserido entre os marcadores “<!--" e “-->” são
considerados comentários, e serão ignorados pelo processador XML.
 Outros elementos: há ainda outros elementos, como secções CDATA.

Ilustração 6 - Exemplo de um documento XML

XML & ebXML 32

 e-Business

A VALIDAÇÃO DE DOCUMENTOS XML

Um documento XML que atende as regras de sintaxe é um documento bem formado.

Porém, para a maioria das aplicações, ele deve ser validado baseado numa estrutura
previamente definida, que constitui uma família de documentos.
Estas especificações têm alguns mecanismos para se determinar a estrutura de
validação de um documento XML. (PINHEIRO, 2003)
Segundo (Daum & Merten, 2002), no passado a DTD (document type definition definição
de tipo de documento) era o modo padrão de se definir um esquema para um documento
XML. No entanto, mais de uma dezena de linguagens alternativas de definição de esquemas
foram criadas por várias instituições e indivíduos. Entretanto, o W3C produziu uma nova
linguagem de esquema, a XML Schema.

DTD

O DTD (definição de tipo de documento) é um documento (esquema) que contém as

regras que definem quais as tags que podem ser usadas num documento XML e quais os
valores válidos. Alguns autores em estudos comparativos para validação estrutural e
sintáctica da XML apontam vários factores restritivos ao uso da DTD: (Zaidan, 2006)
 A sintaxe não é baseada ou derivada da XML, o que não permite que ela seja
validada por um parser.
 As declarações da DTD são globais, o que não permite declarar elementos do
mesmo nome em pontos distintos do documento
 A DTD tem deficiências na especificação do tipo de dado dos elementos (inteiro, real,
alfanumérico, etc.).
<!ELEMENT PRODUTOS ((PRODUTO))+>
<!ELEMENT PRODUTO (NOME, FABRICANTE, PRECO)>
<!ELEMENT FABRICANTE (DESCRICAO, RAZAOSOCIAL, ENDERECO+)>
<!ELEMENT ENDERECO (RUA, NUMERO, CIDADE, CP, DISTRITO)>
<!ELEMENT NOME (#PCDATA)>
<!ELEMENT PRECO (#PCDATA)>
<!ELEMENT DESCRICAO (#PCDATA)>
<!ELEMENT RAZAOSOCIAL (#PCDATA)>
<!ELEMENT RUA (#PCDATA)>
<!ELEMENT NUMERO (#PCDATA)>
<!ELEMENT CIDADE (#PCDATA)>
<!ELEMENT CP (#PCDATA)>
<!ELEMENT DISTRITO (#PCDATA)>
<!ATTLIST PRECO MOEDA CDATA #REQUIRED PAIS CDATA #REQUIRED>
<!ATTLIST FABRICANTE NACIONALIDADE CDATA "PORTUGUESA">
Exemplo de uma DTD que valida o documento XML

XML & ebXML 33

 e-Business

XML SCHEMA

XML Schema é uma linguagem baseada no formato XML para definição de regras de
validação ("esquemas") em documentos no formato XML. Foi a primeira linguagem de
esquema para XML a obter uma recomendação por parte do W3C após serem apontadas as
deficiências na DTD.
Assim um XML Schema tem por objectivo descrever a estrutura de um documento. Ele
define os elementos existentes no documento, bem como sua ordem e os valores possíveis
para os conteúdos.

Ilustração 7 - Exemplo de um XML Schema

As principais características do XML Schema

 Tem a mesma estrutura de um documento XML, ou seja, é uma aplicação XML,
com o mesmo vocabulário capaz de definir estruturalmente classes de
documentos XML, e validá-las; (PINHEIRO, 2003)
 Namespaces (espaço de nomes): contextualiza um nome de elemento ou de
atributo num documento XML, ou seja, determina um escopo para os elementos
declarados. Utilizando o espaço de nomes, passa a ser permitido a repetição de
um nome de elemento num documento XML, desde que esteja em escopos
diferentes. Declaram-se os namespaces apontando uma URI (uniform resource
identifier). A XML permite que se declarem vários namespaces num único
documento, para tal, identifica cada um separado pelo carácter dois pontos (“:”),
da palavra reservada xmlns.
 Grande diversidade de tipos de elementos; Com relação à criação do XML Schema,
existe um conjunto de regras determinadas pelo W3C, que são: definições
básicas; estruturas; tipos de dados.

XML & ebXML 34

 e-Business

O QUE HÁ EM TORNO DA XML

A linguagem XML é muito simples, e existe á sua volta um mundo de outras tecnologias
que a completam e a fazem ampliar as possibilidades, facilitando a
maneira que trabalha com os dados, e no tratamento as informações,
bem como na busca e na recuperação. A XML não é apenas uma
linguagem, mas várias que a fazem flexível, extensível e poderosa.
Conforme se pode verificar são várias as especificações
recomendadas pelo W3C sobre o que há em torno da
XML, como XPath, XPointer, XInclude, XQuery, XSL e
DOM, que regulamentam o acesso a documentos
XML, a sua composição e transformação.
(Daum & Merten, 2002)
Ilustração 8 - Tecnologias em Torno do XML
XPATH (Fonte: Google Imagens 2010)

XPath (XML Path Language) define como os nós dentro dos documentos XML se podem
aceder. As expressões usadas no XPath têm um papel fundamental, e podem ser utilizadas em
outros padrões, como na XSL e na XQuery. A XML é um conjunto de informações numa
estrutura de árvore, com isso, ficará facilitada a localização de um elemento ou um atributo
especificando os nós pai. Utilizam-se expressões de caminho que especificam um arquivo
dentro de um directório de arquivos.
Por exemplo, se desejarmos recuperar o último nome do autor 5, numa árvore de
hierarquia do pai para os filhos: livro – autores – autor – último_nome, tem-se :
/livro/autores/autor[5]/último_nome. Como tudo em XML é case sensitive, aqui também é
necessário ter em consideração as maiúsculas e minúsculas.
Pode fazer-se uso de funções na XPath, por exemplo: last() (número do último nó no
contexto em questão); count() (número de nós de um conjunto de nós); true() false() (valores
booleanos verdadeiro ou falso); sum() (soma valores numéricos de um conjunto de nós);
dentre outras.

XML & ebXML 35

 e-Business

XPOINTER

XPointer é baseado em XPath. É a linguagem de ponteiro XML. Identifica a parte desejada

ou o elemento dentro do documento. A sua finalidade é aumentar o endereço URI, de modo
que seja possível endereçar para dentro de um arquivo XML. Fazendo uma similaridade com o
HTML, seria uma âncora específica dentro de uma página que pode ser endereçada
complementando-se uma URI com o nome da âncora.
Outra característica do uso do XPointer é permitir que atinja um dado elemento pelo
número, pelo nome, pelo tipo ou pela relação a outros elementos no documento. (Zaidan, 2006)

XINCLUDE

XInclude especifica como incluir documentos XML externos, num documento XML alvo.
XInclude introduz um mecanismo para fundir documentos XML. A sintaxe utiliza as mesmas
características da XML - elementos, atributos, e referências de URI. Com o XInclude, podem
compor -se documentos com diferentes namespaces. Na figura abaixo temos um documento
XML que demonstra a flexibilidade do XInclude. (Zaidan, 2006)

Ilustração 9 - Exemplo de um documento XML utilizando XInclude

XML & ebXML 36

 e-Business

XQUERY

A necessidade de se ter consultas em XML, fez o W3C desenvolver o XQuery, que é a

linguagem funcional de consulta a documentos XML. Ela tem características do XPath e do SQL
(Structure Query Languange), e outras linguagens. Como é uma linguagem recente, alguns
problemas foram detectados no início, mas, novas versões com correcções foram lançadas. As
consultas são feitas através de uma expressão.
Numa base de dados relacional, onde os dados estão estruturados, usa-se a SQL para o
acesso e manutenção dos dados. Num documento XML, é necessário de um recurso viável
para resgatar os dados e obter as informações: XQuery é este recurso. As expressões XQuery
são bastante parecidas com expressões SQL. XQuery, portanto, focaliza assuntos que não são
cobertos pela XPath. (Zaidan, 2006)

XSL

As especificações da XSL (extensible stylesheet language – linguagem de estilo estendida)

definem como os documentos XML podem ser transformados noutro formato, principalmente
num formato para apresentação. Esta especificação possui três partes: XPath, XSLT e XSLFO.
(Zaidan, 2006)
 XPath: é uma linguagem para navegar em arquivos XML. Originalmente foi criada
no contexto da XSL. Posteriormente tornou-se uma recomendação separada.
 XSLT(XSL transformations – transformações XSL): é uma linguagem baseada
em XML. Especifica como os documentos XML podem ser transformados noutro
formato (XML ou não). O documento de entrada precisa ser um XML bem
formado.
 XSLFO (objectos de formatação XSL).: é a linguagem para formatar arquivos
XML. XSLFO pode ser comparada com a CSS (cascading style sheets - folhas de
estilo em cascata), que faz a formatação de estilo em páginas HTML.

XML & ebXML 37

 e-Business

APIS XML

São interfaces de programas de aplicações para XML. Definem como as aplicações

podem utilizar os analisadores existentes e outras ferramentas XML.
As aplicações são livres para tratar um documento XML e realizar a análise com lógica
personalizada, porém, é recomendado que isto seja evitado, e se utilizem analisadores
padrões, como o SAX ou DOM. (Zaidan, 2006)

SAX

SAX (Simple API for XML) não é um padrão do W3C. Existem diversos analisadores SAX,
para diferentes linguagens de programação, entre elas, Java, C++ e Delphi. As especificações
SAX estão disponíveis publicamente.
SAX é um analisador baseado em eventos, ele lê um fluxo de entrada XML. SAX é
bastante simples, não exige muita memória e suporta namespace. Não é possível modificar um
documento XML, pois SAX é somente de leitura.

DOM

DOM (document object model) é uma interface de programação de aplicação completa

para documentos XML. Esta interface permite que clientes possam navegar, acrescentar,
modificar ou excluir documentos XML. DOM é relativamente pesado nos recursos, porém, ao
contrário do SAX, armazena a estrutura completa do documento na memória. Como exemplo
de uma implementação DOM muito popular nas plataformas Windows é o MSXML da
Microsoft.
Set xmlDoc = CreateObject("Msxml2.DOMDocument.4.0")
Set stylePI = xmlDoc.createProcessingInstruction("xml", "version=""1.0""")
xmlDoc.appendChild(stylePI)
Set root = xmlDoc.createElement("ALUNOS") xmlDoc.appendChild
root AdicionaAluno "1", "Renato",
root AdicionaAluno "2", "Paulo",
root AdicionaAluno "3", "Marcos",
root AdicionaAluno "4", "Sérgio",
root xmlDoc.save "c:\alunos.xml"
sub AdicionaAluno(id, nome, raiz)
set eleAluno = xmlDoc.createElement("ALUNO")
eleAluno.setAttribute "id", id
set eleNome = xmlDoc.createElement("NOME")
Set eleNomeConteudo = xmlDoc.createTextNode(nome)
eleNome.appendChild eleNomeConteudo
eleAluno.appendChild eleNome
raiz.appendChild eleAluno
end sub
Exemplo de um documento DOM

XML & ebXML 38

 e-Business

<TROCA DE DOCUMENTOS ELECTRÓNICOS VIA XML />

CONCEITOS INICIAIS DAS ARQUITECTURAS DE COMUNICAÇÃO

WEB SERVICES

Para entender a tecnologia de troca de documentos electrónicos via XML, é necessário

voltar um pouco no tempo, para entender os web services. (DOEDERLEIN, 2006)No princípio
dos anos 70 a programação de redes de computadores exigia o uso de APIs de camada de
transporte, por exemplo BSD Sockets para TCP/IP (Transfer Control Protocol/Internet
Protocol). A adopção de programação orientada a objectos, entre meados de 80 e começo dos
anos 90, exigiu uma tecnologia de programação distribuída adequada, assim, surgiram os
middlewares1 de objectos distribuídos. O principal representante foi o CORBA (Common Object
Request Broker Architecture), que especifica um middleware aberto composto de objectos
distribuídos, permitindo que componentes de software sejam conectados juntos, formando
um sistema coeso. Enquanto isso, surgia o grande corrente do CORBA2, o COM (Component
Object Model), da Microsoft; não aberto, não multi-plataforma, pior em desempenho e em
flexibilidade, porém, a família da tecnologia COM tinha maior integração com o Windows.
Na história dos objectos distribuídos, a plataforma J2EE (Java 2 Enterprise Edition)
entrou com a produtividade, portabilidade e estabilidade, mais fácil em alguns aspectos: não
exigindo o uso de diversas de plataformas; libertando o programador de tarefas burocráticas
comuns em CORBA e COM; mais integração do container J2EE, reunindo um middleware
básico com serviços básicos; gestão total da plataforma de aplicação, graças ao modelo
bytecode portável. Posteriormente, surge o NET da Microsoft, cuja arquitectura é um pouco
mais evoluída que o COM.

1
Middleware é uma camada de software que fica no meio do caminho entre as aplicações distribuídas, permitindo a comunicação
entre as camadas de aplicação.
2
A OMG (Object Management Group) estabeleceu a arquitectura CORBA.

XML & ebXML 39

 e-Business

Em 2000, houve um grande interesse nos Web services, embora houvesse a dúvida sobre
a necessidade desta nova tecnologia., e sobre a vantagem em substituir protocolos existentes
por SOAP (Simple Object Access Protocol).
Um Web service é um componente de software que fornece dados e serviços para
aplicações da Internet, contemplando a interacção com outras aplicações. Os Web services
podem ser utilizados em conjunto com sistemas legados, assim, podem adicionar-se novas
funcionalidades, sem que seja necessário retirá-los de produção. A grande aceitação dos Web
services resultou com o aparecimento de um conjunto de tecnologias, que se tornaram um
padrão, entre elas: SOAP, WSDL e UDDI.
Percebem-se muitos outros avanços nos Web services, por exemplo, o baixo
acoplamento, reduzindo ao mínimo a quantidade de informações que uma aplicação tem
sobre as demais. Com o uso da XML, que é o formato de dados de baixo acoplamento por
excelência, os Web services tornam-se o mais forte candidato a middelware universal,
viabilizando o cenário de integração com custos mais reduzidos. (DOEDERLEIN, 2006)
Segundo alguns autores com a utilização dos Web services elimina-se a necessidade dos
aplicativos conversarem entre si, promovendo o uso de interfaces para comunicação. Também
os Web services são uma maneira de implementar EAI, e todo software EAI interage com os
Web services. O crescente interesse nos Web services é pelo facto de que estes permitem SOA
(Service-Oriented Architecture – arquitectura orientada a serviços). (BARBOSA, 2006)

SOAP

Em 2000, o W3C aceitou a submissão do SOAP. Este é um protocolo de mais alto nível
que o TCP/IP. Este formato de mensagem estabeleceu uma estrutura de transmissão para
comunicação entre aplicações ou serviços via HTTP. Sendo uma tecnologia não vinculada a
fornecedor, o SOAP disponibilizou uma alternativa atractiva em relação aos protocolos
proprietários tradicionais. SOAP é assíncrono, ou seja, é capaz de, após despachar uma
mensagem, processar outras, e com duas grandes vantagens: (DOEDERLEIN, 2006)
 Facilidade de tráfego na rede. Não é preciso abrir portas do firewall para deixar
passar SOAP, pois utiliza simples requisições HTTP.

XML & ebXML 40

 e-Business

 Utilização de XML, que por ser transformável, num cenário de integração feitas
de forma independente, não é preciso que todos utilizem exactamente o mesmo
esquema XML, apenas que reconheçam as mesmas entidades

“Uma das particularidades interessantes do SOAP é que ele na verdade

não é apropriado para comunicação entre objectos remotos (SOAP é a sigla para
Simple Object Access Protocol). Ele é mais indicado para prover serviços,
utilizando a passagem de parâmetros e recepção num formato hierárquico
(XML). Uma das razões para isso é que não houve uma grande preocupação em
fazer com que o cliente tivesse a sensação de que o que ele acedia do seu lado
fosse um objecto real. Isso é fácil de entender, porque o SOAP pode ser acedido
inclusive por tecnologias não orientadas a objecto.
(REIS, 2005)
Como SOAP permite a comunicação entre os dois mundos – objectos e não objectos – foi
desvinculada a ideia de objectos da tecnologia SOAP. Porém, o acesso faz-se através de
serviços.

WSDL

WSDL (Web Services Description Language - linguagem de definição de serviços Web) foi
especificada pelo W3C, um ano após o SOAP, como uma nova implementação da XML. É uma
linguagem padrão para descrever a interface dos Web services. O WSDL também é baseado em
XML e o seu tráfego é sobre o HTTP, fornecendo uma descrição do serviço, possibilitando a
integração com ferramentas de desenvolvimento. No WSDL estão descritos: a URL para
aceder o serviço; o nome do Web service; a descrição de cada método; a forma de fazer a
requisição utilizando SOAP, GET ou POST. (Zaidan, 2006)

Ilustração 10 - Exemplo de um documento WSDL

XML & ebXML 41

 e-Business

UDDI

O UDDI (Universal Description, Discovery and Integration - descrição, descoberta e

integração universais) permite ter serviços padronizados, implementando operações úteis
para aplicações. O UDDI é um directório que permite publicar e localizar informações sobre os
serviços disponíveis. Estas informações estão organizadas como documentos WSDL.
UDDI funciona como páginas amarelas (lista telefónica de WSDL´s), ou seja, um local
onde se regista os Web services.

SOA

O SOA (Service Oriented Architecture - arquitectura orientada a serviços) é uma ideia

arquitectural para as aplicações que integram os serviços para utilizadores. Esta arquitectura
é baseada em XML e utiliza tudo com Web service. A figura abaixo mostra a tríade de
tecnologias que compõe os Web services: SOAP; WSDL; UDDI. (DOEDERLEIN, 2006)
É necessário que a tríade de protocolos funcione da seguinte forma:
 O cliente lista os serviços disponíveis a partir de um servidor (UDDI);
 Quando um serviço é escolhido pede uma descrição do serviço através de seu
currículo (WSDL);
 É feita uma chamada ao serviço, passando parâmetros e recebendo valores (SOAP).
Procura-se com o SOA modular a empresa em termos de serviços que podem ser
reaproveitados e publicados para outras empresas, logo, o objectivo principal é modular e
disponibilizar (REIS, 2005)

SOAP
Comunicação
SOAP

WSDL UDDI
Descrição Descoberta
SOAP SOAP
Esquema 3 - Tríade de tecnologias que compõe os web services

XML & ebXML 42

 e-Business

BPM

BPM (Business Process Modeling – modelagem de processos de negócio) é uma maneira

de modelação de processos numa organização. É inspirada num conceito de alguns anos: O&M
(organização & métodos). Os analistas de sistemas têm pensado muito mais nas aberturas dos
sistemas, do que na gestão da empresa por processos. (BARBOSA, 2006)
BPM é uma evolução de EAI onde além de saber da interface, sabe-se dos processos.

A ideia do BPM é permitir que os processos da empresa sejam modelados

por fluxo de informação, ao invés de modelados por sistema.[...] num
desenvolvimento tradicional, são desenvolvidos ou implantados cada um dos
módulos da empresa. Por exemplo, cria-se o módulo de controlo de stock,
financeiro, compras, recursos humanos, etc. E procura-se fazer com que os
módulos se integrem criando portas de comunicação entre eles. Estas portas de
comunicação podem ir desde a troca de arquivos TXT até técnicas mais
sofisticadas.
(REIS, 2005)

SOA e BPM têm uma excelente interacção. Podem ter-se Web services para cada
actividade (pedidos, compras, materiais, fornecedores, clientes, etc.), e com isto, tem-se uma
harmonia organizacional da empresa através dos Web services, promovendo a integração para
o resultado final. (REIS, 2005)
Esta harmonia deve prever o uso de BPEL (Business Process Execution Language -
linguagem para a execução de processos de negócio), evitando qualquer incompatibilidade
com esta alternativa, por exemplo, participantes que não possam falar SOAP, e não poderiam
utilizar um motor BPEL. (Zaidan, 2006)
 BPMS (Business Process Management System – sistema de modelagem de
processos de negócio) é uma ferramenta que permite que o desenho dos
processos seja feito de forma visual. Permite: simular os fluxos de processos;
desenhar diagramas de wokflow; possuir ferramenta de EAI (que integre, pelo
menos, com SOAP e Web service); suportar servidor de aplicação.
 BPMS (Business Process Management System – sistema de modelagem de
processos de negócio)) representação gráfica para representar a maioria das
situações comuns que acontecem com os fluxos de processos.

XML & ebXML 43

 e-Business

OUTRAS TECNOLOGIAS PARA TROCA DE DOCUMENTOS ELECTRÓNICOS

XML não é a única forma de troca de documentos electrónicos, até porque, a XML é uma
tecnologia relativamente recente. Outras formas de troca existiram, e continuam a existir,
embora que pelo exposto neste estudo, a XML é a forma mais flexível, simples, eficaz e de
menores custos para as organizações. No entanto outras tecnologias são apresentadas para
ilustrar a pesquisa.

ARQUIVOS TEXTO TXT ( FLAT FILE)

Hoje em dia a utilização de arquivos texto (também chamados de Flat Files) para
troca de informações é muito comum, visto que este padrão é utilizado desde os
primórdios dos sistemas de computador. Porém a adopção do padrão XML (Extensible
Markup Language) é uma tendência mundial. Este tipo de arquivo abre possibilidades
infinitas de tratamento de dados, que vão desde a utilização de esquemas para definição
e validação de dados até utilização de outros padrões para interagir com este formato.
(MELLO, 2006)
A figura abaixo mostra um exemplo de transformação de um arquivo texto tradicional -
TXT (lado esquerdo), para um documento XML. Percebe-se que o arquivo texto não tem
estrutura e é pobre em semântica, porque não descreve requisitos mínimos para o
entendimento. Por isso, este padrão, que embora tenha sido utilizado por muito anos para a
troca de dados, actualmente é utilizado em muito menor quantidade, ainda está presente
apenas nos sistemas legados. Já o arquivo XML, permite-nos perceber o do significado dos
dados, bem como a estrutura, a sua utilização está em plena ascensão para todas as situações
que envolvem a troca de documentos electrónicos.

<?xml version="1.0" standalone="yes"?> <PROFESSORES

xmlns="7a Serie"> <TURMA> <CLASSE>7A</CLASSE>
7 <PORTUGUES>Claudio</PORTUGUES>
A <RELIGIAO>Marcia</RELIGIAO>
<GEOGRAFIA>Cristian</GEOGRAFIA> </ TURMA> <TURMA>
7 <CLASSE>7B</CLASSE>
B Claudio Marcia <PORTUGUES>Ailton</PORTUGUES>
<RELIGIAO>Marcelo</RELIGIAO> <GEOGRAFIA
Ailton Marcelo Cristian Iago Jorge
>Iago</GEOGRAFIA> </TURMA> <TURMA> <CLASSE>7C</
7 Paola Rodrigo Simone CLASSE> <PORTUGUES>Paola</PORTUGUES>
C Leila Carlos <RELIGIAO>Rodrigo</RELIGIAO>
<GEOGRAFIA>Jorge</GEOGRAFIA> </TURMA> <TURMA>
7 <CLASSE>7D</ CLASSE>
D <PORTUGUES>Leila</PORTUGUES>
<RELIGIAO>Carlos</RELIGIAO>
<GEOGRAFIA>Simone</GEOGRAFIA> </ TURMA> </
PROFESSORES>

Tabela 1 - Arquivo texto txt versus documento

XML & ebXML 44

 e-Business

EDI

O EDI – (Electronic Data Interchange – troca de dados electrónicos), provê a troca

estruturada de dados através de uma rede de dados qualquer: empresarial ou pública. A troca
pode ser dentro da empresa ou entre aplicações de organizações diferentes.
(Turban, Rainer Jr, & Potter, 2005) Consideram que o uso primário do EDI é transferir
transacções de negócio repetitivas tais como: encomendas, facturas, aprovações de crédito e
notificações de envio. Isto significa que o EDI não implica em comunicação em tempo real.
EDI facilita a troca de documentos, pois as trocas de documentos podem ser realizadas
de forma electrónica, proporcionando assim a redução do papel e a redução dos tempos de
realização das transacções.
Porém a XML torna o EDI menos proprietário e mais aberto. Nas comunicações EDI
inter-organizacionais, a XML elimina a necessidade de desenvolvimento de aplicações
específicas dentro da empresa, utilizando sintaxes da EDI tradicional, como o EDIFACT, para
tornar as informações contidas nas mensagens entendidas por todos. Além disto, o padrão
EDI torna-se caro para as empresas, pois necessitam implementar controlo e gestão.

TÉCNICAS DE SEGURANÇA NA TROCA DE DOCUMENTOS ELECTRÓNICOS VIA XML

Actualmente a preocupação com a segurança é um aspecto importante de comunicação

na Internet. Com o passar dos anos foram desenvolvidas várias técnicas de segurança. Uma
arquitectura de segurança é baseada nos seguintes serviços de segurança: confidencialidade;
integridade; autenticação e reconhecimento.
As técnicas para implementar esses serviços são: chaves de criptografia assimétricas,
simétricas, híbridas; sínteses de mensagem; assinaturas digitais e certificados.
A arquitectura de segurança da XML é baseada em padrões de criptografia. Os dois
padrões são XML Signature, XML Encryption, que lidam com criptografia. (Daum & Merten,
2002)

XML & ebXML 45

 e-Business

XML SIGNATURE

Uma assinatura digital define-se pelo valor calculado com um algoritmo criptográfico,
anexado ao objecto de dados de tal forma que se possa usar essa assinatura para verificar a
autenticidade e integridade dos dados.
XML Signature (assinatura XML) é uma assinatura digital mas adaptada a assinar
documentos XML. Descreve a sintaxe e o modelo de processamento de assinaturas baseadas
em XML e possui o status de uma recomendação proposta do W3C. Signature permite a
assinatura digital de qualquer tipo de objecto Web, inclusive os documentos XML, usando um
conceito distribuído, que permite a referência de objectos assinados.
Ao assinar documentos XML, os algoritmos de assinaturas usam a representação de
carácter do documento ou elemento para calcular a assinatura.
A forma como funcionam é extremamente fiável. A assinatura não só assegura que a
pessoa assinou aquele documento é de facto quem se espera – através de um certificado –
como também que o mesmo se manteve inalterado até ao momento em que foi apresentado.
Uma mensagem encriptada com uma chave pública apenas pode ser desencriptada com a
correspondente chave privada.
Existem três tipos de assinatura em XML Signature:
• Detached (isolada): O documento XML a ser assinado e a assinatura estão em
dois ficheiros distintos, sendo que esta tem uma referência ao documento que se
propõe a assinar.
• Enveloped (envolvida): O documento XML e a assinatura surgem no mesmo
ficheiro de uma forma sequencial.
• Enveloping (envolvendo): O documento e a assinatura estão contidos num
envelope XML.

XML & ebXML 46

 e-Business

XML ENCRYPTION

Também criado pelo W3C, define como os dados arbitrários podem ser representados
de forma criptografada em XML. O padrão foca os seguintes alvos de criptografia: dados
binários quaisquer; documentos XML completos e conteúdo do elemento. Além da definição
dos seus próprios elementos sintácticos, XML Encryption utiliza os conceitos e a sintaxe da
XML Signature para especificar coisas como transformações ou informações de chave.
(Daum & Merten, 2002)

XML & ebXML 47

 e-Business

<EBXML />

O ebXML (Eletronic Business Extensible Markup Language) tem como objectivo a criação
de um padrão aberto e único para o mercado de negócios mundial.
As empresas que estão à frente deste projecto, desde 1999, são a OASIS e UNCEFACT.
Estas empresas têm vindo a tentar identificar uma base técnica para padronização. Esta
especificação permitiria as organizações trocarem mensagens, baseadas em XML.
Sabe-se que, devido à diversidade, uma padronização desta amplitude é difícil. Para
conseguir o padrão, existe a necessidade da adesão das organizações para viabilizar as
implementações.
Actualmente, as especificações da arquitectura ebXML são:
 Technical Architecture (TA) 1.04
 Business Process Specification Schema (BPSS) 1.01
 Registry Information Model (RIM) 2.0 (ISO 15000-3)
 Registry services specification (RS) 2.0 (ISO 15000-4)
 ebXML requirements (REQ) 1.06
 Collaboration Protocol Profile and Agreement Specification (CPPA) 2.0 (ISO 15000-1)
 Message Service Specification (MS) 2.0 (ISO 15000-2)

FUNCIONAMENTO E CONCEITOS DE EBXML

A criação do ebXML nasce, então, da necessidade de melhorar o desempenho das

empresas e a relação entre parceiros de negócios. Um cenário típico de negócios utilizando o
ebXML é apresentado na figura da página seguinte.

XML & ebXML 48

 e-Business

Ilustração 11 - Cenário inicial de ebXML Fonte: www.ebxml.org

DESCRIÇÃO DO CENÁRIO APRESENTADO :

1. A empresa A decide efectuar negócios pela via electrónica e identifica a tecnologia ebXML
como a arquitectura mais vantajosa. A empresa A contacta uma empresa de registos de
ebXML (Registry) para avaliar as especificações e detalhes de implementação.
2. A empresa A desenvolve uma aplicação compatível com as especificações ebXML,
acrescentando uma camada ao software de aplicação já existente, ou adquirindo
aplicações disponíveis no mercado.
3. A empresa A submete à empresa de registos os seus perfis de negócio. Nestes perfis
constam informações relativas ao tipo de negócio e regras de implementação (ex. quais os
campos a utilizar, etc.).
4. A empresa B necessitando de determinado produto ou serviço, inquire a base de dados da
empresa de registo e descobre os cenários oferecidos pela empresa A.
5. A empresa B envia um pedido para efectuar negócio à empresa A e submete uma
proposta de negócio onde é definido o processo, a documentação, as mensagens, os
requisitos de segurança, etc. Finda a negociação da proposta, é elaborado um protocolo de
colaboração (collaboration agreement) entre as duas organizações, o qual faz parte do
Acordo de Parceria (Trading Partner Agreement).
XML & ebXML 49
 e-Business

6. As duas organizações estão aptas a realizar negócios utilizando as especificações ebXML.

Da descrição anterior relativa à forma de efectuar negócios utilizando as especificações
ebXML, importa clarificar os seguintes conceitos:
 Empresa de Registos ebXML (Registry) Empresa que regista os processos de
negócio vocabulários e perfis necessários à realização de negócios.
 Perfil de Negócio (Business Profile) Descrição das capacidades e limitações das
organizações para realizar negócios segundo as especificações de ebXML. Contém
ainda os cenários de negócio.
 Processos de Negócio (Business Processes) Descreve os meios pelos quais uma ou
mais actividades são efectuadas.
 Documentação do Negócio (Business Documents) Informação que faz parte dos
processos de negócio, e que é trocada entre os intervenientes do negócio (ex.
encomenda).
 Acordo de Parceria (Trading Partner Agreement) Especifica os parâmetros de
interface entre duas organizações. (Ariza & Martins)

ARQUITECTURA DE EBXML

A arquitectura ebXML é composta por duas visões desenvolvidas a partir do modelo de

referência Open-EDI da ISO.
 Visão Operacional - Descreve os
processos de negócios num formato
independente de uma linguagem de
programação. Para este propósito,
ebXML utiliza o UML (Unified Modelling
Language) e, a metodologia de
Esquema 4 - Modelo Open-EDI
modelação da UN/CEFACT (Modelling
Methodology - UMM). A visão operacional está ligada à etapa do desenho de um
sistema ebXML.
 Visão Funcional - Descreve a estrutura técnica utilizada para a descoberta e troca
da informação de negócios. A visão funcional está ligada à etapa de produção dum
sistema ebXML.

XML & ebXML 50

 e-Business

VISÃO O PERACIONAL DE EBXML

O objectivo de ter uma visão operacional é identificar as regras do negócio, estas regras
são armazenadas no registo. O registo contém dados e definição dos processos, inclui também
relações e referências cruzadas como as utilizadas nos vocabulários próprios dos negócios. O
registo é a ponte entre a linguagem do negócio e o conhecimento expresso pelos modelos de
uma forma generalizada e neutra.
A criação dos modelos constituem a visão operacional e podem dividir-se em várias
fases, em cada fase são criados diagramas UML para a modelação do negócio.
A primeira fase descreve os requisitos, os quais descrevem o problema em diagramas de
casos de uso (Use Case). Caso o mesmo cenário exista no registo, cria-se uma instância, caso
contrário cria-se uma nova entrada.
Na segunda fase (análise) são descritos os processos de negócio em diagramas de
actividades e sequências. Os diagramas de classes capturam a informação associada as
mensagens de negócios. A fase de análise reflecte as regras do negócio que o registo contém.
A fase de desenho é o ultimo passo na normalização. (Ariza & Martins)

VISÃO FUNCIONAL DE EB XML

A visão funcional (dos serviços) na arquitectura ebXML está ligada à execução (runtime)
dos sistemas ebXML. Sendo os sistemas ebXML, sistemas de colaboração, o seu núcleo é o
conjunto dos repositórios. Os repositórios armazenam toda a informação criada pela visão
operacional (processos de negócio, perfis de colaboração e as especificações do ebXML).
Os componentes da visão funcional são: (Ariza & Martins)
 Os perfis dos protocolos de colaboração (CPP), contém o perfil das capacidades
informáticas dos parceiros, os protocolos de transporte, soluções de segurança e os
cenários ebXML suportados.
 Os acordos de colaboração (Collaboration Protocol Agreements - CPA), são os
acordos entre os parceiros com perfis de colaboração em comum.
 No caso da ratificação dos acordos de colaboração, as mensagens de negócios
podem ser transmitidas entre os parceiros e iniciam assim os negócios via ebXML. A
camada física das comunicações é definida pelas normas ebXML (Messaging

XML & ebXML 51

 e-Business

Services), a qual descreve o protocolo suportado, os formatos de empacotamento

das mensagens e os cabeçalhos das mensagens.

COMPONENTES PRINCIPAIS EBXML

Dos componentes da arquitectura, três desempenham um papel fundamental na

diferenciação entre o ebXML e o UNI-EDIFACT (United Nations/Electronic Data Interchange
For Administration, Commerce and Transport). Esta diferenciação permite ao ebXML ser mais
abrangente e flexível.

PROCESSOS DE NEGÓCIOS

Os modelos dos processos de negócio descrevem o seu funcionamento (negócios). A

especificação para a definição de processos, permite expressar processos de negócios em
cenários específicos suficientemente claros para serem perceptíveis por outras empresas. Isto
permite a integração d processos de negócios entre empresas.
Os modelos são baseados num metamodelo do ebXML e são expressos e UML e UMM.

Esquema 5 - Meta modelos UMM (Ariza & Martins)

XML & ebXML 52

 e-Business

O REGISTO E O REPOSITÓRIO

O Registo e o repositório prestam um conjunto de serviços que permitem a partilha da

informação entre entidades (empresas)
com o propósito de utilizar o ebXML
para negócios. As informações são
armazenadas como objectos no
repositório e são geridas pelo registo.
Um item no repositório é utilizado para
referir um objecto que foi submetido ao

registo para armazenamento, por Ilustração 12 - Relação entre o registo e o repositório (Ariza &

exemplo, um documento XML que Martins)

representa uma factura. Cada item no repositório é descrito, com metadados, por uma entrada
no registo. A relação entre registo e repositório é apresentada na Figura.

SERVIÇOS DE MENSAGENS

Os serviços de mensagens ebXML (ebMS) são os componentes que tem a função de

fornecer os serviços para a troca de documentos de negócios. A parte de ebMS relativo às
mensagens é uma extensão do SOAP. O SOAP não fornece soluções satisfatórias em termos de
segurança e fiabilidade.
Baseado no SOAP o ebMS acrescenta algumas características para garantir uma
plataforma onde é possível realizar negócios com segurança e de forma fiável.
Em conjunto o ebXML fornece:
• Especificações de empacotamento
• Extensões ebXML/SOAP
• Serviços de tratamento de mensagens
• Mensagens fiáveis (persistentes)
• Tratamento de erros
• Segurança

XML & ebXML 53

 e-Business

<CONCLUSÃO/>

Actualmente a área de TI vê-se confrontada com o desafio da integração das diferentes

aplicações empresariais, sistemas legados e aplicações COTS. O problema prende-se com
diversos factores desde um aumento significativo do número de sistemas de informação e
repositórios das informações dentro das organizações, a ambientes cada vez mais
heterogéneos, e com diversos cenários carentes de integração, até à necessidade de uma
forma mais simples de trocar documentos electrónicos com a meta da redução de custos
sempre presente.
Perante todo este quadro, a XML e todas as tecnologias que giram em torno dela passou
a ser uma linguagem recomendada pela W3C. Intensificou-se, entretanto, o esforço de
integração e racionalização dos processos de negócio.
A Internet passou a ser vista como simplificadora dos processos, possibilitando o
desenvolvimento de arquitecturas de comunicação, disponibilizando parte das informações
das organizações, e extrapolando as fronteiras empresariais. Assim os novos protocolos Web
promovem o intercâmbio de documentos, com sofisticadas formas de segurança.
Neste trabalho demonstrou-se que, num contexto actual de troca de documentos
electrónicos inter-organizacionais, a XML é uma linguagem perfeita, devido a sua forma
estruturada de tratar os dados, e sua extensibilidade. O ebXML representa o futuro já que o
seu objectivo é a criação de um padrão aberto e único para o mercado de negócios mundial,
embora já existam várias especificações da arquitectura ebXML.
Conclui-se assim que no mundo XML de padrões abertos, torna-se muito mais simples a
implementação, do que a utilização de soluções tradicionais proprietárias.
Conclui-se também que, neste cenário em que as empresas estão inseridas, verifica-se
uma maior adequação para as organizações efectuarem a integração das aplicações já
existentes, com baixos custos, de forma rápida, do que tentar unificar seus ambientes e
plataformas, despendendo de mais tempo e altos custos.

XML & ebXML 54

 e-Business

<REFERÊNCIAS BIBLIOGRÁFICAS/>

Ariza, C., & Martins, P. (s.d.). ebXML Tecnologias para o Comércio Electrónico. Portugal.

BARBOSA, J. L. (2006). Desenvolvimento de Sistemas Distribuídos II. Belo Horizonte, Brasil.

César Ariza, P. M. (2003). Tecnologias para o Comércio Electrónico - ebXML. Universidade do

Minho, Portugal.

CUMMINS, F. A. (2002). Integração de sistemas: EAI - enterprise application integration. Rio

Janeiro.

DAUM, B., & MERTEN, U. (2002). Arquitetura de sistemas com XML. Rio de Janeiro, Brasil.

DOEDERLEIN, O. P. (2006). Entendendo Web Services e SOA: De RPC à service oriented

architecture. Revista Java Magazine .

FURGERI, S. ( 2001). Ensino didático da linguagem XML. São Paulo, Brasil.

MELLO, D. (2006). Convertendo arquivos texto em xml com BizTalk Server 2006. Brasil.

PARREIRAS, F. (2006). Integração de Sistemas Corporativos: competências necessárias. Brasil.

PINHEIRO, M. C. (2003). Proposta de um esquema XML para o intercâmbio de dados entre

programas de análise por elementos finitos. Belo Horizonte.

REIS, G. (2005). Da orientação a objetos até o SOA chegando ao BMP. Revista Mundo Java.
Curitiba, Brasil.

Resende, D. A., & Abreu, A. F. (2003). Tecnologia da informação aplicada a sistemas de

informação empresariais. São Paulo, Brasil.

Turban, E., Rainer Jr, R. K., & Potter, E. P. ( 2005). Administração de tecnologia da informação:
teoria e prática. Rio de Janeiro.

Zaidan, F. H. (2006). SISTEMAS DE INFORMAÇÕES EMPRESARIAIS: Integração de sistemas

inter-organizacionais utilizando troca de documentos electrónicos via XML. BELO
HORIZONTE, Brasil.

XML & ebXML 55

 e-Business

<RECURSOS NA INTERNET/>

ISO http://www.iso.org/
OASIS http://www.oasis-open.org/home/index.php
XML http://www.w3.org/XML/
ebXML http://www.ebxml.org/
http://ebxml.xml.org/
http://www.ibm.com/developerworks/xml/library/x-ebxml/
http://xml.coverpages.org/ebXML.html
UN/EDIFACT http://www.unece.org/trade/untdid/welcome.htm

XML & ebXML 56