PMR3507 Fábrica digital · 2019. 5. 17. · Java, C#, etc.) es • Os web services estão...
Transcript of PMR3507 Fábrica digital · 2019. 5. 17. · Java, C#, etc.) es • Os web services estão...
Escola Politécnica da Universidade de São Paulo
Departamento de Engenharia Mecatrônica e de Sistemas Mecânicos
Av. Prof. Mello Moraes, 2231
05508-030 - São Paulo - SP - Brasil
LSA – Laboratório de Sistemas de Automação www.pmrlsa.poli.usp.br
PMR3507
Fábrica digital
Do EDI ao SOA
Cro
nolo
gia
• 1980 – 1990 – EDI (Eletronic Data Interchance)
• 1990 – 2000 – ORB (Object Request Broker)
• 2000 – Atual – SOA (Service Oriented Architecture)
ED
I (E
letr
on
ic D
ata
Inte
rch
an
ge
) • Forma de comunicação entre organizações
• Forma de aumentar a competitividade
• Transferência eletrônica entre computadores, de
transações comerciais ou administrativas,
utilizando padrões acordados para estruturar as
mensagens
• Intuito
– Automatizar a troca de mensagens, a geração das
mensagens e as ações a serem tomadas ao receber
as mensagens
• Objetivo
– Eliminar papel
– Agilizar a troca de informações entre clientes e
fornecedores
– Redução de mão de obra
ED
I (E
letr
on
ic D
ata
Inte
rch
an
ge
) • Vantagens
– Melhora a precisão das informações e reduz erros
– Reduz a reentrada de dados – permite que as
empresas recebam pedidos eletronicamente em um
formato padronizado
– Acelera a transmissão de informações entre
organizações
– Reduz os estoques e os custos de estoques
– Aprimora a relação entre clientes e fornecedores
– Aprimora o esforço de marketing
– Aumenta a produtividade – elimina atividades de
coleta, envio e recebimento de informações
– Reduz o fluxo de papéis
– Padroniza programas e procedimentos
– Permite a redução de pessoas
ED
I (E
letr
on
ic D
ata
Inte
rch
an
ge
) • Desvantagens
– Requer alto nível de comprometimento da gerência para ser bem sucedido
– O EDI carece de um entendimento comum e a educação é limitada
– É difícil quantificar o retorno do investimento
– Requer uma despesa de capital inicial alta
– Existem muitos fornecedores
– Não havia padronização ou estes estavam em evolução
– Impacta nas estruturas organizacionais, procedimentos e controles
– Causa impacto significativo na cultura organizacional
– A maioria dos parceiros comerciais não usa o EDI - sem fornecedores e clientes cooperativos, a capacidade de EDI é essencialmente inútil
ED
I (E
letr
on
ic D
ata
Inte
rch
an
ge
) • Para a adoção do EDI, muitas empresas
necessitaram reestruturar seus processos
– Difícil mensurar se o “sucesso” obtido foi decorrente
do EDI ou da reestruturação
• Pequenas e médias empresas adotaram por
imposição de uma empresa maior (cliente), com
poder de decisão
– Duas ou mais empresas que adotaram o EDI para
atender um grande cliente não o utilizaram para
realizar transações entre si
OR
B (
Obje
ct
Requ
est
Bro
ker)
• Contexto
– Computação distribuída
– Não necessariamente entre empresas, mas também
para integrar sistemas de uma mesma empresa
– Simplificar a programação através da rede de
comunicação
• Principais padrões
– DCOM (Distributed Component Objetc Model)
– CORBA (Common Object Request Broker
Architecture)
– EJB (Enterprise Java Beans)
OR
B (
Obje
ct
Requ
est
Bro
ker)
• EJB
– Vantagem
• Desenvolvida por um único fabricante (Sun,
atualmente Oracle)
• Portável para diversas plataformas
– Desvantagem
• Um de seus principais componentes, o Java/RMI
(Remote Method Invocation) se basear na linguagem
Java, exigindo que tanto os objetos Java/RMI do
cliente quanto do servidor sejam escritos em Java
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA e DCOM
– Seguem especificações padronizadas visando
interoperabilidade e independência da plataforma
– Definem seus próprios padrões de interfaces para
lidar com as particularidades dos aplicativos
– Usados como middleware de objetos distribuídos
– Facilitam a tarefa de criar aplicativos distribuídos
pois permitem que a rede de comunicação seja
encarada como uma grande máquina virtual onde os
objetos remotos aparentam estar presentes
localmente
OR
B (
Obje
ct
Requ
est
Bro
ker)
• DCOM
– Solução proprietária da Microsoft
– Integrante do sistema operacional Windows
– Indicado para soluções baseadas em Windows
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA
– Utilizado na integração de diferentes sistemas
(heterogêneos) – seu ponto forte
– Pontos fracos
• Complexidade
• Existirem variações de implementações...
• Grande número de distribuidores implementam
CORBA para os sistemas operacionais mais comuns,
o que torna desnecessária a utilização de mais do que
uma distribuição para integrar diferentes sistemas
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA
– ORB é o componente mais importante
– Plataforma para que os objetos interajam
– Responsáveis por localizar e ativar os servidores,
gerenciar requisições e respostas, tratar condições
de concorrência e exceções
– Grupo de objetos cooperativos que podem residir na
mesma máquina ou em máquinas distintas
– Os objetos que residem no lado do cliente podem
invocar métodos presentes nos objetos do servidor,
utilizando um identificador para este objeto como se
ambos estivessem na mesma máquina
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA
– ORB é o componente mais importante
Object Request Broker
Application Objects Common Facilities
Object Services
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA
– Cliente não tem necessidade de saber sobre a
implementação do servidor, em que linguagem este
foi escrito, em que sistema operacional/plataforma
este está sendo executado, ou qual protocolo de
comunicação e rede estão sendo utilizados para
interconectar os objetos distribuídos
– O servidor apenas provê uma interface que serve
como acesso às suas funcionalidades
– Há uma evidente separação entre as interfaces e as
implementações dos objetos
– CORBA introduz uma linguagem neutra chamada
Interface Definition Language (IDL)
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA
1. Objeto cliente chama um método do servidor
através do stub
2. ORB captura a requisição para o BOA (Basic
Objetc Adapter) que ativa a implementação (objeto
no servidor)
Cliente Servidor
SkeletonBOAInterface
ORB
ORB
Stub
1.
2.
3.
4.
5.
OR
B (
Obje
ct
Requ
est
Bro
ker)
• CORBA
3. A implementação invoca o BOA para informar que
esta está ativa e disponível
4. BOA passa a requisição para o objeto no servidor
através do seu skeleton
5. A implementação retorna o resultado para o cliente
através do ORB
Cliente Servidor
SkeletonBOAInterface
ORB
ORB
Stub
1.
2.
3.
4.
5.
SO
A (
Arq
uitetu
ra O
rie
nta
da
a
Se
rviç
os) • Conjunto de princípios arquiteturais para a
construção de sistemas autônomos e
interoperáveis
• Sistemas autônomos
– Criados independentemente de outros sistemas
– Capazes de atuar independentemente do ambiente
em que estão
– “Auto-contidos”
• Interoperabilidade
– Propiciada por uma interface clara e abstrata que
expõe o serviço para o seu ambiente, escondendo a
implementação deste serviço
SO
A (
Arq
uitetu
ra O
rie
nta
da
a
Se
rviç
os) • A descrição da SOA baseia-se em um conceito
central: o serviço
– Serviço pode ser entendido como a implementação
de uma capacidade computacional
– Permite que o sistema de informação possa ser
adequado para ambientes interoperáveis e
heterogêneos
• A interação do usuário (ou sistema) com o sistema
de informação é feita por meio de adaptadores
– Interfaces
– Acoplamento “fraco”
– Comunicação entre processos computacionais
independe da forma como foram implementados
– Serviços podem ser reutilizados
– Serviços podem ser combinados
Web
Serv
ices
• Meio mais utilizado para implementar SOA
• É um conjunto de aplicações que encapsulam
operações
– Aplicações podem ser descritas, publicadas,
localizadas e invocadas em uma rede comunicação
Web
Serv
ices
• Componentes do Web Service
Fornecedor do
serviço (Service
provider)
Web
Serv
ices
• Componentes do Web Service
– Fornecedor do serviço
• Provedor do serviço e representa a aplicação que
hospeda o WS, permitindo que os “clientes” acessem
o serviço e disponibilizem os serviços no repositório
de descrição de serviços
Web
Serv
ices
• Componentes do Web Service
Fornecedor do
serviço (Service
provider)
Repositório
de descrição
de serviço
(UDDI)
Web
Serv
ices
• Componentes do Web Service
– Repositório de descrição de serviços
• Servidores de registro e busca de WS baseados em
arquivos de descrição de serviços que foram
disponibilizados pelos fornecedores dos serviços
• Facilitam a localização dos serviços, via internet, com
os consumidores dos serviços
Web
Serv
ices
• Componentes do Web Service
Fornecedor do
serviço (Service
provider)
Consumidor do
serviço (Service
requester) Conecta
Repositório
de descrição
de serviço
(UDDI)
Web
Serv
ices
• Componentes do Web Service
– Consumidor do serviço
• “Cliente” do serviço
• Representa a aplicação que está procurando,
invocando ou iniciando uma interação com o WS
• Pode ser uma pessoa ou uma aplicação
computacional
• Busca informação no repositório de descrição de
serviços
Web
Serv
ices
• Componentes do Web Service
Web
Serv
ices
• Os web services estão organizados em camadas
de serviços
– Serviço de Transporte - responsável pelo transporte
de mensagens entre aplicações computacionais
• HTTP (Hyper Text Transfer Protocol)
• SMTP (Simples Mail Transfer Protocol)
• FTP (File Transfer Protocol)
– Serviço de Mensagem
• Responsável pela codificação das mensagens em um
formato XML (eXtensible Markup Language)
• XML permite descrever uma informação e apresentar
sua estrutura
• XML pode ser compreendido pelo ser humano
Web
Serv
ices
• Os web services estão organizados em camadas
de serviços
– Serviço de Descrição
• Responsável pela descrição de uma interface pública
para um determinado serviço
• Pode ser realizado pelo WSDL (Web Service
Description Language)
– Serviço de Aplicação
• Esta camada programa as funcionalidades específicas
do serviço oferecido
• Pode ser implementada em diferentes linguagens (ex.:
Java, C#, etc.)
Web
Serv
ices
• Os web services estão organizados em camadas
de serviços
– Serviço de Coordenação
• Responsável pelo fluxo dos processos
• O fluxo dos processos define o número de etapas que
devem ser executadas e o conjunto de condições que
determinam a ordem natural destas etapas
• Envolve os programas de gerenciamento
• O serviço de coordenação tem sido abordado por
meio do BPEL (Business Protocol Executable
Language)