Comparativa Client/Servidor amb JAVA i CORBA

1
Comparativa Client/Servidor amb JAVA i CORBA
Pilar Nieto Soler Núria Lleal Serra Antonio
Santiago Pérez
2
Índex

• Introducció.
• Tecnologies no-CORBA.
• Sockets.
• Java Servlets.
• Java RMI.
• DCOM.
• CORBA.
• Què ofereix Java a CORBA?.
• Què ofereix CORBA a Java?.
• Java RMI vs CORBA vs DCOM.
• Bibliografia.

3
Introducció (I)

• Laugment de la connectivitat canvia la forma de
  desenvolupar aplicacions.
• Augment de les aplicacions distribuïdes.
• Existeixen diversos nodes on es distribueix el
  treball de lempresa.
• Per què no fer que el sistema dinformació es
  distribueixi a tots els nodes?

4
Introducció (II)

• Avantatges de les aplicacions distribuïdes
• Cada localitat te la seva part de funcionalitat
  dins el Sistema dInformació.
• Cada localitat interacciona amb les altres per
  tal daconseguir la funcionalitat general.
• Millora en la eficiència del sistema, ja que cada
  localitat conserva les dades que utilitza més
  sovint.
• La resta del sistema pot seguir funcionant encara
  que falli alguna localitat.

5
Introducció (III)

• Inconvenients de les aplicacions distibuïdes
• Més difícils de compendre, implentar, depurar i
  mantenir.
• Necesitat deines potents pels programadors que
  explotin els avantatges i amaguin les
  dificultats.

6
Introducció (IV)

• Necessitat deines i suports, tant físics com
  lògics
• Hardware ordinadors, xarxes de connexió,
  protocols nivell fisic i enllaç, etc.
• Sistemes Operatius de xarxa Proporcionen entorn
  dabstracció pels programadors amb els detalls de
  la màquina.
• Protocols estàndard dalt nivell.
• Models conceptuals Estableixen un marc lògic pel
  desenvolupament daplicacions (Client/Servidor).
• Tecnología Són la materialització del model
  conceptual.
• Llenguatges, entorns de desenvolupament i
  execució.

7
Aplicacions Client/Servidor distribuïdes (I)

• En els inicis
• Cost Hardware elevat.
• Un únic i gran equip gestionava tota lempresa.
• Utilització de terminals punts daccés al gran
  Sistema d Informació.
• Tot el codi i dades residia a lordinador
  central.
• Poca escalabilitat.
• Difícil de mantenir.
• Més terminals gt Més peticions al servidor.

8
Aplicacions Client/Servidor distribuïdes (II)

• Evolució
• Hardware molt més barat ( terminals més potents,
  desaprofitant les seves capacitats utilitzant-los
  com a tals ).
• Model conceptual Client/Servidor.
• Separa les funcionalitats.
• El servidor ofereix serveis que poden ser
  utilitzar pels clients.

9
Sistemes Distribuïts (I)

• Ofereixen la seva funcionalitat en forma
  dobjectes.
• Faciliten la modularitat i reutilització.
• No existeixen (explícitament) els clients i
  servidors.
• Els processos que composen laplicació poden
  estar execuntant-se en màquines diferents.
• Tots els processos són clients i servidors
  cooperant per tal daconseguir la funcionalitat
  total de laplicació.

10
Sistemes Distribuïts (II)

• Desenvolupament daplicacions distribuïdes
• Tècniques no CORBA
• Sockets.
• Servlets.
• RMI.
• DCOM (Microsoft)
• CORBA.

11
Tecnologies No-Corba(I)

• Què són?
• Objectiu
• Tipus
• Sockets
• Servlets
• RMI
• DCOM
• Amb RMI i DCOM entrem al món dels objectes
  distribuïts.

12
Tecnologies No-Corba(II)

• Què són?
• Tècniques de desenvolupament daplicacions
  distribuïdes, que no estan basades en CORBA.
• Objectiu
• Abstraure al programador de la naturalesa
  distribuïda de les aplicacions.

13
Tecnologies No-Corba(IV)

• Tipus
• Sockets
• Introducció
• Punt de comunicació, per el qual un procés pot
  emetre o rebre informació.
• És la tecnologia més antiga.
• Java ofereix una sèrie de classes per a sockets.
• Tipus
• Orientats a connexió (stream).
• No orientats a connexió (datagrama).

14
Tecnologies No-Corba(III)

• Tipus
• Sockets

15
Tecnologies No-Corba(V)

• Tipus
• Sockets
• Avantatges
• Comunicació ràpida.
• Estàndard de programació en internet.
• Programació relativament senzilla, en aplicacions
  no molt complexes.

16
Tecnologies No-Corba(VI)

• Tipus
• Sockets
• Inconvenients
• Nivell més baix de comunicació.
• Complexitat a la hora dimplementar certes
  aplicacions (mail, ftp..).
• Codi poc portable.
• No ofereixen una estandarització dels tipus El
  programador sha dencarregar de
  codificar/descodificar les dades transmeses
  (marshaling).

17
Tecnologies No-Corba(VII)

• Tipus
• Servlets
• Que són?
• Programes escrits en Java, que sexecuten en la
  màquina virtual del servidor i sencarreguen
  datendre peticions del client, tenint el
  servidor com a encarregat. Així doncs, el
  servidor també es pot beneficiar de totes les
  avantatges que ofereix Java.

18
Tecnologies No-Corba(VIII)

• Tipus
• Servlets
• Per què sorgeixen?
• Java Llenguatge de programació per a Internet.
  El desenvolupament dun servidor completament en
  java, permetria treure profit a aquesta
  popularitat.
• Problema
• Cada petició al servidor gt llançar una màquina
  virtual gt lentitud.
• Solució
• Un únic procès de sistema (una única màquina
  virtual) i per a cada client, crear una nova
  tasca Java (thread).Això és el que ofereix Java
  Web server.

19
Tecnologies No-Corba(IX)

• Tipus
• Servlets

20
Tecnologies No-Corba(X)

• Tipus
• Servlets
• Avantatges
• El servei als clients és més ràpid.
• Framework (conjunt de classes especialitzades)
  que facilita lescriptura dels servlets.
• Possibilitat dutilitzar tota la tecnologia i
  APIs disponibles per a Java.
• Inconvenients
• Un programa mitjanament gran, es converteix en
  totalment inmmanegable.
• Progames difíclis de depurar.

21
Tecnologies No-Corba(XI)

• Tipus
• RMI(Remoted Method Invocation)
• Què és?
• És el model de Java per desenvolupar aplicacions
  amb objectes distribuïts.
• Què permet?
• Permet a objectes Java, cridar a mètodes daltres
  objectes que estan executant-se a altres
  màquines, com si fossin crides a objectes
  definits localment per laplicació.
• El registre RMI és un servidor de noms, que
  permet als clients obtenir referències als
  objectes remots.

22
Tecnologies No-Corba(XII)

• Tipus
• RMI(Remoted Method Invocation)
• Arquitectura 3 capes
• Stubs Skeletons. Aquest Stubs y Skeletons
  permeten, que al moment de ser invocada la funció
  remota, aquesta pugui ser simulada localment.
• Referencia remota Empaqueta el mètode, arguments
  i valor de retorn.
• Transport connexió de la xarxa entre els
  sistemes.

23
Tecnologies No-Corba(XIII)

• Tipus
• RMI(Remoted Method Invocation)

24
Tecnologies No-Corba(XIV)

• Tipus
• RMI(Remoted Method Invocation)
• Avantatges
• Desenvolupament daplicacions petites és ràpid i
  senzill.
• Lexposició dels objectes remots es fa a través
  dinterfícies gt modularitat, extensibilitat,
  reutilització.
• La invocació de mètodes en objectes remots és
  transparent al programador i independent de la
  localització dels objectes.
• El registre RMI és fàcilment configurable.

25
Tecnologies No-Corba(XV)

• Tipus
• RMI(Remoted Method Invocation)
• Inconvenients
• Implementació 100 en Java gt difícil integració
  en SW ja construït.
• Pas dobjectes per valor gtsistema ineficient en
  temps.
• Rols de Client i servidor ben establerts des del
  principi gtNo afavoreix una programació totalment
  distribuïda.

26
Tecnologies No-Corba(XVI)

• Tipus
• DCOM (Distributed Component Object Model)
• Introducció
• Versió CORBA de Microsoft.
• Interfícies
• Treballa entorn a interfícies especificades
  utilitzant IDL (Interface Definition Languaje).
  Aquest IDL és incompatible amb el de CORBA.
• Aquestes interfícies són independents del
  llenguatge utilitzat per implementar la seva
  funcionalitat.

27
Tecnologies No-Corba(XVII)

• Tipus
• DCOM (Distributed Component Object Model)
• Interfícies
• Les classes DCOM en Java sencarregaran
  dimplementar aquestes interfícies.
• Sha dincloure obligatoriamnet la interfície
  IUnknown, que permet controlar el cicle de vida
  de cada objecte DCOM.

28
Tecnologies No-Corba(XVIII)

• Tipus
• DCOM (Distributed Component Object Model)

29
Tecnologies No-Corba(XIX)

• Tipus
• DCOM (Distributed Component Object Model)

30
Tecnologies No-Corba(XX)

• Tipus
• DCOM (Distributed Component Object Model)
• Avantatges
• Permet invocacions dinàmiques.
• Treballa entorn a les interfícies.
• Aconsegueix(teòricament) transparència
  local/remota.
• Ofereix un conjunt de tipus estàndard, així com
  la tècnica del marshalling.

31
Tecnologies No-Corba(XXI)

• Tipus
• DCOM (Distributed Component Object Model)
• Inconvenients
• Configuració difícil.
• No escalable.
• No es basa en un model dobjectes clàssic.
• Només suporta eines específiques de Microsoft.

32
CORBA (I)

• CORBA
• Conceptes
• Tecnologia Client/servidor
• Avantatges
• Inconvenients

33
CORBA(II)

• Conceptes
• CORBA(Common Object Request Broker Architecture)
  estàndard que serveix per a crear sistemes
  distribuïts (arquitectura de bus comú de gestió
  de peticions dobjectes)
• OMG Consorci, sense ànim de lucre, que vol
  promoure la O.O en la E.S, i establir una
  arquitectura comuna per al desenvolupament de
  programes basats en Objectes Distribuïts.

34
CORBA(III)

• Conceptes
• OMG ha definit CORBA
• Un model dobjectes.
• Com interaccionen els objectes.
• Una arquitectura del sistema que suporta la
  interacció dobjectes.
• Un llenguatge per a definir la interacció entre
  objectes.
• Serveis bàsics per a aplicacions distribuïdes.

35
CORBA(IV)

• Conceptes
• Tots els components CORBA són objectes (amb una
  interfície i identitat pròpia)
• Cada objecte es pot implementar amb un llenguatge
  de programació diferent i executar-se sobre
  qualsevol plataforma i SO.

36
CORBA(V)

• Conceptes
• Els dos elements clau de CORBA són
• ORB (Object Request Broker) és el responsable de
  permetre als objectes realitzar de forma
  transparent les invocacions i rebre les respostes
  daltres objectes en un ambient distribuït.
• IDL (Interface Definition Language) llenguatge
  despecificació dinterfícies públiques,
  independent de tot llenguatge de programació, i
  no és cap objecte de programació.

37
CORBA(VI)

• Tecnologia Client/Servidor
• Tots els serveis disponibles per als objectes
  CORBA estan definits utilitzant lIDL, que
  especifica els mètodes que els clients
  necessiten, permeten que els objectes
  simplementin en diferents llenguatges,
  facilitant així la independència de CORBA.

38
CORBA(VII)

• Tecnologia Client/Servidor
• Tant els clients com els servidors necessitaran
  uns adaptadors que transformin
• Client una invocació local a una petició a lORB
  gt stub
• Servidor una invocació de lORB a una invocació
  a un objecte del servidorgt skeletons

39
CORBA(VIII)

• Tecnologia Client/Servidor
• Tant els stubs com els skeletons utilitzaran
  marshalling procés que transformarà dades a un
  format estàndard per, posteriorment,
  transmetre-les per la xarxa.
• Només és necessari que hi hagi una versió de
  CORBA per a la plataforma on es vulgui
  implementar.

40
CORBA(IX)
41
CORBA(X)

• Avantatges CORBA
• Disponibilitat i versatilitat.
• Eficiència.
• Adaptació als llenguatges de programació.
• Inconvenients CORBA
• Complexitat.

42
Què ofereix JAVA a CORBA?

• Traslladar les aplicacions a diferents
  plataformes.
• Programació per a Internet.
• Elimina la gestió de la configuració de la part
  del client.
• Un llenguatge OO relativament senzill.
• Programació Multithreading.
• Simplifica la recollecta de les deixalles.

43
Què ofereix CORBA a JAVA?(I)

• Interfícies definides utilitzant IDL.
• Permet que les peticions es generin de forma
  dinàmica.
• Independència del llenguatge de programació.
• Transparència de localització i activació del
  servidor.

44
Què ofereix CORBA a JAVA?(II)

• Generació automàtica de codi stub i Skeleton.
• Independència del fabricant (a través dels ORBs)
  i fer portable el codi.
• Més velocitat.

45
Què ofereix CORBA a JAVA?(III)

• En definitiva, Corba ens permet programar per tal
  daconseguir funcionalitat, independència del
  llenguatge, del host o de la plataforma Hardware
  sobre la que estigui implementat.

46
Java RMI vs CORBA vs DCOM(I)

• Neutralitat de larquitectura vs Transparència en
  la comunicació
• CORBA transparència en la comunicació,
  transparència local/remota i independència de la
  plataforma.
• Java RMI proporciona una arquitectura neutral,
  transparència en la comunicació però no
  transparència local/remota.
• DCOM proporciona només suport a plataformes
  Windows.

47
Java RMI vs CORBA vs DCOM(II)

• Independència del llenguatge
• CORBA i DCOM sutilitza en diferents llenguatges
• Java RMI només en Java.
• Pas per valor/referencia
• CORBA no suporta el pas dobjectes per valor.
• Java RMI i DCOM sí que ho suporten.

48
Java RMI vs CORBA vs DCOM(III)

• Simplicitat en el desenvolupament daplicacions
• Las aplicacions distribuïdes es construeixen
  fàcilmente amb DCOM i Java, degut a que
  existeixen eines disponibles per al
  desenvolupament de les aplicacions.
• CORBA no té aquesta facilitat i així és difícil
  construir aplicacions CORBA.

49
Java RMI vs CORBA vs DCOM(IV)

• Recollecta de deixalles
• DCOM i els objectes Java tenen recollecció de
  deixalles.
• CORBA no ho té.
• ...

50
Bibliografia

• http//java.sun.com
• http//www.corba.org
• http//www.omg.org/corba
• http//www.javaworld.com
• internet...