Categoría: Web Services

Categorías
PHP Web Services

Uso del servicio web PHP de Alfresco para cargar archivos

El siguiente es el código PHP para cargar archivos usando Alfresco Web Service. Pongo algunos comentarios dentro del código. Si hay algo que te confunda, deja tu comentario y espero poder ayudarte.

 if (isset($_SERVER["ALF_AVAILABLE"]) == false)
 {
 	require_once "./alfresco_sdk/remote/Alfresco/Service/Repository.php";
 	require_once "./alfresco_sdk/remote/Alfresco/Service/Session.php";
 	require_once "./alfresco_sdk/remote/Alfresco/Service/SpacesStore.php";
 	require_once "./alfresco_sdk/remote/Alfresco/Service/ContentData.php";
 }
 $repositoryUrl = "http://localhost:8080/alfresco/api";
 $userName = "admin";
 $password = "admin";
 
 // Authenticate the user and create a session
 $repository = new Repository($repositoryUrl);
 $ticket = $repository->authenticate($userName, $password);
 $session = $repository->createSession($ticket);
 
 // Create a reference to the 'SpacesStore'
 $spacesStore = new SpacesStore($session);
 
 $dir_name =  "s".$irbID;
 
 // Use a serach to get the guest home space we will use to place the new content in
 $nodes = $session->query($spacesStore, "PATH:"app:company_home/cm:testing/cm:$dir_name"");
 
 if(!empty($nodes)){
 	echo "good, no need to do anything.";
 }else{
 	$nodes = $session->query($spacesStore, "PATH:"app:company_home/cm:testing"");
 	$contentNode = $nodes[0];
 	$newSpace = $contentNode->createChild('cm_folder', 'cm_contains', 'cm_'.$dir_name);//here has to be cm_ as it is here.
 	$newSpace->cm_name = $dir_name;
 	$newSpace->cm_title = "This is a title";
 	$newSpace->cm_description = 'Description of Space';
 	$session->save();
 	unset($session);
 	$session = $repository->createSession($ticket);
 	$nodes = $session->query($spacesStore, "PATH:"app:company_home/cm:testing/cm:$dir_name"");
 }
 
 $guestHome = $nodes[0];
 
 // Get the name of the new node
 $name = $_POST['txt_docs_title'];
 
 $contentNode = $guestHome->createChild("cm_content", "cm_contains", "cm_".$name);//!!the folder's name has to begin with 'cm_' otherwise, using web service can not find it later.
 $contentNode->addAspect("cm_titled");
 
 // Set the name, title and description property values
 $contentNode->cm_name = $name;
 $contentNode->cm_title = $_POST['num_ct_ID'];
 $contentNode->cm_description = "testing description --program creek";
 
 // Set the content onto the standard content property for nodes of type cm:content.
 // We are going to assume the mimetype and encoding for ease
 $contentData = $contentNode->updateContent("cm_content", $_FILES['document']['type'], "UTF-8");
 
 // Set the content to be the content file uploaded from the client
 $contentData->writeContentFromFile($_FILES["document"]["tmp_name"]);
 
 // Save the new node
 $session->save();

Artículos Relacionados:

  1. Github: agregue directorio / archivos locales al repositorio remoto de Github
  2. Acceda a ServletContext desde dentro de un servicio web JAX-WS
  3. Carga y descarga de archivos PHP ftp código
  4. Programe una tarea de Java para que se ejecute en un momento determinado y envuélvala como un servicio de Windows

Categorías
Web Services

Análisis de requisitos para el sistema de gestión de archivos centralizado

El siguiente es el resumen de requisitos para crear un nuevo sistema de administración de archivos centralizado (FMS):

1. Después de fusionar el FMS central, cada sistema individual utilizará el servicio web para conectarse a él. Y todos los archivos y la información relacionada se colocarán en un lugar central.

2. La central debe tener las siguientes funciones:

  • Autenticar
  • Cargar (con toda la información relacionada, como el nombre del archivo, el número de versión y la categoría)
  • Actualización (reversión)
  • ListFile (todas las versiones de un archivo)
  • Descargar
  • Borrar
  • Rebautizar
  • AccessVerify

3. Cada sistema debe cambiarse lo menos posible al fusionar el FMS central.

Para ilustrar la situación, lea el siguiente diagrama.

Artículos Relacionados:

  1. Carga de archivos Java en Servlet mediante el componente FileUpload de Apache commons (código de muestra)
  2. Instalar el complemento Maven para Eclipse
  3. La mayor teoría para el análisis de datos.
  4. Cómo funciona el complemento Eclipse: análisis de un menú simple

Categorías
JSP/JSF Web Services

Acceda a ServletContext desde dentro de un servicio web JAX-WS

En un proyecto J2EE típico, colocamos el parámetro inicial del nivel de aplicación en la etiqueta context-param en web.xml, como la configuración de la base de datos, la dirección de correo electrónico del administrador, etc.

Los valores dentro del se puede acceder al elemento así:

String value = 
getServletContext().getInitParameter("name_of_context_initialization_parameter");

Cuando se trata de Web Service, surge el mismo problema.

¿Qué sucede si queremos poner la información de configuración de la base de datos en un archivo de configuración y dejar que Web Service acceda a él? Queremos que la información de configuración no esté codificada y, por lo tanto, se pueda cambiar durante la etapa de implementación.

Afortunadamente para nosotros, el servicio web también puede acceder al contexto del servlet. El contexto de servlet está disponible por JAX-WS a través del contexto del mensaje, que se puede recuperar utilizando el contexto del servicio web. Insertar el siguiente miembro hará que JAX-WS inyecte una referencia al contexto del servicio web en su servicio web:

@Resource
private WebServiceContext context;

Luego, puede acceder al contexto del servlet usando:

ServletContext servletContext =
    (ServletContext) context.getMessageContext().get(MessageContext.SERVLET_CONTEXT);

¿Qué hay de otras formas de poner información de configuración para Java Web Service?

Artículos Relacionados:

  1. Nivel de acceso de Java para miembros: público, protegido, privado
  2. Coloque la conexión de la base de datos en ServletContextListener
  3. Uso del servicio web PHP de Alfresco para cargar archivos
  4. Programe una tarea de Java para que se ejecute en un momento determinado y envuélvala como un servicio de Windows

Categorías
JSP/JSF Web Services

La forma correcta de implementar un proyecto web Java

Desarrollé un proyecto de servicio web Java en mi caja local. Ha funcionado bien con mis pruebas. Ahora necesito implementar este proyecto en un servidor remoto, al que se le asignará un nombre de dominio estático para nuestro departamento. Busqué en todas partes y finalmente encontré las siguientes formas de implementar un proyecto web.

1. Implementar artefactos ensamblados en la caja de producción

Aquí, creamos el archivo .war, lo configuramos para producción (posiblemente creando numerosos artefactos para numerosas cajas) y colocamos los artefactos resultantes en los servidores de producción.

Pros: No hay herramientas de desarrollo en las cajas de producción, puede reutilizar los artefactos de las pruebas directamente, el personal que realiza la implementación no necesita conocimientos del proceso de compilación
Contras: dos procesos para crear y desplegar artefactos; la configuración potencialmente compleja de artefactos prediseñados podría dificultar la secuenciación / automatización del proceso; tener que versionar artefactos binarios

2. Construye los artefactos en la caja de producción.

Aquí, el mismo proceso que se usa día a día para construir e implementar localmente en cajas de desarrollador se usa para implementar en producción.

Pros: Un proceso para mantener; y está fuertemente probado / validado por uso frecuente. Potencialmente más fácil de personalizar la configuración en el momento de la creación del artefacto en lugar de personalizar el epílogo del artefacto preconstruido; no se necesita control de versiones de artefactos binarios.
Contras: Se necesitan herramientas de desarrollo potencialmente complejas en todas las cajas de producción; el personal de implementación debe comprender el proceso de construcción; no estás implementando lo que probaste
He utilizado principalmente el segundo proceso, ciertamente por necesidad (sin tiempo / prioridad para otro proceso de implementación). Personalmente, no compro argumentos como «la caja de producción tiene que estar limpia de todos los compiladores, etc.», pero puedo ver la lógica en implementar lo que has probado (en lugar de construir otro artefacto).

Sin embargo, las aplicaciones Java Enterprise son tan sensibles a la configuración que se siente como si tuviera problemas con dos procesos para configurar artefactos.

Eso es lo que obtuve de mi compañero de trabajo.

Esta es la forma correcta:

Construir sobre la caja de producción es incorrecto, porque significa que está usando una construcción diferente a la que probó. También significa que cada máquina de implementación tiene un archivo JAR / WAR diferente. Por lo menos, haga una compilación unificada solo para que cuando realice el seguimiento de errores no tenga que preocuparse por las inconsistencias entre los servidores.

Además, no necesita poner las compilaciones en el control de versiones si puede mapear fácilmente entre una compilación y la fuente que la creó.

Donde trabajo, nuestro proceso de implementación es el siguiente. (Esto es en Linux, con Tomcat).

  1. Pruebe los cambios y verifique en Subversion. (No necesariamente en ese orden; no requerimos que se pruebe el código comprometido. Soy el único desarrollador a tiempo completo, por lo que el árbol SVN es esencialmente mi rama de desarrollo. Su kilometraje puede variar).

  2. Copie los archivos JAR / WAR a un servidor de producción en un directorio compartido con el nombre del número de revisión de Subversion. Los servidores web solo tienen acceso de lectura.

  3. El directorio de implementación contiene enlaces simbólicos relativos a los archivos en los directorios con nombre de revisión. De esa manera, una lista de directorios siempre le mostrará qué versión del código fuente produjo la versión en ejecución. Al implementar, actualizamos un archivo de registro que es poco más que una lista de directorios. Eso facilita los retrocesos. (Sin embargo, un problema; Tomcat busca nuevos archivos WAR antes de la fecha de modificación del archivo real, no el enlace simbólico, por lo que tenemos que tocar el archivo anterior al retroceder).

Nuestros servidores web descomprimen los archivos WAR en un directorio local. El enfoque es escalable, ya que los archivos WAR están en un solo servidor de archivos; podríamos tener un número ilimitado de servidores web y hacer una sola implementación.

Artículos Relacionados:

  1. Cómo implementar Spring Project en Live Server
  2. ¿Compartir un proyecto de Eclipse en GitHub en 2 pasos?
  3. Utilice ASTParser para analizar un proyecto Java
  4. Contar el número total de métodos en un proyecto Java