patrón objeto activo

ESCUELATCNICASUPERIORDEINGENIERADETELECOMUNICACIN

UNIVERSIDADPOLITCNICADECARTAGENA

PROYECTOFINDECARRERA

PATRNOBJETOACTIVO:

SERVIDORMULTIMEDIACONC#

AUTOR:MarioLpezMompen

DIRECTOR:JuanngelPastorFranco

3

Autor MarioLpezMompen

Emaildelautor [email protected]

Director JuanngelPastorFranco

Emaildeldirector [email protected]

TtulodelPFC PatrnObjetoActivo:ServidorMultimediaconC#

Descriptores

Resumen

SedisearunaaplicacinsobreVisualStudio2003.Usarelpatrnobjetoactivo y el lenguaje de programacin C# de la plataforma .NET. Estaaplicacinserunservidordearchivosmultimedia,permitiendoladescarga,lasubidaylareproduccindevideosporpartedelosclientes.

Titulacin IngenieroTcnicodeTelecomunicacin,

espacialidadTelemtica

Intensificacin

Departamento TecnologadelaInformacinylasComunicaciones

Fechadepresentacin Diciembre 2007

5

ndice

Captulo1:Introduccin..................................................................11 1.1.Antecedentes,contexto..11 1.2.Trabajoplanteado,objetivos,motivaciones.12 1.3.Contenidoyalcancedeestedocumento12

Captulo2:.NETFramework.........................................................15 2.1.Objetivosyprincipalescaractersticas.....15 2.2.Arquitectura....16 2.2.1.CLI....17 2.2.2.Ensamblados....17 2.2.3.Metadatos..18 2.2.4.Libreradeclases...18 2.2.5.Seguridad.18 2.2.6.Manejodelamemoria..19 2.3.CLR:Lenguajecomnentiempodeejecucin......20 2.4.Bibliotecadeclases.NET.21 2.5..NETyJAVA.....22 2.6.Inconvenientesde.NET...23

Captulo3:Patrndediseoobjetoactivo......................................25 3.1.Ejemplodelgateway............................................................................... 25 3.2.Contexto.................................................................................................... 26 3.3.Problema................................................................................................... 26 3.4.Solucin...................................................................................................... 27 3.5.Estructura................................................................................................... 27 3.6.Dinmica.................................................................................................. 30 3.7.Implementacin......31 3.7.1.Implementarelservant.........31 3.7.2.Implementarelproxyylosmethodrequests............ 32 3.7.3.Implementarlaactivationlist................34 3.7.4.Implementarelscheduler.............35 3.7.5.Concretarelfutureycmoaccederal..........37

Captulo4:Paquetesylibreras.......................................................39 4.1.Paquetesexternos..........................................................................................39 4.2.Paquetesdesarrollados............................................................................ 39

6

Captulo5:Implementacindelpatrn...........................................41 5.1.Problemasencontrados........................................................................... 41 5.1.1.Referentesallenguaje.............................................................. 41 5.1.2.Referentesalpatrn.................................................................. 42 5.2.Organizacindelcdigo........................................................................... 43 5.2.1.Proxyyskeleton.43 5.2.2.Futureymethodrequests..44 5.2.3.Scheduler.................................................................................. 44 5.2.4.Activationlist............................................................................. 44 5.2.5.Servant....................................................................................... 45 5.3.Dinmica................................................................................................... 45 5.3.1.Arranquedelosprogramas........................................................ 45 5.3.2.Comunicacionesproxyskeleton.............................................. 46 5.3.3.Objetoactivo............................................................................. 48 5.3.4.Comunicacionesobjetoactivoproxy....................................... 48 5.3.5.Otros........................................................................................ 52 5.4.Implementacin...................................................................................... 53 5.4.1.Proxyyskeleton........................................................................ 53 5.4.2.Futureymethodrequests......................................................... 56 5.4.3.Scheduler.................................................................................. 59 5.4.4.Activationlist............................................................................. 60 5.4.5.Servant..................................................................................... 61

Captulo6:Plandeprcticas............................................................63 6.1.Prctica1:Sistemadepasodemensajes.................................................. 64 6.1.1.Objetivosdelaprctica.............................................................. 64 6.1.2.Contenidos............................................................................... 64 6.1.3.Especificacindelosrequisitosdelaaplicacin........................... 65 6.1.4.Diseo...................................................................................... 65 6.1.5.Implementacin........................................................................ 66 6.2.Prctica2:Sistemadepasodemensajesconsockets................................ 67 6.2.1.Objetivosdelaprctica.............................................................. 67 6.2.2.Contenidos............................................................................... 67 6.2.3.Especificacindelosrequisitosdelaaplicacin........................... 67 6.2.4.Diseo...................................................................................... 68 6.2.5.Implementacin........................................................................ 70 6.3.Prctica3:Sistemadevideo.Estructurabsica.......................................... 71 6.3.1.Objetivosdelaprctica.............................................................. 71 6.3.2.Contenidos............................................................................... 71 6.3.3.Especificacindelosrequisitosdelaaplicacin........................... 71 6.3.4.Diseo...................................................................................... 72 6.3.5.Implementacin........................................................................ 74

7

6.4.Prctica4:Sistemadevideo.Aplicacinfinal............................................. 75 6.4.1.Objetivosdelaprctica.............................................................. 75 6.4.2.Contenidos................................................................................ 75 6.4.3.Especificacindelosrequisitosdelaaplicacin........................... 75 6.4.4.Diseo....................................................................................... 76 6.4.5.Implementacin........................................................................ 77

Captulo7:Manualdeusuario.........................................................79 7.1.Servidor................................................................................................... 79 7.2.Cliente........................................................................................................ 80

Captulo8:Conclusionesytrabajosfuturos.....................................83 8.1.Conclusiones........................................................................................... 83 8.2.Trabajosfuturos....................................................................................... 83

Captulo9:Bibliografayreferencias...............................................85

Anexo1:Glosariodetrminosysiglas.............................................87

9

ndicedefiguras

Captulo2Figura1:EstructurabsicadeCLI................................................................................ 17Figura2:Bibliotecadeclasesde.NETFramework........................................................ 22

Captulo3Figura3:Ejemplogateway.......................................................................................... 25Figura4:Estructuradelpatrnobjetoactivo................................................................ 29Figura5:Diagramadesecuenciadelpatrnobjetoactivo............................................. 30

Captulo5Figura6:Estructuradelskeleton................................................................................. 43Figura7:Estructuradelscheduler............................................................................... 44Figura8:Estructuradelservant................................................................................... 45Figura9:Secuenciadearranquedelservidor............................................................... 46Figura10:Secuenciadearranquedelcliente................................................................ 46Figura11:Secuenciadeconexindelproxyconelskeleton......................................... 46Figura12:Secuenciadepeticin................................................................................. 47Figura13:Secuenciadeextraccindepeticin............................................................. 48Figura14:Secuenciadeejecucindelapeticindevisionado...................................... 49Figura15:Secuenciadeejecucindelapeticindedescarga........................................ 50Figura16:Secuenciadeejecucindelapeticindesubida........................................... 51Figura17:Secuenciadeconfiguracin......................................................................... 52Figura18:Interfazdelproxy........................................................................................ 53Figura19:Interfazdelskeleton................................................................................... 54Figura20:Interfazdemethodrequest........................................................................ 56Figura21:interfazdelapeticinverVideo................................................................... 57Figura22:InterfazdelapeticintransferirArchivo....................................................... 57Figura23:InterfazdelapeticinrecibirArchivo............................................................ 57Figura24:Interfazdelfuture....................................................................................... 58Figura25:Interfazdelscheduler................................................................................. 59Figura26:Interfazdelaactivationlist.......................................................................... 60Figura27:InterfazdelobjetoPeticion......................................................................... 60Figura28:Interfazdeliterador.................................................................................... 61Figura29:Interfazdelservant..................................................................................... 61

Captulo6Figura30:Estructuradelaprctica1........................................................................... 65Figura31:Interfazgrficadelaprctica1.................................................................... 66Figura32:Estructuradelprogramaclientedelaprctica2............................................ 68Figura33:Interfazgrficadelprogramaclientedelaprctica2..................................... 68

10

Figura34:Estructuradelprogramaservidordelaprctica2......................................... 69Figura35:Interfazgrficadelprogramaservidordelaprctica2................................... 69Figura36:Interfazgrficadelprogramaservidordelaprctica3................................... 72Figura37:Paneldeconfiguracindelservidordelaprctica3...................................... 72Figura38:Interfazgrficadelprogramaclientedelaprctica3..................................... 73Figura39:Paneldeconfiguracindelclientedelaprctica3........................................ 74Figura40:Interfazgrficadelprogramaservidordelaprctica4................................... 76Figura41:Interfazgrficadelprogramaclientedelaprctica4..................................... 76

Captulo7Figura42:Ventanaprincipaldelservidor..................................................................... 79Figura43:Ventanadeconfiguracindelservidor......................................................... 80Figura44:Ventanaprincipaldelcliente....................................................................... 81Figura45:Ventanadeconfiguracindelcliente........................................................... 82

11

Captulo1:IntroduccinElobjetivoprincipalde lascomunicacionesesel intercambiode informacin,perosialgohacambiadoenlosltimosaoseseltipodeinformacinquesolicitanlosusuariosdeinternet.DesdelapuestaenmarchadelaplataformaconocidacomoWeb2.0,cuyapropuestaesdarunprotagonismo a los usuarios que antes no tenan convirtindolos en generadores decontenidosydndoles lacompleta libertaddepoderelegir la informacinquequierenver,ygraciasaloscadavezmsgrandesanchosdebandadequesedisponen,sehanpopularizadoenInternetmultituddeserviciosqueantesseconsiderabaninconcebibles.Hacepocomsde10aosquesepusoenmarcha la internet talcomo laconocemoshoyenda,perohasidocosadeestosltimosaosenquehahabidounaexplosindeservicios, llevando internetaalgo ms que un conjunto de pginas web, correos electrnicos, servidores de noticias ydems servicios bsicos. No hace demasiado que existen directorios de fotografassuministradasyorganizadaspor lospropiosusuarios,oautnticasenciclopediasenmultituddeidiomascuyoscontenidossonaportadosporusuariosdesinteresados.

1.1.Antecedentes,contexto

SihayunservicioquerealmentehaexplotadoaprovechandoloscadavezmayoresanchosdebandaylasredessocialescaractersticasdelaWeb2.0hasidoeldedifusindevideo.

Han aparecidomultitud de empresas que ofrecen este servicio y cada una tiene su propiomodelodenegocio,loquedejapatentequetodavanoesttodoinventadoperoquealavezcadanuevaempresadebedarleunavueltamsdetuercaalmercadoparapoderdesmarcarse.Probablementelosmodelosmsextendidosenlaactualidadseanlosquecobranunacuotademantenimiento por alojar y difundir los videos o los que hacen esto a cambio de incluirpublicidad de una forma ms o menos encubierta. Y al final de tantas opciones, eldenominador comn es el mismo, al final son los propios usuarios quienes generan elcontenidoyquienesdecidenqumerecelapenaservisto.

UnapruebadequeesteesunmercadoconmuchasposibilidadeseslacompradeYouTubeporpartedeungigantecomoGooglepor1650millonesdedlares.Cifraelevadaparaunportalconpocosaosdevidaquetodoloqueofreceesquelosusuariospuedancolgarsusvideosyque otros los vean. Probablemente lo quems llama la atencin de esta compra sea queGoogleyadisponadesupropioportalcon losmismosserviciosqueYouTubeperoconunadiferencia:elnmerodeusuarios.Enunserviciodondeson losusuariosquienesproveendecontenido,cuantosmsusuariostengas,msgarantastienesquetunegociovayaacrecerygenerarbeneficios.

Estossonnegociosconfinescomerciales,perolaideadeladifusindevideoesinteresanteamuchosniveles:medicina,reunionesvirtuales,entretenimientoEnelmbitouniversitariosepodrautilizarparalaeducacinadistanciaoparaampliarlosconocimientosdelalumnomsalldeloslibros:conferenciasdeprofesores,clases

12

1.2.Trabajoplanteado,objetivos,motivaciones

Dado el cada vez mayor nmero de posibilidades de eleccin donde albergar contenidomultimedia para su difusin, quizs haya llegado elmomento de pensar si no seramejorutilizarunaopcinnotanmasificada,unserviciomsbienprivadoyqueslollegueaaquellaspersonasquerealmenteinteresequellegue.

Conesta ideaenmente,podraser interesanteconstruirunsistemapropioparaestefin.Enproyectos anteriores esto ya se ha hecho aunque de una forma ms rudimentaria y enlenguajeJava.Enesteproyectosepropone llevarestosproyectosunpasomsallyademsportarlosaC#.Paraconseguiresto,esteproyectosevaacentrarmsen losmedioscon losque losusuariosrecibirn losvideosqueenelfinmismode latransmisindevideo,yesporelloporloquetodogiraentornoalpatrnobjetoactivo.

Objetivos:

ProporcionarejemplosdeutilizacindellenguajeC#ydelentornodedesarrollo.NETparaladocenciadelreaLSI.

Proporcionarunadescripcinencastellanodelpatrnapartirdeloriginaleningls. Proporcionar una implementacin del patrn Objeto Activo en el lenguaje C# y

documentarladeformaquesirvaalosobjetivosdocentesdelrea.

Proporcionar una aplicacinmultimedia en el entorno .NET que utilice el patrn antesmencionado.

1.3.Contenidoyalcancedeldocumento

Captulo1:Introduccin,quesesubdivideentresapartados:

Antecedentes, contexto: Se hace breve introduccin del mercado multimediadisponibleeninternetycmohallegadohastaaqu.

Trabajoplanteado,objetivos,motivaciones:Sedescribenlosmotivosylasmetasquepersigueesteproyecto.

Contenidoyalcancedeldocumento:Sedescribelaestructuradeldocumento.

Captulo 2: Tecnologa .NET, se realiza un pequeo resumen de las caractersticas de latecnologa.NET.

Objetivosyprincipalescaractersticas.Detallesdelamotivacinparacrear.NET. Arquitectura.Resumendelaarquitecturaenlaquesebasa.NET.

13

Captulo 3: Patrn objeto activo, explicacin detallada de la estructura bsica del patrnobjetoactivo.

Ejemplo del Gateway: Presentacin del caso terico sobre el que se explicar elpatrn.

Contexto:Escenariosobreelqueactaelpatrn. Problema:Resumendelproblemaqueintentasolucionar. Solucin:Sedetallacmoelpatrnsolucionarlosproblemasplanteados. Estructura: Consta de varios apartados, cada uno dedicado a un componente del

patrn.Detallalaestructuradecadauno. Dinmica:Explicalasfasesenquesedivideelpatrnsegnloqueesthaciendo. Implementacin:Al igualque laestructura,dedicaunapartadoa la implementacin

decadacomponentedelpatrnenelcasoconcretodelgateway.

Captulo4:Paquetesy libreras,estecaptulovadestinadoa identificar lospaquetesusadosenelproyectoajenosalosde.NETyalospaquetesenquesevaaorganizarelcdigo.

Paquetesexternos: Librerasypaquetesexternosa .NETque sehan incorporadoalproyecto.

Paquetesdesarrollados:Paquetesenquesehaorganizadoelcdigo.

Captulo 5: Implementacin del patrn, se divide en cuatro apartados y detalla todos losaspectosdelaaplicacinconstruida.

Problemas encontrados: Resumen de los problemas encontrados antes, durante ydespus de la implementacin del cdigo. Se divide en los problemas debidos a laestructuradelpatrnylosproblemasdebidosallenguajeC#.

Organizacindelcdigo:Seresumecmovaaestarorganizadoelcdigo. Dinmica:Diagramasdesecuenciadelfuncionamientodelpatrnydearranquedelos

programas.

Implementacin:Explicacindelcdigo.Captulo6:Plandeprcticas,completoplandeprcticasparaconstruirlaaplicacinenvariospasos.

Prctica1:Sistemadepasodemensajes Prctica2:Sistemadepasodemensajesconsockets Prctica3:Sistemadevideo.Estructurabsica Prctica4:Sistemadevideo.Aplicacinfinal

Captulo7:Manualdeusuariocompletodelosdosprogramas.

Servidor:Configuracinypuestaenmarchadelprogramaservidor. Cliente:Configuracinypuestaenmarchadelprogramacliente

14

Captulo8:Conclusionesy trabajos futuros, resumende losobjetivos cumplidos yposiblesvasdeactuacinymejoradelaaplicacin.Captulo9:Bibliografayreferencias

Anexo1:Glosariodetrminosysiglas

15

Captulo2:.NETFramework

LanuevatecnologadeMicrosoftofrecesolucionesalosproblemasdeprogramacinactuales,como son la administracinde cdigo o laprogramacinpara Internet. Para aprovechar almximolascaractersticasde.NETesnecesarioentenderlaarquitecturabsicaenlaqueestaimplementadaesta tecnologayasbeneficiarsede todas las caractersticasqueofreceestanuevaplataforma.

El Framework de .NET es una infraestructura sobre la que se rene todo un conjunto delenguajes y servicios que simplifican enormemente el desarrollo de aplicaciones.Medianteestaherramientaseofreceunentornodeejecucinaltamentedistribuido,quepermitecrearaplicacionesrobustasyescalables.Losprincipalescomponentesdeesteentornoson:

Lenguajesdecompilacin Bibliotecadeclasesde.NET CLR(CommonLanguageRuntime)

Actualmente,elFrameworkde .NETesunaplataformano incluidaen losdiferentessistemasoperativos distribuidos por Microsoft, por lo que es necesaria su instalacin previa a laejecucin de programas creados mediante .NET. El Framework se puede descargargratuitamente desde la web oficial de Microsoft (ver link de descarga en el captulo debibliografa[1]).

.NETFrameworksoportamltiples lenguajesdeprogramacinyaunquecada lenguaje tienesuscaractersticaspropias,esposibledesarrollarcualquiertipodeaplicacinconcualquieradeestoslenguajes.Existenmsde30lenguajesadaptadosa.NET,desdelosmsconocidoscomoC#(CSharp),VisualBasicoC++hastaotroslenguajesmenosconocidoscomoPerloCobol.

2.1.Objetivosyprincipalescaractersticas

Latecnologa.NETseplantelossiguientesobjetivos:

Interoperabilidad. La interaccin entre nuevas y viejas aplicaciones eran unaexigencia,porloque.NETdebaofrecermediosparapoderinteractuarconprogramasqueseejecutandeformaexternaalentorno.NET.

Unentornocomndeejecucin.Loslenguajessoportadossecompilanenunlenguajeintermedio conocido como Common Intermediate Language (CIL) o MicrosoftIntermediateLanguage(MSIL).Sinembargo,estecdigonoesinterpretadodurantelaejecucin,sinoqueserecompiladurantelafasedeejecucinmediantecompiladoresjustintime en cdigo nativo. Este modo de funcionamiento se conoce como

16

CommonLanguage Infrastrcture(CLI)yenelcasoparticulardeMicrosoftharecibidoelnombredeCommonLanguageRuntime(CLR).

Independenciadellenguaje.LaindependenciaseconsiguemediantelaespecificacinCommonTypeSystem(CTS).Enellasedefinentodoslostiposdedatosposibles,todoslos operadores y cmo actan unos sobre otros en caso de ser posible estainteraccin.Porestarazn,.NETsoportadesarrollosenvarioslenguajes.

Libreradeclasesbsicas.Estalibreradeclasesformapartedelaplataformayofrecetodas sus funciones a todos los lenguajes que la usan. Proporciona clases queencapsulanfuncionesdeusocomn,comolecturayescrituradeficheros,tratamientodeimgenes,comunicacinconbasesdedatosymanipulacindedocumentosXML.

Instalacin simplede losprogramas creadosdesde laplataforma. La instalacindecualquier software debe realizarse cuidadosamente para que asegurar que nointerfiere con software instalado previamente y que cumple los requisitos deseguridadadecuados.En .NET se incluyenherramientasqueayudana cumplirestosrequisitos.

Seguridad.Evitarvulnerabilidadesdebeserunaprioridad,porejemplo lasrelacionescondesbordamientosdebuffersondemasiadopeligrosasyfcilmenteaprovecharporcdigomalicioso,porloquesedebenevitaratodacosta.Porello.NETproporcionaunmodelodeseguridadcomnparatodaslasaplicaciones.

Portabilidad.Unade lasmetasde laplataformaespermanecer independientede laplataformadesde laqueseejecuta.Estosignificaqueunaaplicacinescritaen .NETdebera poder ejecutarse en cualquier mquina donde est implementada laplataforma. En el momento de escribir este documento, solamente los sistemasoperativosWindowsyWindowsCEsoportanplenamentetodaslasfuncionesde.NET.Microsoft tambin ha liberado implementaciones que funcionen sobre algunossistemasbasadosenUnixcomoFreeBSDyMacOSXbajo licenciasqueslopermitensu uso para propsitos educativos nicamente. Adems Microsoft envi laespecificacin del CLI, el lenguaje C# y el conversor C++/CLI para convertirlos enestndares abiertos. Esto hace posible que se puedan realizar implementacionescompatiblesdelaplataformaencualquiersistemaoperativoosistemaquesedesee.

2.2.Arquitectura

Enesteapartado se vanadetallar los componentesms importantesde laarquitecturade.NET. Se dejarn un par de casos para apartados posteriores por considerarlos losuficientementeimportantescomoparaentrarenprofundidad.

17

2.2.1.CLI

Elncleode.NETrespetalaestructuratipoCLI.ElpropsitodeCLIesproporcionarunentornoindependientedel lenguajedeprogramacinparaeldesarrollo yejecucinde aplicaciones,incluyendofuncionesparaeltratamientodeexcepciones,recoleccindebasura,seguridadeinteroperabilidad. La implementacin que utiliza Microsoft de la estructura CLI recibe elnombredeCLR.LasiguientefiguramuestralaestructurabsicadeCLI:

Figura1:EstructurabsicadeCLI

2.2.2.Ensamblados

Unodelosmayoresproblemasdelasaplicacionesactualesesqueenmuchoscasostienenquetratarcondiferentesarchivosbinarios (DLLs),elementosde registro,conectividadabiertaabasesdedatos(ODBC),etc.

ParasolucionarloelFrameworkde.NETmanejaunnuevoconceptodenominadoensamblado.LosensambladossonficherosconformadeEXEoDLLquecontienentodalafuncionalidaddelaaplicacindeformaencapsulada.Portantolasolucinalproblemapuedesertanfcilcomocopiartodoslosensambladoseneldirectoriodelaaplicacin.

Con losensambladosyanoesnecesario registrar loscomponentesde laaplicacin.Esto sedebeaquelosensambladosalmacenandentrodesmismostodalainformacinnecesariaenloquesedenominaelmanifiestodelensamblado.Elmanifiestorecogetodos losmtodosy

18

propiedadesenformademetadatosjuntoconotra informacindescriptiva,comopermisos,dependencias,etc.

Para gestionar el uso que hacen la aplicaciones de los ensamblados .NET utiliza la llamadacach global de ensamblados (GAC, Global Assembly Cache). As, .NET Framework puedealbergarenelGAC losensambladosquepuedanserusadosporvariasaplicacionese inclusodistintasversionesdeunmismoensamblado,algoquenoeraposibleconelanteriormodeloCOM.

2.2.3.Metadatos

TodocdigoCILesautosuficientegraciasalosmetadatos.ElCLRcompruebaenlosmetadatosque se est llamando al mtodo correcto. Normalmente estos metadatos los genera elcompilar,aunqueesposiblequeelprogramadorpueda crear los suyospropiosa travsdeatributospersonalizables.

2.2.4.Libreradeclases

Existendoslibrerasdeclases.Porunladoseencuentralalibrerabsica,queincluyetodaslasclasesdetodosloslenguajessoportados.EstaseconocecomoBaseClassLibrary(BCL).Esmsgrandequeotraslibrerasdeestetipo,perotambinincluyemuchasmsfuncionesenunsolopaquete.Avecesesta libreraseconfundecon la libreraque incluyeademsde lasbsicas,todaslasclasesdelespaciodenombresdeMicrosoft.[2].EsteconjuntodeBCLyelespaciodenombresdeMicrosoftsellamaFrameworkClassLibrary(FCL).

Enunapartadoposteriorseentrarendetalleenestepunto.

2.2.5.Seguridad

.NETtienesupropiomecanismodeseguridad.Tienedoscaractersticasprincipales:

CodeAccessSecurity (CAS).Sebasaencierta informacin,evidence,asodicadaaunensamblado especfico. Esta informacin determinar la fuente desde la que seejecutaelensamblado,siest instaladoen lapropiamquinaosisehadescargadodesdeuna intranetodesde internet.Apartirdeesta informacin,CASdetermina lospermisospermitidos al cdigo.Cuando sehaceuna llamadaque requierepermisosespecficos,desdeelCLRserealizaunabsquedaencadaensambladoquetengaunmtodoen lacolade llamadas,siningunodeestosensambladostienepermisopararealizarlallamadaselanzaunaexcepcindeseguridad.

19

Validacin y verificacin. Cuando se carga un ensamblado, el CLR realiza variascomprobaciones.Dosdeellas se conocen comovalidacinyverificacin.Durante lafasedevalidacinsecompruebaqueelensambladocontienemetadatosvlidosyquelastablasinternasestncorrectas,esdecir,compruebaquenohasidomodificado.Laverificacinbuscasielcdigopuederealizaroperacionesnoseguras.Lacomprobacines muy restrictiva y puede dar lugar a que cdigo seguro sea catalogado comoinseguro. El cdigomarcado como inseguro slo se ejecuta si se otorga permiso alensambladoparaque se salte la fasede verificacin. El cdigoque se instala en lamquina desde la que se ejecuta normalmente permite la ejecucin de cdigoinseguro.

Comopuntofinal,otracaractersticaqueincorpora.NETeslaposibilidaddeotorgarpermisossegnpordominios.As,notoda laaplicacintiene losmismospermisosentodas laspartes.Estos dominios se conocen como appdomains. Esto mejora la tolerancia a fallos de laaplicacin y evita que un fallo en un dominio afecte al resto. Estos dominios se han deestablecerporelprogramador.

2.2.6.Manejodelamemoria

En el apartadodemanejode lamemoria, .NET funcionadeuna forma similarde JAVA. Seliberaalprogramadordelastareasdemanejodelamemoria,automatizandolosprocesosdereserva y liberacin de sta. El proceso de reserva de memoria lo realiza el CLR. Estecomponenteguardaunespacioyvaasignandomemoriaalosobjetosquevancrendose.Losobjetossecolocanunoal ladodelotroen lamemoria,sindejarespaciosentreellos.Cuandoesteespaciose llenasereservams.Mientrasexistaunareferenciaacualquierobjetoenelespacio reservado por el CLR, se considera que el objeto est en uso por l. Cuando seeliminan todas las referenciasaunobjetoynoesposibleusarloniaccederaldeningunamanera, se vuelvebasura. Sin embargo, sigueocupando el espaciodememoriaque le fueasignado.Paraliberarlamemoriautilizadapordatosbasuraseutilizaelrecolectordebasura.

Este recolector seejecutaperidicamenteenunhilo separadoalde laaplicacin.Seactivaslocuandounaciertacantidaddememoriahasidousadaosiseest llenando lamemoriaquereservelCLR.Comoelmomentoenelquevaaentrarenfuncionamientoelrecolectornoestapriorideterminado,sedenominaqueesejecutadeunaformanodeterminista.

Todaaplicacin .NETtieneunaseriedepunterosmantenidosporelCLRqueapuntanacadaobjetoenmemoria.Estos incluyenreferenciasaobjetosestticosyaobjetosdefinidoscomovariableslocales,parmetrosdemtodosenusouobjetosreferenciadosporlosregistrosdelaCPU. Cuando el recolector entra en funcionamiento, pausa la aplicacin y por cada objetoreferenciadoporunpuntero, recorre todos losobjetosque sepueden llegara travsdel.Tambin es capaz de recorrer objetos encapsulados dentro de otros objetos gracias a losmetadatosyrecorrerlosqueestnrelacionadosconellos.Mientrasrecorretodoslosobjetosa losquepuede llegarutilizando lospunterosdelCLRytodassusramificacionestambin losmarcarcomoReachable(alcanzable).Unavezhechoesto,recorretodoslosobjetosquehayen

20

memoriamarcandocomobasuraaquellosquenoestnmarcadoscomoalcanzables.Estaeslafasedemarcado.Losobjetosmarcadoscomobasurasetratanapartirdeaqucomoespaciosde memoria libres. Pero como a los nuevos objetos se les asigna memoria al lado de losltimos que se crearon, estos espacios dememoria libre no son aprovechables tal cual. Esnecesariounprocesodecompactacindelamemoriaparaquetodoslosobjetosestnjuntosdenuevo.

Paramejorar laeficiencia,elrecolectordebasuraesgeneracional.Atodos losobjetosse lesasignaunageneracin yen funcindesta, son recolectadosmsomenosamenudo. Losobjetos nuevos tienen generacin 0. Los que sobreviven a un recolector de basura, se lesasigna lageneracin1y losquesobrevivenaunsegundorecolectorson losdegeneracin2,nohaymsniveles.Losarchivosdemayorgeneracinsonrecolectadosmenosamenudo,yaquesonobjetosquetienenuntiempodevidamslargo.Asseaceleraelfuncionamientodelrecolectoraleliminarlosobjetosmsviejosdeunaejecucin,puessetienenquecomprobar,marcarycompactarmenosobjetos.

2.3.CLR:Lenguajecomnentiempodeejecucin

ElCLReselverdaderoncleodelFrameworkde.NET,yaqueeselentornodeejecucinenelquesecargan lasaplicacionesdesarrolladasen losdistintos lenguajes,ampliandoelconjuntodeserviciosqueofreceelsistemaoperativo.

Secomponeprincipalmentedecuatropartes:

CommonTypeSystem(CTS).Entrminosgenerales,describeeltratamientodetodoslos tipos de datos que deben soportan todos los lenguajes .NET. Su funcin esestableceruna integracinmultilenguajeseguraydealto rendimiento,proporcionarun modelo orientado a objetos y definir reglas para la interaccin entre distintoslenguajesdeprogramacin.

Common Language Specification (CLS). Conjunto de tipos y operaciones que debensoportartodosloslenguajescompatiblescon.NET.

JustInTimeCompiler(JIT).Compiladorentiempodeejecucin,transformaelcdigoenMSILacdigonativodelamquina.

VirtualExecutionSystem(VES).ProporcionalonecesarioparamanejarcdigoenMSIL.La herramienta de desarrollo compila el cdigo fuente de cualquiera de los lenguajessoportadospor .NET enunmismo cdigo,denominado cdigo intermedio (MSIL,MicrosoftIntermediate Language). Para generar dicho cdigo el compilador se basa en el CommonLanguage Specification (CLS) que determina las reglas necesarias para crear cdigo MSILcompatibleconelCLR.

21

De esta forma, indistintamente de la herramienta de desarrollo utilizada y del lenguajeelegido, el cdigo generado es siempre elmismo, ya que elMSIL es el nico lenguaje queentiendedirectamenteelCLR.Estecdigoestransparentealdesarrollodelaaplicacinyaquelogeneraautomticamenteelcompilador.

Sin embargo, el cdigo generado en MSIL no es cdigo mquina y por tanto no puedeejecutarsedirectamente.Senecesitaunsegundopasoenelqueunaherramientadenominadacompilador JIT (JustInTime)generaelcdigomquina realqueseejecutaen laplataformaquetengalacomputadora.

As se consigue con .NET cierta independencia de la plataforma, ya que cada plataformapuedetenersucompiladorJITycrearsupropiocdigomquinaapartirdelcdigoMSIL.

LacompilacinJITlarealizaelCLRamedidaqueseinvocanlosmtodosenelprogramay,elcdigo ejecutable obtenido, se almacena en la memoria cach de la computadora, siendorecompiladoslocuandoseproducealgncambioenelcdigofuente.

2.4.Bibliotecadeclasesde.NET

Cuandoseestprogramandounaaplicacinmuchasvecessenecesitanrealizaraccionescomomanipulacin de archivos, acceso a datos, conocer el estado del sistema, implementarseguridad, etc. El Framework organiza toda la funcionalidad del sistema operativo en unespaciodenombresjerrquicodeformaquealahoradeprogramarresultabastantesencilloencontrarloquesenecesita.

Para ello, el Framework posee un sistema de tipos universal, denominado Common TypeSystem (CTS). Este sistemapermiteque elprogramadorpueda interactuar los tiposque seincluyenenelpropioFramework (bibliotecadeclasesde .Net)con loscreadosporlmismo(clases).De esta forma se aprovechan las ventajas propias de la programacin orientada aobjetos,como laherenciadeclasespredefinidasparacrearnuevasclases,oelpolimorfismodeclasesparamodificaroampliarfuncionalidadesdeclasesyaexistentes.

Labibliotecadeclasesde.NETincluye,entreotros,trescomponentesclave:

ASP.NETparaconstruiraplicacionesyserviciosWeb. WindowsFormsparadesarrollarinterfacesdeusuario. ADO.NETparaconectarlasaplicacionesabasesdedatos.

22

Figura2:Bibliotecadeclasesde.NETFramework

La forma de organizar la biblioteca de clases de .NET dentro del cdigo es a travs de losespaciosdenombres(namespaces),dondecadaclaseestorganizadaenespaciosdenombressegnsu funcionalidad.Porejemplo,paramanejar ficherosseutilizaelespaciodenombresSystem.IOysi loquesequiereesobtener informacindeunafuentededatosseutilizarelespaciodenombresSystem.Data.

Laprincipalventajadelosespaciosdenombresde.NETesquedeestaformasetienetodalabliblioteca de clases de .NET centralizada bajo el mismo espacio de nombres (System).Adems,desdecualquier lenguajeseusa lamismasintaxisde invocacin,yaqueatodos loslenguajesseaplicalamismabibliotecadeclases.

2.5..NETyJava

Latecnologa.NETyJavatienenmuchospuntosencomn[3]:

Utilizan mquinas virtuales que ocultan los detalles del hardware sobre el quefuncionan.

Usancdigointermedio.BytecodesenelcasodeJava,MSILenelcasode.NET. ElcdigoMSILessiemprecompiladoantesdelaejecucin.Losbytecodesademsde

compilado,puedeserinterpretado.

Proporcionan grandes libreras de clases con todas las necesidades habituales yacubiertas,incluidalaseguridad.

El espacio de nombres de .NET es bastante similar al sistema de paquetes de laespecificacindelaAPIJavaEEtantoenestilocomoeninvocacin.

23

Hastaaqulassimilitudes.Lasdiferenciassepuedenresumirenvariospuntos:

.NETsloestcompletoparaWindows,existeuna implementacinparcialenLinuxyMACOSX.Javaestcompletamentesoportadoenestastresplataformas,ademsdemuchasmsotras.

.NET tiene soporte nativo paramltiples lenguajes,mientras que en JAVA esto fueaadidoaposterioriysuusoesmnimo.

Javaestbajolicenciasdelibredistribucinyesdecdigoabierto,mientrasque.NETestbajolicenciasquerestringensuuso.

2.6.Inconvenientesde.NET

Procesos como la recoleccin de basura de .NET o la administracin de cdigo introducenfactoresdesobrecargaquerepercutenenlademandademsrequisitosdelsistema.

Elcdigoadministradoproporcionaunamayorvelocidaddedesarrolloymayorseguridaddeque el cdigo seabueno. En contrapartida el consumode recursosdurante la ejecucin esmuchomayor,aunqueconlosprocesadoresactualesestocadavezesmenosinconveniente.

Elniveldeadministracindelcdigodependerengranmedidadel lenguajequeutilicemospara programar. Por ejemplo, mientras que Visual Basic .Net es un lenguaje totalmenteadministrado,C#permite laadministracinde cdigode formamanual, siendopordefectotambinunlenguajeadministrado.MientrasqueC++esunlenguajenoadministradoenelquesetieneuncontrolmuchomayordelusodelamemoriaquehacelaaplicacin.

25

Captulo3:Patrnobjetoactivo

Elpatrnobjetoactivo[4][5]seenglobaen lospatronesdeconcurrencia.Tieneporobjetivodarordenymejorarlaconcurrenciaenelaccesoaunobjetodesacoplandolainvocacindeunmtododeesteobjetodesuejecucin.Deestaformasemejoralaconcurrencia,puesvarioshilospuedenaccederalobjeto intercaladamente,y lasincronizacin,puesslounodeellosactasobreelobjetocadavez.Aestepatrntambinseleconocecomoobjetoconcurrenteoeninglsactiveobjectoconcurrentobject.

Tratardeexplicarunpatrndediseosindarunejemplodeusoparacomprenderelproblemaqueintentadarsolucinseraunalaborcompleja,porloqueseutilizarunejemploalolargodelaexplicacindelpatrn.Esteejemploconsistirdeungatewayenunsistemadepasodemensajes.Medianteesteejemplo serbastantems sencillocomprenderelpatrnyelporqutienelaestructuraquetiene.

Antesdeempezar,hayqueaclararqueungatewaycumplelafuncindeinterconexinentrediferentesdispositivosoredes.Porlotanto,elobjetoactivoserestegateway,mientrasquelosdispositivosomquinasconectadasaltendrnlafuncindeclientes.

3.1.Ejemplo:gateway

Estegatewaydecomunicacionespermitelacooperacinentretodosloscomponentessinquehayadependenciasdirectasentreellos.Esunsistemadistribuido,porloqueelgatewaydebesercapazde llevar losmensajesdesde losproveedoreshastatantasmquinasdestinocomoseannecesarias.Enlafigurainferiorsemuestraunaposibleestructura:

Figura3:Ejemplogateway

Se va a suponer que todas las partes se comunican entre s mediante el protocolo TCPaprovechando que es un protocolo orientado a la conexin. Por tanto, el gateway seencontrarconlosproblemasdecontroldeflujoprovenientesdelacapadetransporteTCPa

26

lahoradeenviardatosydeberactuaren consecuencia.Params informacin,TCPusaelcontroldeflujoparaasegurarquefuentesdeinformacinmuyrpidasoelpropiogatewaynosaturan consumidores lentos o congestionan redes incapaces de almacenar y procesar lospaquetes.Porello,paramejorarlacalidaddeservicioparatodosloscomponentes,elgatewayno deber bloquearse si el control de flujo del protocolo TCP entra en funcionamiento.Ademselgatewaydebepoderescalarseeficientementeconelincrementodeproveedoresyconsumidores.

Unode losmejoresmtodosparaevitarelbloqueodelgatewayymejorarsurendimientoesaadirconcurrenciaaldiseodelgateway,porejemploasociarcadaconexinTCPaunhilodecontroldiferente.Estoconsigueque,aunque loshilosde lasconexionesTCPafectadasporelcontrol de flujo se encuentren bloqueados, el resto de hilos siguen funcionando connormalidad.Noobstanteesnecesarioprogramar loshilosdeejecucindelgatewayycmoestosvanainteractuarconlosdelosproveedoresylosdelosconsumidores.

3.2.Contexto

Clientesqueaccedenaobjetosejecutndoseenhilosdecontroldiferentes.

Estoes,mquinasquegeneranmensajesquehande llegaraotrasmquinaspasandoporelgateway.

3.3.Problema

Muchas aplicaciones intentan dar mejor calidad de servicio permitiendo que se conectenvarios clientes simultneamente. En vez de usar un nico objeto pasivo que ejecuta susmtodos en el hilo de ejecucin del cliente que lo invoc, un objeto concurrente tiene supropio hilo. Sin embargo, aunque los clientes se atienden concurrentemente, es necesariosincronizarlosaccesosaesteobjetoencasodequepudierasermodificadoporvariosdeestosclientesalavez.

Portanto,elpatrnintentasolucionartresproblemas:

Elaccesoaesteobjetoporpartedelosclientesnodeberabloquearnialosclientesnial servidor de ningn modo para no degradar la calidad de servicio de todos losparticipantes.

Simplificarelaccesoa losobjetos compartidos,de formaque toda la sincronizacinnecesariaseatotalmentetransparenteparaelcliente.

Hacer un diseo donde el software equilibre los paralelismos entre hardware ysoftware.

27

3.4.Solucin

Por cada objeto afectado por los tres problemas anteriores, habr que desacoplar lainvocacindelosmtodosqueafectenalobjetodesuejecucin.Lainvocacintienelugarenelhilodeejecucindelcliente,mientrasquelaejecucinloharenunhilodistinto.Adems,elclienteinvocarestosmtodoscomosifuerancualquierotro.

Entrarnen juegootrosdospatronesdediseo:ProxyyServant.Elprimerorepresentar lainterfazdelobjetoactivoyelsegundoproporcionarsuimplementacin.Elproxyyelservantestarn enhilosde controldiferentesparaque la invocacin y la ejecucinpuedanocurrirconcurrentemente.Concretamente,elproxycorrerenelhilodelclienteyelservant loharenotrodistinto.

Elproxy se encargarde transformar la invocacindel cliente enunapeticindemtodos(method request), que ser almacenada en una lista de activacin (activation list) por unorganizador (scheduler). El scheduler tendr un hilo propio encargado de desencolarpeticionesydeprovocarsuejecucin,por loqueelservantcorrerenelhilodelscheduler.Los clientes obtienen el resultado de la peticin a travs del future que devolvi el proxydurantelainvocacin.

3.5.Estructura

Eldiseobsicodelpatrncuentaconseiscomponentes:proxy,methodrequest,scheduler,activationlist,servantyfuture.

Unproxyproporciona la interfazquepermitea losclientes invocar losmtodospblicosdelobjetoactivo,dichodeotra forma,seencargadeocultar toda la implementacindelobjetoactivoalcliente.Resideenelhilodelcliente.

Cuandounclienteinvocaunmtododefinidoenelproxy,sedisparalaconstruccindeobjetotipomethodrequest.Esteobjetocontienetodalainformacinnecesariaparalaejecucindelmtodo y devolver el resultado al cliente. El method request define un interfaz para laejecucinde losmtodosdeunobjetoactivo.Tambincontiene lasincronizacin requeridapara determinar cundo puede ejecutarse una peticin y cundo no. Se implementa unmethodrequestdistinto(concretemethodrequest)porcadamtododisponiblealpblicoporpartedelproxy.

28

Elproxycreaunconcretemethodrequestdurante la invocacindeunodesusmtodosporpartede los clientesy lo insertaen laactivation list.Esta listaacumula todas laspeticionesrealizadasypendientesdeejecucin,ademsdedecidirqupeticionespuedenejecutarse.Laactivation listes laencargadadedesacoplarelhilodelclientedonderesideelproxydelhilodondeelservantejecutalapeticin.Elestadointernodelalistadebeestarprogramadodetalforma que est protegido contra accesos concurrentes que pudieran modificarlasimultneamente.

Elschedulercorreenunhilodiferentedeldelosclientes,normalmenteeneldelpropioobjetoactivo.Decidequpeticinseejecutaracontinuacin.Estadecisinsepuedetomarsegnelcriterioqueseprograme,porejemploenelordenenque fueronencoladas laspeticionesosegnalgunaspropiedadesde laspropiaspeticiones(tiemponecesarioparasuejecucinporejemplo).Elschedulerpuedehacerestograciasalosmtodosdeguardadelmethodrequestya la informacin que contiene para su ejecucin. El scheduler usa la activation list paraorganizar losmethod requestspendientesde ejecucin. Losmethod requests los inserta elproxycuandoelclienteinvocaunmtodo.

Clase

Proxy

Colaboradores

MethodRequest

Scheduler

Future

Responsabilidad

Define el interfaz delobjetoalosclientes.

Crea elMethod Requestcorrespondiente.

Correenelhilodelcliente

Clase

MethodRequest

Colaboradores

Servant

Future

Responsabilidad

Representa la llamadaalmtodo en el objetoactivo.

Proporciona mtodospara la sincronizacincuando una peticinpuedaserejecutada.

Clase

ConcreteMethodRequest

Colaboradores

Servant

Future

Responsabilidad

Implementa larepresentacin de lallamadadeunmtodo.

Implementamtodos deguarda.

Clase

ActivationList

Colaboradores

Responsabilidad

Almacena methodrequests pendientes deejecucin.

El scheduler aade losmethod requests apeticin del proxy y losextraecuandoseaposibleejecutarlos.

Clase

Scheduler

Colaboradores

ActivationList

MethodRequest

Responsabilidad

Extrae method requestsdelaactivacinlist.

Aade method requestscuando el proxy losolicite.

Seejecutaenelhilodelobjetoactivo.

29

Un servant define el comportamiento y el estado que se modela como objeto activo. Losmtodosque el servant implementa se corresponden con aquellos a losqueda interfaz elproxy y los method request que el proxy crea. Tambin puede contener mecanismos quepuedenusar losmethod request para susmtodosde guarda. Se invocan losmtodosdelservantcuandoelschedulerlosolicitaatravsdelosmethodrequests,porloqueseejecutaenelhilodelscheduler.

Cuandounclienteinvocaunmtodoenelproxy,steledevuelveunfuture.Conestefutureelclienteescapazdeencontrarelresultadodesupeticincuandoestdisponible.Cadafuturereservaelespacionecesarioparaalmacenarelresultado.Elclientepuedecomprobarsiestdisponibleelresultadobienbloquendosehastaquelorecibeorealizandosondeos.

Eldiagramadeclasesalquerespondeelpatrneselsiguiente:

Figura4:Estructuradelpatrnobjetoactivo

Clase

Servant

Colaboradores

Responsabilidad

Implementa el objetoactivo.

Seejecutaenelhilodelscheduler, el hilo delobjetoactivo.

Clase

Future

Colaboradores

Responsabilidad

Almacenaelresultadodeuna peticin al objetoactivo.

Da un punto deencuentroentreelclienteyelresultado.

30

3.6.Dinmica

Elpatrnsedivideentresfases:

1. CreacindeunMethodRequestysuencolamiento.Elclienteinvocaelmtodoenelproxy.Estoprovocalacreacindeunmethodrequest,queguardalonecesarioparalaejecucindelapeticin.Elproxyenvaalschedulerelmethodrequestcreadoparaque lo encole en la activation list. Si la peticin espera un resultado, el proxy ledevuelveal clienteun futuredondepodrencontrarlo cuandoestdisponible.Sielmtodonodevuelveningnresultado,noseledevuelvealclienteningnfuture.

2. Ejecucin del Method Request. El scheduler monitoriza su activation list ydeterminaqumethod requestpuede serejecutadoa continuacina travsde susmtodosdeguarda.Paraellotieneunhilopropiocorriendocontinuamente.Cuandounmethodrequestvaaserejecutado,elschedulerlosacadelaactivationlistyselopasaalservantparaqueejecuteelmtodocorrespondiente.Mientrasseejecutaestemtodosepuedeaccederalestadodelservantycrearelresultadosiserequiere.

3. Finalizacin. En esta fase se almacena el resultado, si lo hay, en el future y elscheduler vuelve a monitorizar la activation list buscando method requests quepuedan ser ejecutados. Si se esperabaun resultado, el cliente puede encontrarlo atravsdelfuture.Normalmentecualquierclientequepuedaencontrarseconelfuturepodr encontrarse con el resultado. Una vez el cliente se ha encontrado con elresultado,tantoelmethodrequestcomoelfuturesepuedenborrarexplcitamenteomedianteelrecolectordebasuracuandoyanotenganreferenciasquelesreferencien.

Figura5:Diagramadesecuenciadelpatrnobjetoactivo

31

3.7.Implementacin

Serecuperarelejemplodelgatewayduranteesteapartadoparadarunamejorexplicacindecmo implementarestepatrn.La implementacindelpatrnsepuederealizaren loscincopasosdescritosacontinuacin.

3.7.1.Implementarelservant

Elservantdefineelcomportamientoyelestadoquevaasermodeladocomounobjetoactivo.Adems el servant puede contener mtodos que podrn ser utilizados por los methodrequestsparasuspropiosmtodosdeguarda.

Enelejemplodelgateway,elservantesunacolademensajespendientesdesertransmitidosalosconsumidores.Porcadaconsumidorremoto,existeunconsumerhandlerquecontieneunaconexinTCPqueapuntaalprocesodeunconsumidor.Ademsestehandlercontieneunacolamensajesmodelada comounobjetoactivoe implementado conunMQ_Servant.Cadahandleralmacenamensajesprocedentesdelosproveedoresalgatewaymientrasesperansertransmitidos al consumidor remoto. La interfaz ms bsica del MQ_Servant se muestra acontinuacinenlenguajeC#:

Losmtodos put() y get() implementan la insercin y la extraccin demensajes de la colarespectivamente.El servantdefine losmtodosempty() y full()quedistinguen tresestadosinternosdelservant:vaco, llenooningunode losdos.Conellospuededeterminarsecundosepuedellamaralosmtodosput()yget(),yportantoejecutarselosmethodrequest.

Comoenestecaso,lasincronizacinqueprotegeseccionescompartidasservantnodebeestarimplementada dentro del servant. ste slo debe proveer de los medios necesarios pararealizarlamostrando su estado interno a losmethod request, que sern los encargadosdeimplementarlosmecanismosdesincronizacinnecesarios.Deestaformaseevitanproblemas

class MQ_Servant{ //Constructor.

public MQ_Servant (int mq_size); //Mtodos para encolar y desencolar mensajes. void put_i (string msg); string get_i (); //Mtodos en los que los method request basarn los mtodos de guarda bool empty_i (); bool full_i ();

}

32

si se necesitase crear subclases del servant que requirieran polticas diferentes desincronizacin.

3.7.2.Implementarelproxyylosmethodrequests

Elproxyproporcionaalosclientesuninterfazconelquepoderhacerllamadasalosmtodosdel servant. Por cada invocacin del cliente, el proxy crea unmethod request con toda lainformacinnecesariapara suejecucin,que suelecomponerse convariosparmetros,unareferencia al servant en el que se ejecutar, un future donde almacenar el resultado y elcdigoqueejecutaelmethodrequest.

Enelgateway,laclaseMQ_ProxyproporcionauninterfazalaclaseMQ_Servantdefinidaenelpaso1.

class MQ_Proxy{ //Parmetros private int MAX_SIZE = 100; //Nmero mximo de mensajes en cola private MQ_Servant servant; private MQ_Scheduler scheduler; //Constructor.

public MQ_Proxy (int size){ servant = new MQ_Servant(size); scheduler = new MQ_Scheduler(size); } //Mtodos para encolar y desencolar mensajes. void put (string msg){ Method_Request mr = new Put(sevant, msg);

scheduler.enqueue(mr); } future get (){ future resultado; Method_Request mr = new Get(servant, resultado); scheduler.enqueue(mr); return resultado; }

}

33

Cada mtodo del MQ_Proxy transforma una invocacin en un method request y pasa lapeticinalschedulerqueseencargardeencolarla.Elaccesoalproxynoest limitadoaunnicocliente,ademspuedenaccederconcurrentemente.

LaclaseMethod_Requesteselinterfazqueusarntodaslasimplementacionesdelosmethodrequests,hayunapormtodoqueseofreceenelproxy.Proporcionaalschedulermtodosconlosquerealizarlasincronizacinyprovocarsuejecucin.Normalmenteestoesmedianteun mtodo can_run() que devuelve un valor booleano si es posible ejecutarlo o no, y unmtodorun()quecontieneelcdigopararealizarlapeticin.

Losmtodossonimplementadosensussubclases,porloquenecesitamosdos:GetyPut.

Sepuedeobservar cmo seusa elmtodo full()del servantpara realizar la sincronizacin.Cuando lapeticinpuedeserejecutada,elscheduler llamaalmtodorun(),quehacequeseintroduzcaunmensajeen lacolademensajesdelservant.stemtodono requieredemssincronizacinyaqueeselschedulerelqueseencargadetodoconlosmtodosdeguardadelosmethodrequests.

abstract class Method_Request{ public bool can_run(); public void run();

}

class Put : Method_Request{ private MQ_Servant servant; private string mensaje; //Constructor public Put(MQ_Servant servant, string mensaje){ this.servant = servant; this.mensaje = mensaje; } //Mtodo de guarda

bool can_run(){ return !servant.full(); } //Mtodo con el cdigo para la ejecucin void run(){ servant.Put(mensaje); }

}

34

Lo nico que cambia con respecto a la peticin Put es que se devuelve un resultado y seguardaenun future.Comoelclientetiene lamismareferencia,alactualizarel futureconelresultado,elclientetieneaccesoalinmediatamente.

3.7.3.Implementarlaactivationlist

Cadamethod request seencolaen la activation list.Esta lista sepuede implementar comoconvenga,siendo lomstpicohacerlocomouna listaenlazadayqueproporcione iteradorescon los que el scheduler puede extraer e introducir elementos. Se suele disear usandopatrones de control de la concurrencia, como el del objeto Monitor. Si se combina contemporizadores, es posible delimitar el tiempo que se puede estar esperando a que unaoperacinserealice.

class Get : Method_Request{ private MQ_Servant servant; private future resultado; //Constructor public Get(MQ_Servant servant, future resultado){ this.servant = servant; this.resultado = resultado; } //Mtodo de guarda

bool can_run(){ return !servant.full(); } //Mtodo con el cdigo para la ejecucin void run(){ resultado = servant.Get(); }

}

class ActivationList{ //Constructor public ActivationList(); //Mtodo para aadir method requests public void enqueue(Method_Request CMR);

//Mtodo para extraer method requests public void dequeue(Method_Request CMR);

}

35

Esposiblellamaralosmtodosenqueueydequeuesimultneamenteyaqueestosincorporanlosmecanismosnecesariosparaquenoseproduzcaninconsistenciasynosecorrompalalista.

Enelgatewaylosclientesactancomoproveedoresaadiendomethodrequestsmientrasqueelschedulerhacedeconsumidorextrayndoloscuandoseaposibleyejecutandosumtodorun().

3.7.4.Implementarelscheduler

El schedulermantiene laactivation listyejecuta losmethod requestcuando seaposible.Lainterfazdelschedulersueleproporcionarunmtodoalproxyparaaadirmethodrequestsalalistayotromtodoparaextraerlosyejecutarlos.

ElschedulercreaunhilosloparaejecutarelmtodoDispatch.Apeticinde losclientes,elproxyencolamethodrequetsenlaactivationlistmientrasqueelschedulermonitorizalalistadesde otro hilo, el del mtodo Dispatch. Desde ste hilo, se comprueban los mtodos deguardadelosmethodrequestsyseejecutalapeticincuandoseaposible.

class MQ_Scheduler{ private ActivationList actList; //Constructor public MQ_Scheduler(int size); //Mtodo para aadir method requests public void enqueue(Method_Request CMR){ actList.enqueue(CMR); }

//Mtodo para extraer method requests public Dispatch();

}

36

Selanzaraelnuevodesdeelmismoconstructordelscheduler:

La implementacin del mtodo Dispatch determina en qu orden pueden ejecutarse losmtodosPutyGetdelservantmediantelosmtodosfull()yempty()deste.

En el gateway, la implementacin delmtodoDispatch ejecuta continuamente losmethodrequest que estn disponibles. No obstante se puede complicar ms dando por ejemploprioridadaunosmethodrequestssobreotrosoaadiendovariablesparatenerencuentaelestadodelservant.

class MQ_Scheduler{ private ActivationList actList; //Constructor public MQ_Scheduler(int size){ actList = new ActivationList(size); Thread bucle = new Thread(new ThreadStart(Dispatch)); bucle.Start(); } }

public Dispatch(){ while(true){ if(!actList.numpet = 0){ IEnumerator enume = actList.tope.GetEnumerator(); Method_Request peticion; for(enume.Reset(); enume.MoveNext();){ peticion = ((ActivationList.Peticion)enume.Current).metodo; if(peticion.can_run()){ actList.dequeue(peticion); peticion.run(); } } } }

37

3.7.5.Concretarelfutureycmoaccederal

Elltimopasoesdeterminarcmolosclientespodrnaccederalresultadodesuspeticiones.Es necesario establecer un procedimiento porque el servant, el encargado de realizar lapeticin,seejecutaenunhilodistintoaldelclienteypor lo tantose tendrnqueponerencontactodealgunamanera.

Haymultituddeopcionespara realizar este intercambiode informacin,pero existenunaspocaspolticasquesonlasusadasmshabitualmente:

Synchronouswaiting(paradasncrona).Elclientesebloqueaenelproxyhastaqueelschedulermandaejecutarelmethod requestyel resultado sehaalmacenadoenelfuture.Estosignificaqueelclientenopodrhacernadahastaquetengaelresultadodesupeticin.

Synchronous timedwait (parada sncrona limitada). El cliente se bloquea un ciertotiempomientrassupeticinserealiza.Sivenceeltemporizador,elclienteretomaelcontrol pero no se encola ningn method request porque no se puede ejecutarinmediatamente.

Asynchronous(asncrono).Elclienterealizasupeticinalproxyyste ledevuelveunfuturedondeencontrarelresultadosiesqueesperauno,devolviendoaselcontroldelhiloalcliente.Aquhaymuchosmtodosparaqueelclientesepaquesepeticinestyadisponible.Elmismoservantpodraavisarledequeestohaocurrido,tambinlopodrahacerelproxyoquizselpropioclienteseencarguederealizarsondeosparacomprobarsielresultadoestdisponible.

Enesteejemplosehaoptadoporlaterceraopcinporquedaunpocomsdecomplejidadypermiteestablecerreglasparaestablecerelordenenquesevanaejecutarlaspeticiones.

Elfuturepermiterealizarllamadasasncronasquedevuelvanunresultado.Cuandoelservantcompleta la ejecucin, almacena el resultado en el future. Cualquier cliente con acceso alfuture,puedenrecogerelresultadoconcurrentemente.Elfuturesepuedeeliminarunavezelservantytodoslosconsumidoreslohanusado.

38

Enelgatewayelmtodoget()delproxydevuelveunfutureysuimplementacinpodraserlasiguiente:

Class Future{ //Parmetros private bool listo; private string mensaje; public Future (){ listo = false; } public Future(string mensaje){ this.mensaje = mensaje; listo = true; } public setResultado(string mensaje){ this.mensaje = mensaje; listo = true; } public bool listo(){ return listo; } public string getResultado(){ return mensaje; } }

39

Captulo4:Paquetesylibreras

Lamotivacindeeste captuloes lapresentacinde lasdiferentes librerasypaquetesqueformanpartede laaplicacindesarrollada.Esnecesario realizarun controlde laestructuraparapoderadoptarelpatrndediseocomobase.

4.1.Paquetesexternos

SehautilizadoelpaqueteDirectShowLib[6]en laversin liberadaenabrilde2006para laslabores multimedia. Es un paquete de libre distribucin que trata de portar la bibliotecaDirectShow que existe en C++ al lenguaje C#. Est siendo desarrollado por un grupo devoluntarios que decidieron tomar la iniciativa cuando Microsoft anunci su intencin deabandonarlaslibrerasDirectShowparacentrarseenelproyectoWindowsMedia.

Por el hecho de estar siendo desarrollado por programadores independientes y de formavoluntaria, no est terminado y algunas funciones que podran ser interesantes para esteproyecto han tenido que ser sustituidas por otras menos eficientes. Concretamente laposibilidaddeenviar ficherosmultimediaymanipularlosalvuelocomo loqueson,esdecir,tener flujosdedatos identificados comomultimediay sobre losque sepuedeactuar comotales.EstoquesepuedehacerenJava,enC#noestsoportadonativamenteysonnecesariaslibrerasexternas.Encasodetenerestesoportenativoparaflujosdedatosmultimedia,seraposible unificar la descarga y el visionado de imagen y video en directo. En el captulo deimplementacindelaaplicacinsedetallarenquafectaesto.

ConcretamenteenelservidorsehautlizadoelcomponenteDxPlayde la libreraCapturedelpaquete DirectShowLib. Permite reproducir video y hacer capturas del mismo. Con latransmisindeestascapturas se realizarun sistemadevisionadoendirecto,quizsnodeltodoeficiente,perosposibleconlasherramientasdisponiblesenestemomento.

4.2.Paquetespropios

Laaplicacinsehadivididoendosespaciosdenombres:clienteyservidor.

El paquete cliente es el ms simple de los dos, pues slo contiene la interfaz grfica delusuario.Estainterfazcontieneuncomponentedelespaciodenombresdelservidor,elproxy,alque se realizarn laspeticionesdel cliente.Elproxy seha incluidodentrodelespaciodenombresdelservidorporquetiene lafuncindeserunrepresentantedesteparaelclienteperonoformapartedeste:seejecutaenelhilodecontroldelcliente.

Servidor DirectShowLibusa

40

Ademsenelpatrnoriginal,elproxycompletoesunapartedelservidor,porloqueeslgicoque aunque se separen las funciones relacionadas con el cliente y las relacionadas con elservidor endospartes, estasdospartes sigan siendopartedel servidor. El cliente tambinutilizalaclasefuturedelservidorparapoderaccederalresultadodesupeticin.

El paquete servidor contiene todas las clases relacionadas con el patrn objeto activo,incluidosproxyyfuture.AdemsdesdeelpaqueteservidorseutilizaelcomponenteDxPlaydelpaqueteDirectShowLibparalaslaboresmultimedia.

Cliente Servidorusa

41

Captulo5:Implementacindelpatrn

Esteproyectobuscabaconstruirunaaplicacinmultimediadetipocliente/servidorbasndoseenelpatrnobjetoactivo.Sehaintentadorespetaralmximoposiblelaestructuraoriginal,yassehaconseguido,exceptoenalgunosaspectosnocontempladosenladescripcinoriginal.Sepodradecirquesehaimplementadounavariantedelpatrnycomomsadelantesevaahaber,loscambiosnoslohansidonecesarios,sinoqueademsinevitables.

5.1.Problemasencontrados

Duranteeldesarrollodelaaplicacinsehanencontradodificultadesrelacionadastantoporellenguajeutilizadocomoporelpatrn.

5.1.1.Referentesallenguaje

LibrerasmultimediainacabadasAunqueen teorael lenguajeC#esmultiplataformaydehechohayproyectosmsomenosmadurosquedanlaposibilidaddeutilizarloensistemasLinux,enlaprcticasloseutilizaensistemasWindows.AdemsMicrosoftes sugran valedor, sepodradecirquees suyo, y sedemuestra en que son los encargados de escribir las libreras que utiliza. Esto, que puedeparecer bueno a priori ya que asegura su desarrollo, resulta daino a largo plazo por lasaspiracionesdeMicrosoftapromocionarsusproductos.

Unejemplodeestosonlaslibrerasmultimediaquelaaplicacindeberautilizar.Laslibrerasquedeberanserequivalentesa lasutilizadasaC++,noslonoestnacabadas,sinoqueseencuentranabandonadas.LaraznesqueMicrosoftlasolvidcuandolanzlaversin9desuWindows Media Player y vio que la forma ms fcil para tratar audio y video con C# essimplementeincrustarsureproductoralldondeseanecesario.

Elproblemadeestoesqueoficialmente lanicamaneradever, transmitiro tratarvideooaudiorequiereunsistemaWindowsyutilizarprogramasdeMicrosoft.Estopuedenoserdeltodo deseable, por ejemplo porque se est acostumbrado a C++ y se prefiera utilizar laslibrerasequivalentesaese lenguajeoqueseestpensandoenunaposiblecompilacinenLinuxdondenoestarndisponiblesestosprogramas.

Porelloalgunosdesarrolladoresindependienteshanideadosistemasalternativosconlosquetrataraudioyvideo.Lamayorasondemasiadosimplesysimplementepermitenvervideoyaplicarfiltrosalaimagenaunqueexisteunproyectodesoftwarelibrebastanteavanzadoqueeselquesehausadoenlaaplicacin.EselcasodelalibreraDirectShowNet.Noobstanteestalibrera no est acabada y tiene una funcin imprescindible para la aplicacin todava sinimplementar,yeselsoportedearchivosmultimediaparasocketsyflujosdedatos.Porahora

42

esta libreraes incapazdediferenciarunflujodedatosbinariosdeunodedatosmultimedia,porloqueelvisionadodevideosentiemposetienequerealizardandounpequeorodeo.

El impacto de este problema sobre la aplicacin es tener que elegir entre ver el video odescargarlo y verlo despus. Cuando la librera DirectShowNet est acabada ser posibledescargarunvideoyverloalmismotiempo.

LanzamientodehilosEl lenguajeC#tieneunaformamuyparticulardecrearhilos.SienJavasemodelaunobjetotipoThreadqueseejecutabaenunhiloindependiente,enC#loquesemodelaesunmtodoquetieneunasignaturaparticular.Concretamentehadeserpublicynodevolvernada.Surgendosdificultadesprincipalmente.Porun ladonoesposiblecrearunhiloquedependadeunoparmetros,almenosnode formadirecta.Porotro lado,estehilonopuededevolvernada,por loquenosepodrobtenerelresultadocualquierprocesoque lleveacabo,tambindeformadirectaenestecaso.

Loque sehaoptadoes la solucinmsutilizada,yesutilizarobjetosa travsde loscualespoderadecuarelcontextodelhiloquevaafuncionar.Estosignificaqueunobjetocontiene,ademsdelmtodoqueselanzar,loscamposnecesariosparapoderadecuarelprocesoalasituacin que est transcurriendo. Adems, mediante estos campos es posible acceder acualquierresultadoquedebadevolverelhilo.Unavezseobtieneesteresultadoofinaliza laejecucindelhilo,bastaconeliminaresteobjeto.

5.1.2.Referentesalpatrn

ProgramaclienteyprogramaservidordistintosLaversinoriginalnocontemplabaque laaplicacinpuedaestarpartidaendospartesyportanto,nohayaformaposiblequeelfutureseaunobjetocompartidoporclienteyservidor.Sielclienteesunprogramayelservidoresotro,noesposibletenerreferenciascruzadasyqueelservidortuvieraunareferenciaaunobjetodelprogramadelcliente(elfuture).

Porlamismarazn,elproxynopuedeserimplementadotalcualestenlateora.Porunladoelcliente tendraqueaccederaesteproxycomo sidelmtododel servidor se trataseparapoder obtener su future, no debera utilizar sockets en ningnmomento. Por otro lado elproxydeberatenerreferenciasalosobjetosdelscheduleryelservantqueseencuentranenelservidorparaconstruirlosmethodrequestsypoderencolarlos.

EjemploenC++El documento original que describa el patrn objeto activo utilizaba el lenguaje C++ comobase. A pesar de que tanto C++ como C# son lenguajes orientados a objetos, han sidonecesariasciertasadaptacionesdefuncionesdeC++quenoexistanenC#.Porejemplo

43

5.2.Organizacindelcdigo

Laaplicacinsedividirendosprogramasaltenerestructuratipocliente/servidor.Porunladoestar el servidor y por otro el cliente, y las funciones del patrn estarn repartidas entreambos.

El componente ms afectado por la estructura cliente/servidor es el proxy. La solucinescogidahasidopartirelproxyendospartes.Lapartequeestarenelprogramadelclienteharde interfazparaquestepueda realizarpeticionesal servidory seencargardehacerllegarelresultadode lapeticinalcliente.Laotraparteestarenelprogramadelservidoryserelencargadode crear losmethod requests ypedirleal schedulerque losencoleen laactivationlist.

Alpartirelproxyendospartes,surgelanecesidaddeunmediodecomunicacinentreellas.Aqu, sinembargo, s sepuedeutilizar socketsparaeste finporquesta comunicacin sercompletamentetransparentealcliente.Paraaclararconceptos,lapartedelproxyqueestenelladodelclientesedenominarapartirdeahoraProxymientrasquelaotraserSkeleton.

5.2.1.ProxyySkeleton

LaclaseProxyseencuentraenelespaciodenombresdelservidoryeslapuertadeaccesodelosclientesalobjetoactivo.Notienehilopropio,seejecutaenelhilodecontroldelclienteyatiendesuspeticiones.Sloseencargardelasfuncionesrelacionadasconelcliente:atendersuspeticionesyencauzarlashaciaquiendeberintroducirlasenlalista,devolverunfuturealclienteyponerlosmediosparaqueelresultadollegueal.

Proxymantendrunalistadelosarchivostantopropiosdelamquinadelclientecomolosdelamquinadelservidor.

ElSkeletontampocotienehilopropio,seejecutaenelhilodelcliente.Es lapartevisibledelobjeto activo para el resto de proxies. El skeleton y los proxies se comunican por socketsmediantemensajesdebidamenteformateados.

Figura6:Estructuradelskeleton

44

5.2.2.FutureyMethodRequests

ElFutureescomnatodaslaspeticiones,aunquenotodasusantodosloscampos,deahquehayadosconstructoresdistintos.Silapeticinesdevisionadodevideo,nisiquieraelnombredelficheroseranecesarioparaqueelclientelovea.Paralaspeticionesdedescargaosubidadearchivos,tantoelnombrecomoeltamaodelosficherosesnecesario.

El interfazdeMethodRequestalquesedebernajustartodas laspeticioneseselmostradoenlafigurasiguiente.ElcampotipodelainterfazMethodRequestseusanicamenteparalabores de depuracin. El mtodo can_run() es el mtodo de guarda que devolver truecuandoseaposiblerealizarlapeticin.Elmtodoejecutar()realizaunallamadaalservantparaquerealicelapeticin.

LaimplementacinqueserealizadelMethodRequestparacadaunodelaspeticionesposiblesesprcticamentelamismayaquedentrodeestasclasesnoestelcdigoparaejecutarla,sinola llamadaalservantparaque la realice.Lanicadiferenciaes lapresenciaonodelcamposize,queindicaeltamaodelficheroenelcasodedescargaosubidadeficheros.

5.2.3.Scheduler

ElScheduleressimilaraldelejemplodelgateway.Contieneunareferenciaaunaactivacionlistdonde iralmacenando losmethodrequestsque le lleguendesdeelskeleton.Slocontienedosmtodos,unoparaincluirmethodrequestsyotroparaextraerlos.

Figura7:Estructuradelscheduler

Adems cuenta con elmtodoDispatchque correr enunhilo independiente. Estehilo seencargade recorrer losMethodRequestsalmacenados,comprobar susmtodosdeguarda,extraerlodelalistasiesposiblerealizarsuejecucinyavisaralservantparaquelarealice.

5.2.4.ActivationList

EstconstruidamedianteuniteradorutilizandolosinterfacesqueproporcionaMicrosoftparaeste fin: IEnumerable y IEnumerator. De esta forma se consigue compatibilidad con lainstruccinforeach()deC#.

El interfaz IEnumerabledebeser implementadaporelobjetoquevayaaser iterado.EnestecasoseusaunaclaseinternallamadapeticinqueincluyeelMethodRequestyunareferenciaalasiguientepeticindelalista.

45

El interfazIEnumerator lo implementaotraclase internaqueser laencargadaderecorrer lalistadeobjetostipopeticinenlazados.

5.2.5.Servant

Elservanteselcomponenteltimodelaestructura,elencargadoderealizarlaejecucindelapeticin y devolver al cliente el resultado. Utiliza el componente DxPlay de la libreraDirectShowLibparaenviarvideoendirecto.

Figura8:Estructuradelservant

Para realizaresta transmisinde videoendirecto,el servantnecesita reproducirel video yhacercapturasde la imagenparaenviarlas.Parapoderreproducirelvideo,hade tenerunareferenciaaunobjetotipopanelqueseleproveeenelconstructor.

5.3.Dinmica

Se realizan comunicaciones simultneas a varios niveles ya que existen varios hilos deejecucin.Estnlascomunicacionesentreelproxyyelskeletonprovocadasporlaspeticionesdelosclientes.Ademsexisteintercambiodemensajesentrelasclasesdelobjetoactivoparadecidirsisepuedeejecutarunapeticin.Porltimoestnlascomunicacionesentreelservantyelclienteparahacerlellegarelresultadodesupeticin.

5.3.1.Arranquedelosprogramas

Enesteapartadosevanadetallarlosprocesosdearranqueeiniciodelosprogramasclienteyservidor.

Empezandoporelprogramaservidor,hayquediferenciarentreelarranquedelprogramayeliniciodelservidor.Alarrancarelprogramatodo loqueseobtieneesunaventanaconvariasopciones, pero todava no se escucha ninguna peticin de los clientes. Para comenzar aescuchar laspeticionesde losclientes,hayquepulsarsobre elbotn Iniciar.Estodispara lasecuencia de arranque del objeto activo que se reduce a crear un objeto de tipo skeleton

46

desdelaventana.Enelconstructordesteselanzarnlosdiferentescomponentesdelobjetoactivo,queasuveziniciarnloscomponentesquenecesitenparafuncionar:

Figura9:Secuenciadearranquedelservidor

Elcasodelclienteesaunmssimple.Partiendodelaventanainicial,elproxysecreacuandosepulsasobrelaopcinConectardelmenprincipal.

Figura10:Secuenciadearranquedelcliente

5.3.2.Comunicacionesproxyskeleton

Lasprimerascomunicacionesentreelproxyyelskeletonseproducendurantelasecuenciadearranque del proxy. En este periodo, el proxy se conecta al servidor y descarga la lista devideosremotos.Despusdeesto,permanecealaesperadequeseproduzcanpeticionesquedebaencaminarhaciaelskeleton.

Figura11:Secuenciaconexindelproxyconelskeleton

Conectar()Form1 Proxylanza

Proxy Skeleton

connect()

send(listaVideos)

Form1 Skeleton

Servant

ActivationList

iniciar()

lanza

lanza

hiloDispatch()

Scheduler

47

Elsegundoyltimocontactoqueseproduceentreproxyyskeletonesenlosprimerospasosdeunapeticin:

Figura12:Secuenciadepeticin

El cliente realiza lapeticin como sideunmtodonormaldelproxy se tratara.Desconocecompletamente que esa llamada a unmtodo del proxy supone conectar con un servidorexterno.Obviamenteelusuariossabe loqueesapeticinconlleva,perodesdeelpuntodevistadelprogramacliente,estoestotalmentetransparente.

Unavezelproxy recibe lapeticindelcliente,construyeunvector tipostringdedoso tresposiciones segn el tipo de peticin. En este vector incluye la informacin debidamenteformateadaquenecesitaelskeletonparasaber lapeticinque realizelclientey losdatosnecesariosdelosarchivosquehayaimplicadosenestapeticin.Unavezestosdatoshansidotransmitidos al skeleton, el proxy le devuelve un future al cliente a travs del cual deberesperarrecibirelresultado.Msadelantesedetallarelprocesodepeticinsegneltipoquesea,yaquenotodasrequierenlosmismospasosunavezhasidoencoladaenlaactivationlist.

Elskeletonse limitaarecibir lapeticinyconstruirunobjetotipoConcreteMethodRequest(CMR)queincluyetantoeltipodepeticinylascaractersticasdelosvideosimplicados,comounsocketalqueenviarelresultado.Esteobjetoseloenvaalschedulerparaqueloencoleenlaactivationlist.Cuandoelschedulerrecibeelobjeto,selimitaaenviarloalaactivationlistystaacolocarloenlaltimaposicindesulista.

enqueue(CMR)future

Cliente Proxy Skeleton Scheduler ActivationList

peticion() transmitepeticion

enqueue(CMR)

48

5.3.3.Objetoactivo

Elobjetoactivotieneunhilopropioencargadodeextraerpeticionesdelalistaydeejecutarlasposteriormente.Elprocesoeselsiguiente:

Figura13:Secuenciadeextraccindepeticin

El mtodo Dispatch tiene un hilo propio donde se ejecuta continuamente. Este mtodorecorrelalistadepeticionespendientesdeejecucinmedianteuniterador.Compruebaconelmtododeguardade cadapeticin siesposibleejecutarlay cuandoencuentraunaque sepuedeejecutar,laextraedelalistayavisaalservantparaquerealicelaejecucin.

5.3.4.Comunicacionesobjetoactivoproxy

Unavezsehaextradounapeticinysehallamadoalservantparaquelaejecute,seproduceunintercambiodemensajesentreelobjetoactivo,concretamentedesdeelservant,yelproxyalojadoenelhilodelcliente.Esteintercambiodemensajesvaraconeltipodepeticinqueseva a realizar,por loque se van adetallar a continuacin los tres casos implementados. Entodos los casos se parte desde elmomento en que el Scheduler avisa al servant para queejecutelapeticin.

true

.

.

.

.

.

.

Scheduler Dispatch() ActivationList Servant

lanzahilo

peticion.can_run()

dequeue(peticion)

ejecutar()

49

Primercaso:Peticintipodescargadevideo.

Figura14:Secuenciadeejecucindelapeticindevisionado

.

.

.

setListo()listo

lanzahilo

.

.

.

estaListo()

true

.

.

.

Close()

FIN

recibirImagen()

.

.

.

imagen

recibirImagen()verVideo()

ActualizarImagen

imagenActualizarImagen

FIN

Dispose()

Cliente Proxy escucharClientes Servantfuture

50

Segundocaso:Peticintipodescargadevideo.

Figura15:Secuenciadeejecucindelapeticindedescarga

.

.

.

Cliente Proxy Servantfuture

Iniciatransferencia

.

.

.

setListo() Close()

.

.

.

FIN

Close()

actualizar()

Dispose()

true

estaListo()

51

Tercercaso:Subidadevideo.

Figura16:Secuenciadeejecucindelapeticindesubida

actualizar()

Dispose()

true

estaListo()

setListo() Close()

Iniciatransferencia

.

.

.

FIN

Close()

.

.

.

.

.

.

.

.

.

Cliente Proxy Servantfuture

52

Entodosloscasos,unavezharecibidoelresultadoelcliente,seeliminalareferenciaalproxyy se creaunanueva.Parapoder volvera realizarpeticionesesnecesario reconectar conelservidor.

Laspeticionestipodescargaysubidafuncionandeformaexactamenteigualtalcomoseveracontinuacin,conlaexcepcindelsentidodelatransferenciadelficheroprincipalmente.

Lapeticintipovisionadotieneunfuncionamientoalgomscomplicado.Estapeticin

5.3.5.Otros

Lasecuenciaqueseproducecuandosecambianlosparmetrosdeconfiguracineslamismatantoparaelservidorcomoparaelcliente.Lonicoquevaraeselnombredelasvariables.

Figura17:Secuenciadeconfiguracin

Cuandosepulsasobreelbotndeconfiguracin,encualquieradelosdoscasos,seabreunaventanaqueasumeelcontroldelaaplicacin.Unavezsecierra,seactualizanlosvalores.

Close()

getValores()

FIN

lanzaConfiguracin()

BotnConfiguracin

.

.

.

ConfiguracinForm1

setValores

53

5.4.Implementacin

Eneste captulo se vaaentrarendetalleenel cdigode losdosprogramasdesarrollados,clienteyservidor.Puestoqueyahaquedadoclaroencaptulosanterioresqucomponentespertenecena cadaprograma,eneste captulo sevanadocumentardirectamenteel cdigosiguiendolaestructuradelpatrnynoladelosprogramas.Seharasparaseguirelmodeloquesehautilizadoenladescripcindelpatrnensuversinoriginal.

Elmtodoconsistirenmostrarprimeroelinterfazdecadaclaseyunapequeaexplicacindesta.Despusseentrarendetalleconlosmtodos,explicandolafuncindecadauno.

5.4.1.Proxyyskeleton

Puestoqueenelpatrnoriginalestasdos claseseranunamisma,enesteapartado sehanincluidoambas.Comoya sehaexplicadoenapartadosanteriores,elproxy seencargardeproporcionaralclienteun interfazconelqueaccederalservidor.Elskeletonhardeenlaceentrelosproxiesqueseejecutanencadamquinaclienteconelservidor.

Figura18:Interfazdelproxy

Proxy

Skeleton:Socketf:Futureservidor:SocketpictureBox1:PictureBoxListaArchivos:ListBoxlistaAjena:string[][]listaPropia:string[][]peticionEnCurso:int

Proxy(listaArchivos:ListaBox)solicitarVideo(indice:int):FuturetransferirArchivo(indice:int):FuturesubirVideo(indice:int):FutureesperarMensaje()verVideo(pictureBox1:PictureBox)recibirImagen()descargarArchivo()subirArchivo()setListaPropia(listaPropia:string[][])

54

Mtodo Descripcin

Proxy (listaArchivos ListBox) Eselconstructordelaclase.Lalistaqueselepasacomoargumentoes la listade archivosde lamquina clientedisponiblesenesemomento.Durantelaconstruccin,sedescargalalistadearchivosdelservidor.

solicitarVideo ( int ndice ) Mtodoque invocael clientepara solicitarel visionadode un video. El proxy se encarga aqu de encaminar lapeticinalskeleton.Elargumentoeselndicedelarchivoenlalistadearchivosdelservidor.

transferirArchivo (int ndice ) Mtodoqueinvocaelclienteparasolicitarladescargadeun video. El proxy se encarga aqu de encaminar lapeticinalskeleton.Elargumentoeselndicedelarchivoenlalistadearchivosdelservidor.

subirVideo ( int ndice ) Mtodoque invocaelclientepara solicitar la subidadeun video. El proxy se encarga aqu de encaminar lapeticinalskeleton.Elargumentoeselndicedelarchivoenlalistadearchivosdelcliente.

esperarMensaje ( ) Conestemtodoserealizaunaesperasielservidordebeavisarcundosedebeactualizarelfuture.

verVideo ( PictureBox pictureBox1 )

Cuandolapeticindevisionadoestlistayelfutureasloindica,elclienteinvocaestemtodoparacomenzaraverlasimgenesdelvideo.Elargumentoeselcuadrodondeelclientequiereverlasimgenes.

recibirImagen ( ) Medianteestemtodoelproxyrecoge las imgenesdelservidoryselashacellegaralcliente.

descargarArchivo ( ) Conestemtodoelproxy realiza ladescargaelarchivo.Al finalizaractualizael futureparaqueel clientepuedaencontrarelresultadodesupeticin.

subirArchivo ( ) Conestemtodoelproxyrealiza lasubidaelarchivo.Alfinalizaractualizael futureparaqueelcliente sepaqueyasehasubido.

setListaPropia ( string[][] listaPropia )

Encasodequecambielalistadearchivospropia,aquseactualiza.

55

Figura19:Interfazdelskeleton

Mtodo Descripcin

Skeleton(Panel panel, ListoBox lEventos ) Constructor de la clase. Sobre el panel sereproducir el video del que se tomarncapturas y lEventos es una lista que seactualizarconloseventosqueocurran.

Iniciar ( ) Iniciaelobjetoactivo.

actualizarLista ( ) Actualizalalistadearchivosdelservidor.

esperarClientes ( ) Mtododeesperadeconexindeclientes.

recibirVideo ( Socket client, string fichero, long size )

MtodoqueavisaalschedulerdequedebeintroducirunapeticindetiporecibirVideoenlaactivationlist.

verVideo ( Socket client, string fichero ) MtodoqueavisaalschedulerdequedebeintroducirunapeticindetipoverVideoenlaactivationlist.

transferirArchivo ( Socket client, string fichero, long size )

Mtodoqueavisaalschedulerdequedebeintroducir una peticin de tipotransferirArchivoenlaactivationlist.

Skeleton

TCPListener:TCPListenerlista:string[][]organizador:Schedulerservant:Servantpanel:PanellEventos:ListBox

Skeleton(panel:Panel,lEventos:ListBox)iniciar()actualizarLista()esperarClientes()esperarMensaje()recibirVideo(client:Socket,fichero:string,size:long)verVideo(client:Socket,fichero:string)transferirArchivo(client:Socket,fichero:string,size:long)

56

5.4.2.Futureymethodrequests Losinterfacesdelaspeticiones,aunquesimilares,nosondeltodoigualesentreellos.Ademsdediferirenelconstructor,unosrequierendistintosdatosparalaejecucin,porloquetienencamposdistintos.ElinterfazbaseparatodoslosMethodRequestyquedebernimplementareselsiguiente:

Figura20:InterfazdeMethodRequest

LaclaseMethodRequestsehadeclaradocomounaclaseabstracta,ascomosusmtodos.Porestarazn,noaportaningncdigo,sloelinterfazquedebenimplementarlaspeticionesdecada tipo. Elmtodo ejecutar() resulta obvio que cada peticin necesitar uno propio quelanceuna llamadadiferentealservant,perosepodrapensarqueelmtodocan_run()sescomnatodos.Esteplanteamientoesincorrectoporvariasrazones.Porunladolosdistintostiposdepeticionesno tienenporqudependerde lasmismas variablespara suejecucin,aunqueenlaaplicacinestosesas.Porotrolado,asnosedependedeunaimplementacinespecficadelservant,yas,siestecambiaraenalgnsentido,slovariaranlaspeticionesquesevieranafectadasporestecambio.Elcampotiposehautilizadoen laboresdedepuracindeerroresparapoder identificarqupeticiones hay en la cola y saber qu estaba ocurriendo durante la ejecucin. Para elfuncionamientonormaldelaaplicacin,estecampoestotalmenteirrelevante.

Mtodo Descripcin

can_run() Eselmtododeguarda.Devuelveunvalorbooleano: true si esposible la ejecucin yfalsesinoesas.

ejecutar() Cuandoseaposible laejecucin,se llamara este mtodo. Este mtodo hace unallamadaalservant.

MethodRequest

tipo:string

can_run():boolejecutar()

57

Enlaaplicacinsehanusadotrestiposdepeticiones:Vervideoendirecto,descargarvideoysubirvideo.Losinterfacesdecadaunasonlossiguientes.

Figura21:InterfazdelapeticinverVideo

Figura22:InterfazdelapeticintransferirArchivo

Figura23:InterfazdelapeticinrecibirArchivo

En los tres casos realizan una implementacin de los mtodos abstractos. El mtodo deguardaeselmismoenlaaplicacin,aunquenotendraporquserlocomoyasehaexplicado.Como sepuedever cadapeticinnecesitadeuna seriededatospara suejecucin,yestosdatossealmacenandentrodelMethodRequest.

transferirArchivo:MethodRequest

servant:Servantclient:Socketfichero:stringsize:long

transferirArchivo(servant:Servant,client:Socket,fichero:string,size:long)can_run():boolejecutar()

recibirVideo:MethodRequest

servant:Servantclient:Socketfichero:stringsize:long

recibirVideo(servant:Servant,client:Socket,fichero:string,size:long)can_run():boolejecutar()

verVideo:MethodRequest

servant:Servantclient:Socketfichero:string

verVideo(servant:Servant,client:Socket,fichero:string)can_run()boolejecutar()

58

Porltimo,antesdeseguirconlaestructuradelpatrn,quedadetallarelfuture.Sehaoptadopordarunaimplementacinnicadelfutureparatodaslaspeticiones,aunquesepodrahaberdadodiferentesversionesdefutureparacadauna.Esteobjetoseencontrarenelcliente,porloquehadellevaraquellainformacinqueserequieraenlamquinaclienteparalarecepcindel resultado.Porello,seha implementadoelconstructor sobrecargado,paraatendera lasexigenciasdecadasolicitud.Elinterfazeselsiguiente:

Figura24:Interfazdelfuture

Elnicocamponecesarioentodosloscasoseselcampolisto,queindicasielresultadoestyadisponible.Laspeticionesdedescargaysubidadevideosrequierende losotrosdoscampos,nombreysize,parasaberelnombredelficheroacrearoabrirysutamao,parasabercundoseha completado la transferencia.En casode verel videoendirecto,no senecesitaradeninguno de estos dos campos, aunque se deja el del nombre por si se quisieramostrar elnombredelvideoenlaventanaporejemplo.

Mtodo Descripcin

Future(nombre : string) Primer constructor. Slo requiere delnombredelficherodevideo.

Future( nombre : string, size : long) Este es el segundo constructor. Requiereademsdelnombredel fichero,el tamaodeste.

setListo() Cuando el resultado de la peticin estdisponible,conestemtodoseactualizaelestado.

estaListo() : bool Conestemtodoel clientepuede sondearsi el resultado de su peticin est yadisponible.

Future

listo:boolnombre:stringsize:long

Future(nombre:string)Future(nombre:string,size:long)setListo()estaListo():bool

59

5.4.3.SchedulerAprimeravista,elschedulerpuedeparecer laclasemssimpledelpatrn.Siobservamoselinterfaz, se ve que adems del constructor, slo hay dosmtodos y el componente de laActivationList.

Figura25:Interfazdelscheduler

Sinembargoesenestemtododondesepodrandefinirunasreglasyunordena lahoradedecidir quMethodRequest se extraer a continuacin. Esto queda para futuras versiones,perobastaraconmodificarelmtodoDispatch()paraque,ademsdecomprobarlosmtodosdeguarda,tuvieralgicaadicionalquetuvieraencuentainformacinsobrelaspeticiones.Porejemplo, seraposibleestablecerprioridadesentre tiposdepeticiones ydentrodel tipodepeticiones,prioridadesportamaosdearchivosoduracindelosvideos.Adems, se podra aadir un nivel ms de complejidad permitiendo que las opciones sepudierancambiardesdeunmendeopciones,sinnecesidaddeprogramarlasmanualmente.

Mtodo Descripcin

Scheduler() Constructor.

enqueue(CMR : MethodRequest As se encolan peticiones en la activationlist.

Dispatch() Estemtodo se ejecuta continuamente enun hilo independiente. Se encarga deextraerMethodRequestdelaactivationlistcuando sea posible ejecutarloscomprobandolosmtodosdeguarda.

Scheduler

AL:ActivationList

Scheduler()enqueue(CMR:MethodRequest)Dispatch()

60

5.4.4.ActivationlistElinterfazdelaactivationlisteselsiguiente:

Figura26:Interfazdelaactivationlist

LosobjetostipoPeticionsemodelanmedianteunaclaseinternadelaactivationlist.

Figura27:InterfazdelobjetoPeticion

ElobjetoPeticionencapsula,ademsdelMethodRequestqueocupaesaposicinen la lista,unareferenciaalsiguienteobjetoPeticionenlalistaenlazada.

ElmtodoGetEnumerator()devuelveuniteradorconelquerecorrerlalistaenlazadaapartirdelobjetoPeticiondesdeelquesehacelallamada.

Mtodo Descripcin

ActivationList() Constructor.Norecibeningnparmetro.

enqueue( CMR : MethodRequest ) Aadepeticionesalalista.

dequeue( CMR : MethodRequest ) Extrae la peticin que se le pasa comoargumentodelalista.

ActivationList

primera:Peticionactual:Peticiontope:Peticionnumpet:int

ActivationList()enqueue(CMR:MethodRequest)dequeue(CMR:MethodRequest)

Peticion:Ienumerable

siguiente:Peticionmetodo:MethodRequest

Peticion(siguiente:Peticion,metodo:MethodRequest)G():IEnumerator

61

El iterador ha de implementar un interfaz concreto, IEnumerator, para que el operadorforeach()seacompatibleconl.

Figura28:Interfazdeliterador

5.4.5.Servant

Porltimoquedadetallarlaimplementacindelservant.Esteeselobjetoactivopropiamentedicho,aunqueellonosignificaquetengahilopropiodeejecucin.Dependedelschedulerparaejecutarlaspeticiones.

Figura29:Interfazdelservant

Mtodo Descripcin

PetEnum( pet : Peticion) Constructor.Elargumentoeselobjetoquesetomarcomoelprimerodelalista.

getCurrent( ) : object Devuelve una referencia del objeto de lalistaporelquevalaiteracin.

MoveNext( ) : bool Adelanteunaposicinenlalistaenlazadalaiteracin

Reset( ) Reinicialaiteracinalprimerobjeto.

Servant

estado:boolpanel:Panel

Servant(Panel:panel)getEstado():boolsetEstado(estado:bool)recibirVideo(cliente:Socket,fichero:string,size:long)transferirArchivo(cliente:Socket,fichero:string,size:long)verVideo(cliente:Socket,fichero:string)

PetEnum:IEnumerator

actual:Peticionprimera:Peticion

PetEnum(pet:Peticion)getCurrent():objectMoveNext():boolReset()

62

Mtodo Descripcin

Servant ( Panel : panel ) Constructor.Elargumentoeselpanelsobreel que se reproduce el video para lapeticindevisionado.

getEstado () : bool Indicasielservantestocupadorealizandouna peticin. Devuelve True cuando estocupado,yFalsecuandoestlibre.

setEstado ( estado : bool ) Actualizaelestadodelservantalvalorqueselepasaporargumento.

recibirVideo ( cliente : Socket, fichero : string, size : long )

Mtodo que ejecuta una peticin derecepcindevideo.Con losargumentosescapazdeconectaralcliente.

transferirArchivo ( cliente : Socket, fichero : string, size : long )

Mtodo que ejecuta una peticin detransferenciadevideo.

verVideo(cliente : Socket, fichero : string ) Mtodo para ejecutar una peticin devisionadoadistanciadevideo.

63

Captulo6:Plandeprcticas

UnodelosobjetivosdeesteproyectoeraproporcionaralreaLSIdelaUPCTejemplosdeusotantode la tecnologa .NETcomodelpatrnobjetoactivo.Trasel trabajo realizado,pareceunabuenaideaaprovecharlaevolucinquetuvolaaplicacinparacrearunplandeprcticasquesirvaparaelfindeproporcionasejemplosdeuso

patrón objeto activo

Documents