PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE REGIR LA ... · documento original. En el siguiente...

Sociedad Mercantil Estatal para la Gestión de la Innovación y las Tecnologías Turísticas, S.A.M.P.

Calle Orense nº58, 4ª planta 28020 Madrid Tel. 91 443 07 07 Fax 91 443 04 17

1

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE REGIR LA CONTRATACION DE LOS SERVICIOS DE TRADUCCIÓN DE LOS CONTENIDOS WEB DE LOS PORTALES GESTIONADOS POR SOCIEDAD MERCANTIL ESTATAL PARA LA GESTIÓN DE LA INNOVACIÓN Y LAS TECNOLOGÍAS TURÍSTICAS, S. A.M.P. (SEGITTUR)

NOVIEMBRE 2017



2

ÍNDICE

Página

1. OBJETO DEL CONTRATO 3

2. EJECUCIÓN Y GESTIÓN DEL PROYECTO 13

3. ADJUDICACIÓN 14

ANEXO. GUÍA DE DESARROLLO DE PLUGINS PARA LA PASARELA DE TRADUCCIÓN

15



3

1. OBJETO DEL CONTRATO

El objeto de la contratación comprende la prestación de servicios de traducción de los contenidos que se determinen en cada caso (fundamentalmente contenidos web de los portales gestionados por SEGITTUR) a cualquier idioma, y especialmente a inglés británico, francés, alemán, italiano, chino simplificado, portugués, portugués brasileño, español argentino y español mexicano, danés, finés, neerlandés, noruego, sueco, japonés, coreano, polaco, ruso, árabe clásico, farsi e idiomas cooficiales. La traducción debe realizarse optimizando los costes de la modificación parcial de textos previamente traducidos. La traducción deberá realizarse de forma que dichos contenidos en el idioma destino resulten no sólo correctos desde un punto de vista gramatical, sino expresados de un modo natural para usuarios nativos en dicho idioma, y que optimicen la indexación en buscadores mediante el uso de términos de uso común que mejoren el posicionamiento orgánico de las páginas. El objetivo a conseguir es que los contenidos parezcan redactados directamente por un nativo en el idioma del que se trate en cada caso.

a) SERVICIOS: Concretamente, el alcance del proyecto consistirá en lo siguiente:

i. Lenguas:

La traducción de contenidos, redactados generalmente en idioma español (castellano), y ocasionalmente en inglés, será a las siguientes lenguas con carácter mayoritario: inglés británico, francés, alemán, italiano, chino simplificado, portugués, portugués brasileño, español argentino y español mexicano, danés, finés, neerlandés, noruego, sueco, japonés, coreano, polaco, ruso, árabe clásico, farsi e idiomas cooficiales.

En todas esas lenguas se podrá requerir la traducción inversa, al mismo coste que la directa.

Cada petición individualizada de traducción indicará las lenguas a que debe traducirse cada unidad de contenido.

ii. Áreas de conocimiento:

Turismo

Arte y cultura

Cualquier otro contenido en las áreas de competencia de SEGITTUR

iii. Formatos:

XML

HTML



4

Microsoft Office: ppt, doc…

PDF

Imágenes

Texto plano

iv. Volúmenes:

Se prevé un volumen anual total a traducir de 2.730.000 palabras, en previsión de nuevas incorporaciones de contenidos y mantenimientos de contenidos derivados de actualizaciones de lo ya publicado y por tanto previamente traducido.

Se podrá requerir la traducción a cualquier otra lengua diferente a las indicadas anteriormente sin más que aplicar la tarifa de idiomas con características similares.

v. Tareas a realizar:

Servicios de traducción y revisión.

Coordinación, gestión de proyectos y administración del servicio de traducción.

Incorporación de memorias y guías de estilo facilitadas por SEGITTUR al proceso de traducción.

Mantenimiento de la terminología, memorias y guías de estilo aplicadas.

Cualquiera otra que durante la ejecución del proyecto se estime necesaria.

b) REQUERIMIENTOS TÉCNICOS

i. Herramienta de intercambio de traducción SEGITTUR cuenta con un conector para las traducciones automatizadas. Este conector se encarga de la conexión con los gestores de contenido (OpenCMS en diferentes versiones) donde se almacena y gestiona la mayoría de contenidos que requieren traducción, aunque también pueden existir contenidos externos, como por ejemplo ficheros de literales (properties en Java). Para que los contenidos puedan ser traducidos, la empresa adjudicataria deberá proporcionar, como requisito indispensable, una herramienta a través de la cual y de forma automática, se realice el intercambio de contenidos originales y de traducciones. Este intercambio se realizará a través de un plugin vía RMI que se comunique con nuestro conector. Desde este plugin conectará vía servicio web y preferentemente en formato xml con codificación UFT-8 (en este caso cada campo llevará marcado si éste es traducible o no).



5

Los contenidos serán enviados para su traducción desde el gestor a través de la herramienta del conector de traducciones de SEGITTUR, que a su vez se integrará debidamente con el plugin desarrollado por el adjudicatario. De esta forma, se espera de vuelta un nodo xml, o fichero con el mismo formato de envío, sustituyendo los elementos traducibles por su traducción correspondiente en el idioma solicitado. Además, deberá proporcionarse un método alternativo de envío, en el que se puedan solicitar las traducciones de otros formatos (PDF, Microsoft Office, HTML o cualquier otro formato editable). Estos formatos podrán llevar texto no traducible que se indicará expresamente de acuerdo con el adjudicatario en función del formato. El fichero traducido en estos casos deberá devolverse en el mismo formato que el documento original. En el siguiente dibujo se presenta un esquema funcional del intercambio:

Empresa adjudicataria

traducción

Gestor de contenidos 1



Pasarela de traducción

Plugin empresa

adjudicaria traducción

SEGITTUR

La herramienta permitirá el envío en batch o en tiempo real y gestionar prioridades para los envíos más urgentes para su traducción de acuerdo a los plazos especificados en el epígrafe “Capacidad de traducción” del presente documento. La prioridad urgente debe necesariamente enviarse en tiempo real, mientras que las solicitudes de traducción de prioridad ordinaria podrán encolarse y hacerse llegar a la empresa adjudicataria en un solo envío por cada proyecto en modo batch. En este sentido, cada solicitud de traducción de una unidad de contenido, conllevará un identificador de fichero único, así como el identificador de proyecto al que pertenece y el identificador de envío en el que se ha hecho llegar a la empresa adjudicataria. Cabe destacar que cada solicitud de traducción puede implicar uno o varios idiomas destino. En el siguiente dibujo se presenta un esquema funcional de la relación entre ficheros (idf), envíos (ide) y proyectos (idp):



6

La empresa adjudicataria proporcionará, por tanto, para su instalación en SEGITTUR, o en las instalaciones que SEGITTUR provea a tal efecto, la herramienta informática necesaria que se encargará de los envíos para su posterior traducción, y de la recepción de los contenidos traducidos. El adjudicatario garantiza la disponibilidad al 100% de esta herramienta de intercambio de contenidos en el plazo de un mes a contar desde la fecha de formalización del correspondiente contrato, así como de los recursos necesarios disponibles para su mantenimiento en perfecto estado de funcionamiento durante toda la duración del contrato, reservándose SEGITTUR el derecho de resolver el contrato, por ser este plazo una condición esencial del mismo. La disponibilidad de dicha herramienta implica abordar los siguientes desarrollos independientes:

Desarrollo de un plugin del conector de traducciones. Ver anexo I “Guía de desarrollo de Plugins para la Pasarela de Traducción”, con definición y condiciones.

Desarrollo que se encarga de la interfaz propiamente dicha con los sistemas de traducción del adjudicatario, manteniendo la trazabilidad de estas comunicaciones, y realizando los tratamientos necesarios, que cubran la funcionalidad especificada en el presente documento. Este desarrollo debe ser abordado a expensas del



7

adjudicatario, y será de obligado cumplimiento por parte de éste que el departamento de Tecnología de SEGITTUR reciba el soporte, documentación, código fuente, tests, etc. de su API de integración.

La garantía del desarrollo debe ser de 1 año, por lo que cualquier labor correctiva correrá a cargo del adjudicatario. Se deberá hacer entrega a SEGITTUR del código fuente y plugin de integración de acuerdo al anexo I. Esta herramienta deberá permitir, además de la planificación del envío (opción de marcar envíos prioritarios), auditar la recepción con la posibilidad de rechazo de la traducción si ésta no se considera satisfactoria. Debe permitir las consultas vía API del estado de las traducciones en todo momento. Asimismo, permitirá la consulta de las incidencias surgidas o detectadas en la traducción, así como la consulta de las memorias de traducción disponibles en cada momento. Las búsquedas se podrán realizar, entre otras, por ID de fichero, ID de envío, proyecto, idiomas, usuario, rango de fechas, etc. en algún interfaz externo a la API. Por cada fichero se podrá consultar el conteo de palabras por cada idioma y por el rango de tarificación al que pertenecen en función de la actualización o repetición de las mismas según la memoria. A tal efecto, se tendrán en cuenta los rangos de tarificación descritos en el epígrafe “Uso de las Memorias” del presente documento. Asimismo, se debe mantener un histórico de los envíos y recepciones, que será accesible en todo momento desde SEGITTUR. Dicho histórico debe permitir la descarga de los ficheros traducidos en cualquier momento. De la misma forma, la herramienta deberá permitir su ejecución en cualquier momento bajo petición o por invocación desde aplicaciones desarrolladas por SEGITTUR. Cada solicitud de traducción se hará llegar a la empresa adjudicataria al menos con los siguientes datos:

Identificador del fichero

Identificador del envío

Proyecto al que pertenece

Idioma origen

Idioma destino

Contenido a traducir

Prioridad de entrega

Fecha de envío



8

Usuario que solicita la traducción

También deberá permitir informar en cada solicitud de traducción los siguientes datos:

Fecha solicitada de entrega. Únicamente para los ficheros con prioridad urgente.

Observaciones y posibilidad de adjuntar otros archivos (instrucciones, contextos, imágenes explicativas que puedan facilitar la labor de traducción) por parte de Segittur.

Añadido a lo anterior, la herramienta debe permitir el rechazo de la traducción, de tal forma que el fichero inicie inmediatamente el ciclo de traducciones para volver a ser traducido de nuevo. En estos casos, la nueva traducción siempre será tenida en consideración como urgente y la rechazada no será objeto de facturación. Si se precisara la traducción a múltiples lenguas, se cursará la solicitud de traducción a las mismas en un solo fichero. En estos casos, la traducción a todos los idiomas destino debe entregarse a la vez por parte del adjudicatario, no considerándose la entrega como efectiva en el caso en que falte por entregar al menos uno de los idiomas destino a que fue solicitada la traducción, y aplicándose las penalizaciones en plazos de entrega especificadas en el punto “Capacidad de traducción” del presente documento.

La empresa adjudicataria no deberá esperar a enviar todo un envío (ide_x) completo, sino que puede ir enviando ficheros ya traducidos (idf_x), aunque siempre completando todos los idiomas para los que se solicitó la traducción del mismo fichero.

Cabe destacar que para la mayoría de contenidos es muy probable que la traducción únicamente se requiera para un subconjunto de lenguas habituales.

La herramienta de intercambio deberá disponer de un sistema de alertas que avise de la recepción de los ficheros traducidos.

ii. Uso de las memorias SEGITTUR pondrá a disposición de la empresa adjudicataria varias memorias de traducción con el fin de reducir costes y tiempos de entrega de las traducciones. Las memorias se utilizarán para evitar traducir un texto que ya ha sido traducido anteriormente. La empresa adjudicataria actualizará y mantendrá las memorias de traducción aportando los datos de las nuevas traducciones realizadas. A tal efecto, se tendrán en cuenta los siguientes rangos de tarificación para aquellas unidades de traducción ya existentes en la memoria:

Palabras repetidas: Palabras nuevas que se repitan en el contenido a traducir (unidad de contenido o segmento).

Palabras actualizadas (95-99%): Unidad de traducción o segmento que tenga un porcentaje de coincidencia de 95-99% con una unidad registrada en la memoria de traducción.



9

Palabras actualizadas (75-94%): Unidad de traducción o segmento que tenga un porcentaje de coincidencia de 75-94% con una unidad registrada en la memoria de traducción.

Aquella unidad de traducción ya presente en la memoria, tanto si el contexto (segmentos anterior y posterior a esta unidad) es igual o diferente al registrado en memoria, ha de ser revisada y no será tenida en cuenta a efectos de facturación. Cabe destacar que los descuentos a aplicar atendiendo al volumen de actualización presupuestados por el adjudicatario serán siempre de aplicación independientemente del volumen de palabras por proyecto enviado a traducir. La memoria podrá ser consultada on-line y permitirá en todo momento su edición por parte de SEGITTUR. Del mismo modo, se deberá permitir la incorporación directa a la misma de textos en idioma destino. Las memorias actualmente vigentes se entregarán al adjudicatario al inicio del contrato en formato TMX. Deberá ser de obligado cumplimiento por parte del adjudicatario, la importación al 100% de las memorias existentes en SEGITTUR relativas a los diferentes proyectos que gestiona, dentro de los 30 primeros días a partir de la firma del contrato. Los potenciales costes de integración de estas memorias en la herramienta de traducciones, serán soportados por el adjudicatario. Una vez realizada la importación del 100% de las memorias, y con objeto de valorar la correcta importación de las memorias de traducción, SEGITTUR requerirá al adjudicatario, sin coste, las traducciones de algunos textos, de forma que éstos no representen más del 1% del volumen total del concurso, para su correspondiente traducción. La traducción necesariamente deberá acompañarse del hipotético informe económico asociado, a fin de verificar el correcto uso de las memorias. Dicho informe deberá indicar expresamente, para cada fichero, el conteo de palabras por cada idioma y por el rango de tarificación al que pertenecen, en función de la actualización o repetición de las mismas según la memoria, así como la tarifa aplicada. En caso en que la prueba arroje resultados no satisfactorios sobre la correcta integración de las memorias, se procederá a la inmediata resolución del contrato, seleccionándose como nuevo adjudicatario del servicio al siguiente licitador que haya obtenido la mejor puntuación en la valoración de ofertas. La memoria deberá estar alojada on-line, al igual que los glosarios, mediante un acceso seguro de manera que puedan ser utilizados en tiempo real por todos los miembros del equipo del proveedor asignado al proyecto, así como por el equipo responsable de SEGITTUR. Todas las actualizaciones que se realicen como consecuencia de las traducciones incrementales que se vayan realizando deben estar también disponibles en tiempo real y en uso inmediato para los archivos a traducir de forma que se produzca el máximo aprovechamiento de éstas.



10

El acceso a la memoria de traducción por parte del equipo de SEGITTUR debe permitir verificar el correcto conteo de palabras incluyendo los distintos tramos de coincidencias de las palabras a traducir. La herramienta empleada como soporte para la traducción, deberá incluir funciones de filtrado de formatos y etiquetado, creación y aplicación de memorias de traducción, conteo de palabras y gestión de terminología integrada. La empresa adjudicataria estará obligada a suministrar las memorias de traducción vigentes a la finalización del contrato, en formato TMX, en un plazo no superior a 15 días.

iii. Capacidad de traducción. Volúmenes y plazos de entrega.

Se pueden estimar los siguientes volúmenes de traducción, por grupo de palabras, calculados en base a históricos:

Donde se especifican los siguientes idiomas destino en cada grupo en la tabla anterior:

Ante posibles traducciones de idiomas no incluidos en los grupos especificados, se deberá aplicar la tarifa de idiomas con características similares.

Estim. anual Estim. anual Estim. anual Estim. anual

Nueva Repetidas Act. (95 – 99%) Act. (75 - 94%)

Palabra Grupo 1 1.403.586 804.074 106.664 195.378 167.600

Palabra Grupo 2 381.410 191.845 26.779 28.483 51.715

Palabra Grupo 3 164.059 81.752 7.402 13.083 13.378

Palabra Grupo 4 190.946 98.946 14.597 14.653 21.290

Palabra Grupo 5 93.344 51.202 2.731 6.717 13.902

Palabra Grupo 6 109.738 4.200 386 998 7.768

TOTAL 2.343.082 1.232.018 158.558 259.312 275.653

Concepto

Unidades de

traducción ya

presentes en

memoria. Coste

Concepto Idiomas

Palabra Grupo 1 Inglés, francés, alemán, italiano, portugués, chino simplificado, brasileño

Palabra Grupo 2 Danés, finés, sueco, noruego, neerlandés, coreano, árabe clásico, farsi

Palabra Grupo 3 Japonés

Palabra Grupo 4 Polaco, ruso

Palabra Grupo 5 Catalán, gallego, euskera

Palabra Grupo 6 Argentina, México



11

A tal efecto, se solicita que las empresas aporten un listado de idiomas destino disponibles, diferentes de los contemplados en la tabla anterior, indicando la similitud con alguno de los grupos definidos en dicha tabla. La empresa deberá acreditar su capacidad de traducción mediante la garantía de cumplimiento de los plazos de entrega correspondientes, y de forma simultánea, para los idiomas indicados en el epígrafe “Servicios” del presente documento, de 12.000 palabras semanales por lengua, así como los siguientes plazos máximos de entrega para la traducción de dichas palabras en función de los siguientes niveles de prioridad:

Urgente: 2 días hábiles

Ordinario: 3 días hábiles La empresa podrá ofertar la realización de mayores volúmenes de traducción y la disminución de los plazos de entrega, en los términos de calidad y metodología indicados en este documento, que serán tenidos en cuenta a efectos de valoración, siendo éstos los que se consideren a efectos de ejecución del contrato. En caso de incumplimiento de los mismos, serán de aplicación las penalizaciones que se especifican a continuación. Penalizaciones:

En caso de incumplimiento de los plazos establecidos en 3 o más días hábiles, SEGITTUR se reserva el derecho de aplicar la penalización económica que resulte de multiplicar los días hábiles en que se ha retrasado la entrega por el importe correspondiente a la capacidad de traducción diaria para cada idioma (2.400 palabras/ día por el precio cierto de cada palabra en cada idioma a que fue requerida la traducción). Si se hubiera solicitado la traducción a múltiples lenguas, habiéndose cursado la misma en un solo fichero, la traducción a todos los idiomas destino, deberá entregarse de una sola vez por parte del adjudicatario, no considerándose la entrega como efectiva en el caso en que falte por entregar al menos uno de los idiomas destino a que fue solicitada la traducción, y aplicándose las penalizaciones en plazos de entrega especificadas anteriormente.

iv. Informes

La empresa adjudicataria entregará con carácter mensual un informe en formato Excel, que contendrá al menos, la siguiente información:

Prioridad

% Reducción sobre

facturación en dichos

contenidos 1 día hábil retraso

% Reducción sobre

facturación en dichos

contenidos 2 días hábiles

retraso

Urgente 50% 70%

Ordinario 30% 50%



12

Proyecto o centro de coste asociado a la traducción

Fecha de envío

Fecha de recepción

Número de lote

Nombre de fichero enviado

ID de fichero enviado

Idioma origen

Idioma destino

Prioridad de envío

Conteo de palabras por idioma y por rango de tarificación (en función de la actualización o repetición de las mismas según la memoria), así como la tarifa aplicada en cada caso

Coste total sin IVA y con IVA por cada idioma y por cada fichero enviado

Este informe deberá ser entregado dentro de los 3 primeros días de cada mes.

c) METODOLOGÍA Y GESTIÓN: SEGITTUR designará un director técnico del proyecto, que será la persona que supervise y dirija el trabajo desarrollado por el adjudicatario para el seguimiento del proyecto. En caso de que se produzcan eventualidades que hagan variar la planificación o la organización del proyecto o de su equipo, será SEGITTUR quien autorice las soluciones más adecuadas. El adjudicatario no podrá realizar ninguna variación sin la autorización expresa de ésta.

d) CONTROL DE CALIDAD: El adjudicatario deberá realizar un control de calidad continuo a lo largo de todo el período de desarrollo del servicio. Las características formales del documento una vez traducido deberán ser las mismas del documento original remitido por SEGITTUR. Antes de su entrega, las traducciones serán debidamente revisadas y, en su caso, corregidas. Se presentarán sin errores de formato, tipográficos, mecanográficos, lingüísticos o estilísticos. Deberán contener un discurso natural y autónomo en la lengua de destino, de forma que parezcan redactados originalmente en dicha lengua. Como tareas básicas de control de calidad, la empresa adjudicataria realizará las tareas que se indican a continuación:

Controles de calidad técnica y lingüística aplicados

Memoria de la organización de los equipos, en la que se indicarán los procedimientos adoptados para la correcta prestación de servicio, de las medidas



13

que se prevén aplicar para garantizar el éxito del proyecto, así como el plan de contingencias a aplicar en caso de fallo del sistema

Revisión de la traducción al menos por un segundo traductor nativo alternativo al que realizó la traducción.

Control por parte de un director de proyecto designado por la empresa adjudicataria durante todo el proceso, y previo a cada entrega. Este director de proyecto deberá ser el responsable de cara a SEGITTUR de la ejecución técnica del objeto del contrato, actuando como interlocutor, con capacidad decisoria, con el responsable de dirección del proyecto de SEGITTUR.

Uso de glosarios terminológicos: vocabulario clave y específico previamente identificado, traducido y validado de forma conjunta, y contrastado con otras fuentes oficiales.

Uso de guías de estilo específicas: normas de estilo y comunicación en cada una de las lenguas destino en la traducción.

Protocolo de comunicaciones de incidencias, en caso de fallo del sistema.

Uso de Memoria de traducción

Plan de contingencia ante fallo del sistema.

SEGITTUR se reserva el derecho de realizar controles de calidad aleatorios, mediante traducciones de textos ya traducidos por el adjudicatario. SEGITTUR se reserva el derecho de aplicar la penalización económica que resulte de calcular el 50% del importe correspondiente a la traducción del envío completo (ide_x) en que fue requerida la traducción original del fichero, en el caso en que el resultado de estos controles arroje discrepancias fundamentales sobre los textos ya traducidos por el adjudicatario.

e) CERTIFICACIONES El licitador deberá contar con los siguientes certificados sobre la metodología de gestión de Servicios: Sistema de gestión de calidad ISO 9001 (que especifica los requisitos para un Sistema de Gestión de la Calidad adecuado) y de traducción de contenidos ISO 17100 o en su defecto UNE-EN-15038. Todo ello, bajo la dirección, control y seguimiento de SEGITTUR.



14

2. EJECUCIÓN Y GESTIÓN DEL PROYECTO.

El adjudicatario designará una persona como Coordinadora del Proyecto, que asumirá las labores de interlocutor con el Director Técnico nombrado por SEGITTUR.

Asimismo, la empresa adjudicataria destinará al servicio un equipo de trabajo formado al menos por Traductores y revisores nativos, cuya lengua materna sea el idioma destino, con experiencia profesional, al menos, en un proyecto de características similares en los últimos tres años. Es decir, con experiencia en traducción de contenido online en una de las siguientes áreas de conocimiento: turismo o arte y cultura.

3. ADJUDICACIÓN

Los criterios objetivos que han de servir de base para la adjudicación de la contratación son los que figuran en el Pliego de Bases.

APROBADO POR EL ÓRGANO DE CONTRATACIÓN

Noviembre de 2017



15

ANEXO I GUÍA DE DESARROLLO DE PLUGINS PARA LA PASARELA DE TRADUCCIÓN

I. INTRODUCCIÓN

El presente documento no tiene como objetivo ser una guía exhaustiva de cómo desarrollar

un plugin1 que sea compatible con la pasarela de traducción implantada en Segittur, pero sí

dar una serie de directrices y sugerencias que faciliten y reduzcan al máximo el tiempo de

desarrollo del mismo. En los sucesivos apartados se enumerarán los requisitos, se

describirá detalladamente el API y se mostrará paso a paso como desarrollar con un sencillo

ejemplo un plugin de comunicación con una plataforma externa de traducción.

El plugin será básicamente un servicio RMI2 con una serie de sencillos métodos que nos

abstraerán de la complejidad y particularidades de los posibles servicios a los que se desee

enviar los archivos a traducir.

II. REQUISITOS

El plugin ha de poder ejecutarse en un entorno con las siguientes características:

Linux versión 2.6.32

Java versión 1.8.0_77

Opcional: MySQL 5.1.66

III. DESCRIPCIÓN del API

El plugin deberá implementar un API de servicio, el cual será suministrado en el archivo

rmi-plugin-api-1.1.jar, el cual pasaremos a describir a continuación.

a) DIAGRAMA DE CLASES

Paquete: es.segittur.translationgateway.rmi

1 Plugin: Un complemento es una aplicación que se relaciona con otra para aportarle una función nueva y

generalmente muy específica. Esta aplicación adicional es ejecutada por la aplicación principal e interactúan por medio de la API. También se conoce como plug-in, add-on, conector o extensión.

2 RMI (Java Remote Method Invocation): es un mecanismo ofrecido por Java para invocar un método de manera

remota. Forma parte del entorno estándar de ejecución de Java y proporciona un mecanismo simple para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java.



16

Clases:

RemoteServiceException: Excepción que lanzarán cada método del api si se

produce cualquier problema, y que extiende directamente de

java.rmi.RemoteException

ReliableRemoteServiceException: Especialización de la excepción más genérica

RemoteServiceException. Indica que el error es temporal y que se deberá intentar

realizar la solicitud más adelante cuando el servicio haya sido reestablecido.

Priority: Enumeración con los diferentes tipos de prioridad en los trabajos de

traducción.

TranslationService: Interfaz de servicio que todo plugin debe implementar, para

posteriormente ser expuesta como un servicio RMI.

class Class Mo...

«enumeration»

Priority

LOW

MEDIUM

HIGH

Attributes

- priority: int

- Priority(int)

+ getPriority() : int

Exception

RemoteServ iceException

+ detail: Throwable

+ getCause() : Throwable

+ getMessage() : String

+ RemoteServiceException()

+ RemoteServiceException(String)

+ RemoteServiceException(String, Throwable)

RetriableRemoteServ iceException

+ RetriableRemoteServiceException()

+ RetriableRemoteServiceException(String)

+ RetriableRemoteServiceException(String, Throwable)

«interface»

TranslationServ ice

+ approve(Long) : void

+ cancel(Long, String) : boolean

+ getTranslatedFile(Long, String) : byte[]

+ isRunning() : boolean

+ isTranslated(Long, String) : boolean

+ reject(Long, String, String[]) : void

+ submitFile(Long, String, byte[], String, String, String, Priority, Date, String, String[]) : void



17

b) DESCRIPCIÓN DE LOS MÉTODOS A continuación, se muestra detalladamente cuales son los métodos de la interfaz TranslationService que se deben implementar.

submitFile Envío de fichero al servicio de traducción. Parámetros:

Nombre Tipo Descripcion

jobId Long El identificador del trabajo actual. Si el servicio de traducción genera su propio id, este debe ser asociado a este identificador.

fileName String El nombre del fichero a traducir.

content Byte[] El contenido del archivo como un array de bytes codificado en UTF-8

comment String Comentario que será almacenado junto con el contenido, proporcionando información adicional útil en el proceso de traducción.

project String El proyecto al que pertenece el fichero.

requester String El usuario que realiza la solicitud.

priority Priority La prioridad del trabajo. Puede ser LOW, MEDIUM o HIGH.

estimatedDeliveryDate Date Fecha para la que se espera esté lista la traducción. Este campo es opcional.

sourceLanguage String Lenguaje del fichero original. Se utilizará preferiblemente el estandard BCP 47, aunque puede adaptarse a cualquier representación compatible con la plataforma de traducción destino.

targetLanguages String[] Lista de los lenguajes a los que se desea traducir.

Devuelve:

Void



18

Lanza:

RemoteServiceException Cuando ocurre cualquier error. Si el error es temporal y se desea que la operación sea reintentada posteriormente, se debe utilizar RetriableRemoteServiceException.

RemoteException Excepción genérica de servicios RMI.

isTranslated Comprueba si el fichero ha sido traducido al idioma indicado. Parámetros:


jobId Long El identificador del trabajo.

lang String El idioma destino.

Devuelve:

Boolean Si el fichero ha sido traducido o no.

Lanza:



getTranslatedFile Descarga el fichero traducido en el idioma indicado codificado en UTF-8. Parámetros:





19

lang String El idioma destino.

Devuelve:

Byte[] El contenido del fichero codificado en UTF-8.

Lanza:



reject Rechaza el contenido traducido en los idiomas indicados. Parámetros:



comment String Comentario acerca del problema con los contenidos traducidos

languages String[] Los idiomas que van a ser rechazados

Devuelve:

Void

Lanza:





20

approve Aceptar la traducción. El flujo puede ser cerrado. Parámetros:



Devuelve:

Void

Lanza:



cancel

Cancela completamente el trabajo actual. Parámetros:



Comment String Comentario acerca del problema con el trabajo.

Devuelve:

Boolean Si el trabajo ha podido ser cancelado o no.

Lanza:





21

isRunning

Método utilizado para comprobar que el servicio RMI está funcionando correctamente y que existe comunicación con el servicio de traducción remoto. Parámetros:

Devuelve:

Boolean Si todo funciona correctamente. Lanza:



c) SECUENCIA DE MENSAJES Por simplicidad, se contemplará únicamente un caso de uso para describir el sistema actual, la traducción de un documento. Comenzaremos enviando el fichero indicando todos los idiomas en los que queremos obtener una traducción. Siempre y cuando no hayamos recibido ninguna traducción, se le dará la posibilidad al usuario de realizar la cancelación del trabajo si ha cometido algún error al enviar un documento. Esta llamada tendrá que tener siempre la aceptación por parte del servicio remoto de traducción. En caso de no poder cancelarse, el flujo continuará con la ejecución. Cada cierto periodo de tiempo, se interrogará al servicio acerca del estado de la traducción para un trabajo y un idioma dado. Si la traducción está disponible, se procederá a su descarga, repitiendo este proceso para todos los idiomas hasta que todos los idiomas de un trabajo estén traducidos. Una vez el usuario final ha revisado los documentos recibidos, puede o bien aceptar las traducciones dando por terminado el flujo, o bien rechazar alguna traducción si encuentra algún tipo de problema, en cuyo caso volveríamos a repetir el proceso anterior de consulta hasta que la nueva traducción esté disponible para descargar. A continuación, se mostrará el diagrama de secuencia del flujo completo de traducción.



22

IV. IMPLEMENTACIÓN

El programador tendrá la responsabilidad final de decidir cómo quiere implementar el plugin, siendo los datos que se dan a continuación meras recomendaciones para simplificar el proceso de desarrollo. Pero si se decide seguir los pasos que se dan en esta guía, se entenderá que el programador tiene experiencia en las siguientes tecnologías:

Eclipse

sd Use Case Model

«interface»

Class

Model::TranslationServicePasarela de Traducción

opt

[isTranslated]

loop

[pendingTranslations]

alt

[approve]

[reject]

opt

[cancel]

«Pre-condition»

{Ningún idioma ha sido

traducido}

loop

[pendingTranslations]

opt

[isTranslated]

loop

[repeatUntilApprove]

submitFile(Long, String, byte[], String, String, String, Priority, Date, String, String[])

cancel(Long, String) :boolean

isTranslated(Long, String) :boolean

getTranslatedFile(Long, String) :byte

[pendingTranslations -1]:

approve(Long)

reject(Long, String, String[])

isTranslated(Long, String) :boolean

getTranslatedFile(Long, String) :byte

[pendingTranslations -1]:



23

Maven

Java

Spring

junit

a) CREACIÓN DE UN NUEVO PROYECTO Creamos un nuevo proyecto en Maven con las siguientes opciones, sustituyendo el group id y el artifact id, por lo que corresponda:

La estructura del proyecto resultante será la siguiente:



24

Para poder añadir la dependencia del API, añadiremos el artefacto al repositorio local con el siguiente comando maven: mvn install:install-file –Dfile=<path-to-rmi-plugin-api-1.1.jar>

A continuación, editaremos el fichero pom.xml, que quedará como sigue:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.mycompany.plugin</groupId> <artifactId>my-plugin</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <properties> <java.version>1.8</java.version> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.3.RELEASE</version> </parent> <dependencies> <dependency> <groupId>es.segittur.translationgateway</groupId> <artifactId>rmi-plugin-api</artifactId>



25

<version>1.1</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <mainClass>com.mycompany.plugin.Application</mainClass> <layout>ZIP</layout> </configuration> <executions> <execution> <goals> <goal>repackage</goal> </goals> </execution> </executions> </plugin> <plugin> <artifactId>maven-assembly-plugin</artifactId> <configuration> <archive> <manifest>

<mainClass>com.mycompany.plugin.Application</mainClass> </manifest> </archive> <descriptorRefs> <descriptorRef>jar-with-dependencies</descriptorRef> </descriptorRefs> </configuration> </plugin> </plugins> </build> </project>

Spring dispone de una serie de dependencias “starters” que simplifican notablemente el proceso de añadir nuevas dependencias al proyecto. En el ejemplo de POM mostrado anteriormente, se utiliza la dependencia spring-boot-starter-parent en la sección parent, la cual proporciona ciertas configuraciones por defecto. La versión podría omitirse, utilizándose en ese caso la última versión disponible en el repositorio.



26

En la sección de plugins, el spring-boot-maven-plugin reempaquetará el jar construido durante la fase de empaquetado. Se le ha de indicar la clase que contiene el método main para que el jar gererado sea ejecutable. A continuación, añadiremos la clase principal que contiene el método main:

package com.mycompany.plugin; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.context.ApplicationContext; @SpringBootApplication public class Application { public static void main(String[] args) { ApplicationContext ctx = SpringApplication.run(Application.class, args); } }

Necesitaremos configurar nuestro servicio de RMI, para lo cual añadiremos la siguiente clase de configuración:

package com.mycompany.plugin.configuration; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.remoting.rmi.RmiServiceExporter; import es.segittur.translationgateway.rmi.TranslationService; @Configuration public class ApplicationConfiguration { @Bean public RmiServiceExporter registerService(@Value("#{myService}")TranslationService tService) { RmiServiceExporter rmiServiceExporter = new RmiServiceExporter(); rmiServiceExporter.setServiceName("MyPlugin"); rmiServiceExporter.setService(tService); rmiServiceExporter.setServiceInterface(TranslationService.class); rmiServiceExporter.setRegistryPort(1099); return rmiServiceExporter; } }



27

A continuación, solo resta generar la clase que implementará nuestro servicio:

package com.mycompany.plugin.service; import java.rmi.RemoteException; import java.util.Date; import org.springframework.stereotype.Service; import es.segittur.translationgateway.rmi.Priority; import es.segittur.translationgateway.rmi.RemoteServiceException; import es.segittur.translationgateway.rmi.TranslationService; @Service public class MyService implements TranslationService { public void approve(Long jobId) throws RemoteException { // TODO Auto-generated method stub } public boolean cancel(Long jobId, String comment) throws RemoteException { // TODO Auto-generated method stub return false; } public byte[] getTranslatedFile(Long jobId, String lang) throws RemoteServiceException { // TODO Auto-generated method stub return null; } public boolean isRunning() throws RemoteException { // TODO Auto-generated method stub return true; } public boolean isTranslated(Long jobId, String lang) throws RemoteException { // TODO Auto-generated method stub return false; } public void reject(Long jobId, String comment, String[] languages) throws RemoteException { // TODO Auto-generated method stub }



28

public void submitFile(Long jobId, String fileName, byte[] content, String comment, String project, String requester, Priority priority, Date estimatedDeliveryDate, String sourceLanguage, String[] targetLanguages) throws RemoteException { // TODO Auto-generated method stub } }

Para comprobar que todo funciona correctamente, se inicia el programa utilizando el comando maven spring-boot:run:

También podemos crear un sencillo ejemplo de test unitario que, en esta versión inicial, compruebe que el servicio RMI se está ejecutando correctamente:

import static org.junit.Assert.*; import java.rmi.RemoteException; import org.junit.Test; import org.junit.runner.RunWith; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Qualifier; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.ComponentScan; import org.springframework.context.annotation.Configuration; import org.springframework.remoting.rmi.RmiProxyFactoryBean; import org.springframework.test.context.ContextConfiguration; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import com.mycompany.plugin.configuration.ApplicationConfiguration; import es.segittur.translationgateway.rmi.TranslationService;



29

@RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = {ApplicationConfiguration.class, MyPluginTest.Config.class}) public class MyPluginTest { @Configuration @ComponentScan("com.mycompany.plugin.service") static class Config { @Bean(name="client") public TranslationService createTranslationService() { RmiProxyFactoryBean rmiProxyFactoryBean = new RmiProxyFactoryBean(); rmiProxyFactoryBean.setServiceUrl("rmi://localhost:1099/MyPlugin"); rmiProxyFactoryBean.setServiceInterface(TranslationService.class); rmiProxyFactoryBean.afterPropertiesSet(); return (TranslationService) rmiProxyFactoryBean.getObject(); } } @Autowired @Qualifier("client") TranslationService ts; @Test public void testRunning() throws RemoteException { assertTrue(ts.isRunning()); } }

El test unitario carga el contexto de la aplicación, crea una instancia de un cliente RMI y comprueba que el cliente es capaz de llamar al servicio remoto “isRunning” sin lanzar ninguna excepción, devolviendo true. Si lanzamos el test, deberemos observar algo como lo siguiente:



30

Ya tenemos nuestro servicio funcionando y una manera de verificar el correcto funcionamiento por RMI.

i. Añadir un WEB SERVICE al proyecto.

El intefaz con un servicio web SOAP está encapsulado en un WSDL. JAXB proporciona un método sencillo para generar las clases necesarias a partir del WSDL (o en su defecto, el XSD que contenga la sección <types/> del wsdl. Añadiremos la siguiente dependencia al pom.xml

<dependency> <groupId>org.springframework.ws</groupId> <artifactId>spring-ws-core</artifactId> </dependency>

Y configuraremos el plugin que genera las clases para el webservice: <plugin>

<groupId>org.jvnet.jaxb2.maven2</groupId>

<artifactId>maven-jaxb2-plugin</artifactId>

<version>0.13.1</version>

<executions>

<execution>

<goals>

<goal>generate</goal>

</goals>

<configuration>

<schemaLanguage>WSDL</schemaLanguage>

<generatePackage>com.webservicex</generatePackage>

<schemas>

<schema>

<url>http://www.webservicex.net/TranslateService.asmx?WSDL</url>

</schema>

</schemas>

</configuration>

</execution>

</executions>

</plugin>

Esta configuración generará las clases del webservice encontrado en la ulr proporcionada y las pondrá en el paquete com.webservicex. No será necesario añadir ningún paso adicional ya que la generación de objetos de JAXB se integra automáticamente al ciclo de vida de la compilación.



31

Los objetos generados serán los siguientes:

ii. Crear el cliente del servicio de traducción

Para crear el cliente deberemos extender la clase WebServiceGatewaySupport e implementar todas las operaciones a realizar: package com.mycompany.plugin.client;

import org.springframework.ws.client.core.support.WebServiceGatewaySupport;

import org.springframework.ws.soap.client.core.SoapActionCallback;

import com.webservicex.Translate;

import com.webservicex.TranslateResponse;

public class TranslationClient extends WebServiceGatewaySupport {

public TranslateResponse Translate(String text, String lang) {

String mode = null;

switch(lang) {



32

case "fr" :

mode = "SpanishToFrench";

case "en" :

default :

mode = "SpanishTOEnglish";

}

Translate request = new Translate();

request.setText(text);

request.setLanguageMode(mode);

return (TranslateResponse) getWebServiceTemplate()

.marshalSendAndReceive(

"http://www.webservicex.net/TranslateService.asmx?WSDL",

request,

new

SoapActionCallback("http://www.webservicex.net/Translate"));

}

}

En el ejemplo anterior solo se contemplan las traducciones al inglés y francés. Se necesitará un único método, el cual tomará un texto y el idioma destino y devolverá el texto traducido por el servicio web. Tanto la clase Translate como TranslateResponse han sido generadas por JAXB a partir del WSDL. Se utiliza una instancia de WebServiceTemplate suministrada por la clase base WebServiceGatewaySupport para realizar el intercambio de información SOAP. Para realizar la llamada al servicio web necesitamos la URI, el objeto para construir el payload de la solicitud y el SoapActionCallback que será pasado en la cabecera del soapAction junto a la request.

iii. Configurar los componentes del web service

Spring WS utiliza el módulo OSX que utiliza Jaxb2Marshaller para serializar y deserializar solicitudes XML. Añadiremos a la clase ApplicationConfiguration los siguientes métodos: @Bean

public Jaxb2Marshaller marshaller() {

Jaxb2Marshaller marshaller = new Jaxb2Marshaller();

marshaller.setContextPath("com.webservicex");

return marshaller;

}

@Bean



33

public TranslationClient translationClient(Jaxb2Marshaller

marshaller) {

TranslationClient client = new TranslationClient();

client.setDefaultUri("http://www.webservicex.net/TranslateService.asm

x?WSDL");

client.setMarshaller(marshaller);

client.setUnmarshaller(marshaller);

return client;

}

iv. Completar clase de servicio

Ahora podemos añadir la implementación de nuevos métodos a la clase de servicio, que quedará como sigue: @Service

public class MyService implements TranslationService {

private Map<String,byte[]> translations = new

HashMap<String,byte[]>();

@Autowired

TranslationClient client;

public void approve(Long jobId) throws RemoteException {

// TODO Auto-generated method stub

}

public boolean cancel(Long jobId, String comment) throws

RemoteException {


return false;

}

public byte[] getTranslatedFile(Long jobId, String lang)

throws RemoteServiceException {

return translations.get(jobId + "_" + lang);

}

public boolean isRunning() throws RemoteException {

return true;

}

public boolean isTranslated(Long jobId, String lang)

throws RemoteException {

return translations.containsKey(jobId + "_" + lang);

}

public void reject(Long jobId, String comment, String[] languages)




34


}

public void submitFile(

Long jobId,

String fileName,

byte[] content,

String comment,

String project,

String requester,

Priority priority,

Date estimatedDeliveryDate,

String sourceLanguage,

String[] targetLanguages)


TranslateResponse response = null;

for (String lang: targetLanguages) {

try {

response = client.Translate(new String(content,

"UTF-8"), lang);

translations.put(jobId + "_" + lang,

response.getTranslateResult().getBytes("UTF-8"));

} catch (UnsupportedEncodingException e) {

throw new RemoteException(e.getMessage());

}

}

}

}

En el ejemplo se guardan las traducciones en un simple mapa, queda para desarrollos futuros reemplazar dicha implementación por algo más persistente.

v. Completar los test unitarios

Se podría completar el conjunto de test unitarios con una llamada al servicio de traducción añadiendo el siguiente método: @Test

public void testTranslate() throws RemoteException,

UnsupportedEncodingException {

Long jobId = new Long(1);

ts.submitFile(jobId, "my_file.xml", "Hola mundo".getBytes("UTF-

8"), "comment", "", "", Priority.LOW, null, "es", new String[] {"en"});

assertTrue(ts.isTranslated(jobId, "en"));

assertEquals("Hello world", new

String(ts.getTranslatedFile(jobId, "en"), "UTF8"));



35

}

En este ejemplo, se traduce un simple “Hola mundo” y se verifica que el testo devuelto por la traducción sea “Hello world”. A continuación, se ofrece una sugerencia de posibles pruebas unitarias a realizar, dado que no siempre es posible obtener traducciones inmediatas de contenidos que se acaban de enviar a traducir, puede ser necesario cargar el sistema con datos para los test:

Prueba de conexión con el servicio

Descripcion: Verificar el estado de las comunicaciones entre el plugin RMI y el servicio de traducción remoto.

Prerrequisitos:

Pasos: Llamada al método RMI isRunning()

Se establece comunicación con el servicio remoto de

traducción.

Resultado esperado:

El método devuelve verdadero.

Resultado obtenido:

Flujo completo de traducción

Descripcion: Se realiza el flujo completo de traducción de un archivo

Prerrequisitos: El id de trabajo no está dado de alta en el sistema.

Pasos: Llamada al método RMI submitFile() para los idiomas

inglés, francés, alemán e italiano.

Llamada al método RMI isTranslated(), el cual deberá

devolver true. Si no se puede generar una traducción

inmediata, cambiar el id de trabajo por otro que haya

sido precargado.

Llamar al método RMI getTranslatedFile() para cada

uno de los idiomas. Comparar el contenido de los

archivos descargados con el resultado esperado para

cada idioma.



36

Llamar al método RMI cancel(). Deberá devolver

falso, ya que el trabajo tiene traducciones creadas.

Llamar al método RMI reject() para el idioma francés.

Volver a llamar al método RMI getTranslatedFile()

para el idioma francés y obtener una nueva

traducción.

Llamar al método RMI approve().

Resultado esperado:

Se han obtenido todas las traducciones sin problemas.

Resultado obtenido:

Cancelar flujo de traducción

Descripcion: Se realiza el flujo parcial de traducción de un archivo, justo hasta el momento en el que puede ser cancelado.


Pasos: Llamada al método RMI submitFile() para los idiomas

inglés, francés, alemán e italiano.

Llamada al método RMI isTranslated(), el cual deberá

devolver false.

Llamar al método RMI cancel(), y comprobar que

devuelve verdadero.

Resultado esperado:

Se creado el trabajo de traducción, pero está en un estado cancelado.

Resultado obtenido:

Comprobar si un trabajo inexistente ha sido traducido

Descripcion: Se pregunta por el estado de un trabajo que no debería existir en el sistema


Pasos: Llamada al método RMI isTranslated()



37

Capturar la excepción remota que indica que el id no

está dado de alta en el sistema.

Resultado esperado:

Se ha lanzado una RemoteException indicando que el id no existe.

Resultado obtenido:

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE REGIR LA ... · documento original. En el siguiente...

Documents

Transcript of PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE REGIR LA ... · documento original. En el siguiente...