The solution to this error should be review Spring Messaging and Websocket version to charge 4.3.5.RELEASE version, there are somes changes from version 4.1.2.RELEASE to 4.3.5.RELEASE specially in Tyrus container and application server distribution.
Error:
Error during WebSocket handshake: Unexpected response code: 500
There are two common errors when you import a proyect in Android Studio like these two:
"Gradle DSL method not found: 'android()'" //appears on Gradle 2.x
"Could not find method android() for arguments" //appers on Gradle 3.x
1. It can be solved modifying two build.gradle files, first gradle file at parent should be look like:
2. And the second gradle file inside app folder should have android declaration:
This error occurs when you have android declaration inside gradle parent file.
I remembered that 2014 was a year of several incubation software technology releases, Spring boot and Docker start to be published in several media articles nominated to be next used solution in projects, considering at that time Cloud computing was received for enterprise as possible solution of storing, high-concurrency and service problems, I convince myself after some test and construction that Cloud was still in design in terms of infrastructure in those days and they were to intent encourage IT people to start research and development for cultivate the next bag of solution patterns that cloud computing could offer, behind scenes there was software design that has several permutations of solutions some of them were architectures based on components or services looking for being adapted in those stores of Cloud Computing, hardly said software programmers and architects are doing well to show his better design to persist in distributed computing field. Scheduling computing and inference motor were computer designs that I was working on at that time and in the mid-time keeping an eye on those solutions (specially developed in the United States), Cloud computing has a third iteration of "wisdom" accumulated knowledge has been gained and has been released for non cloud architecture to adaptable and compatible to be interconnected with enterprise infrastructure, "Containers" is a fantastic pattern of solution in Cloud computing that everyone is testing or implementing on theirs architectures, back in history it took about 7 years of research to solve how "Cloud computing" should operate, names like Google, Amazon, Microsoft, Red Hat and IBM were behind of those papers, software and infrastructure and after of this third iteration we have new terminology like DevOps that describes how a group of people should operate to construct software.
Microservices and Streams are top tendencies of software development where Software developer shows his bests cards and moves to solve computational paradigms, in case I tend to review some papers before start construction, the following papers were very helpful to me this last two moths:
Now, what can I say after having a microservices architecture (in my point of view) in production?, there are two things that I can enumerate, first is memory and CPU cost and the second is Big O(n log n), how many memory consume an application in the server is very important and should measure I must say that 1024 mb are well enough to handle a concurrency of 30 for millions of transactions per minute and design an architecture "to following the sun" keep of using Big O (n log n) that could some of the most important thing in architecture if your tendencies of received users or transactions increase exponentially to be grow up in a horizontal way with very few modifications to layers, component or services in architectures; questions like am I prepared to construct Cloud computing solutions? well, in my opinion taking care of what do you are going to process with an cloud infrastructure that is operated with best design patterns and rules which normally you have to adapt in your current systems and taking care of cost of pay for a piece of hardware that is costed by units, is more effective to first measure your current architecture by taking several reviews to reduce the amount of cost (memory/CPU) and take a catch of how databases and applications are operating, if the conditions of your current operations is not seems well with low scale, perhaps Cloud computing is the correct solution for you by now.
Spring Boot Microservices, Containers, and Kubernetes - How-to: Ray Tsang discusses how to create a Java-based microservice using Spring Boot, containerize it using Maven plugins, and subsequently deploy a fleet of microservices and dependent components such as Redis using Kubernetes.
My opinion is that we are currently living a new revolution of software development where everyone is showing his better work and releases to be adjusted by Distributed Computing and in the look of using Cloud Computing in a carefully measurable way.
En la segunda etapa se logró visualizar en el 2014, lamentablemente se escucho el problema con las integraciones tecnológicas y el diverso software que se construyo que era productivo pero no esta ínterconectado con el núcleo central (por el problema de la curva de aprendizaje con la tecnología propuesta, esto también pasa con tecnología de IBM/Oracle/Microsoft), la dirección fue cada dependencia debe construir de acuerdo a un esquema de datos propuesto por GOB.MX, esto era un poco problemático para sistemas financieros ya que estos emplean un gran cantidad de reglas de negocio por detrás y aplicar una reingeneria podría ser muy costoso, pues si bien se logró modelar un interface de los núcleos contables y financieros para cubrir dicho requerimiento, asombrosamente hay dependencias de gobierno como IMSS donde si cumplieron y cumplen con los lineamientos de Gobierno Federal, el modelo esquema de tramites lo encuentras en el diseño de sus base datos y sistemas (aunque hay que señalar que en IMSS hay muy poco presupuesto para tecnología y en su caso se ven muy recortados en comparación con otras dependencias que manejan valores monetarios, lo único que hace funcionar tecnológicamente dichas dependencias es su gente que asombrosamente hacen maravillas con lo poco que tienen), otra competencia que tiene en esta segunda etapa fueron los ingenieros “full stack” mayores de 35 años que tiene habilidades de diseño y construcción muy avanzandas, ellos pueden sacar un casos de uso complejos en menos de 1 semana y gracias a su amplia experiencia hacen la instalación hasta producción de su desarrollo, este tipo de mecanismo hizo que algunos proyectos que se sumaron a GOB.MX salieran a luz y por primera vez se viera la intención del proyecto.
La tercera etapa fue la especificación de software, esto considero una gran táctica para salvar el proyecto aunque puede ser rudimentaria y simplista para otros, se podrán notar que en algunas dependencias se empezó a encontrar areas UX (User experience) -felicidades por ello- , son cédulas que se componen de equipos de 3 diseñadores gráficos (como mínimo), líderes de negocio y gerentes de alguna linea de negocio quienes se componen en una etapa del proyecto para realizar el diseño de la interfaz gráfica de casos de uso, aquí fue donde GOB.MX dio en el clavo, si se revisa la especificación de software de interfaz se encuentra publicada en su sitio, es una librería con css, js, jquery y bootstrap básicamente en IMSS sacaron juego los ingenieros "full stack" ventajas para construir con servicios rest (mvc) y dinámicamente producir formularios web adaptables (se puede encontrar interfaces elegantes con la poca infraestructura tecnológica que poseen); el fenómeno que se logro observar es adaptabilidad, el organigrama de trabajo es imprescindible en una organización por lo que si involucras a los distintos equipos para simplificar el diseño y desarrollo se puede lograr un cambio; otro punto importante fue no solo agregar una hoja de estilos al sistema si no lograr integración y modularidad en el diseño de posteriores pantallas, también se hace revisión de protototipado de interfaz, desde el lenguaje empleado en pantalla hasta revisión con abogados de los datos que se exponen, eso fue una actividad importante a capturar y copiar.
Hay distintas historias en el proyecto, en mi curva de aprendizaje obtenida por participar en dichos sistemas con dependencias quienes resolvieron el problema adaptándose a factores internos y externos; consultores, líderes, gerentes y directores a quienes agradezco la oportunidad que me brindaron al ser parte de su proyecto y que indudablemente tratan de hacer un Mexico mejor a costa de su salud y bienestar personal y familiar.
Hace algunos años tuve la oportunidad de ser parte en el desarrollo de algunas integraciones con GOB.MX en el Servicio de Administración Tributaria de México y en Instituto Mexicano del Seguro Social, proyecto que si bien era muy ambicioso por la idea de centralizar todos los trámites de diversas dependencias de gobierno en un solo sistema único, por lo que todas las dependencias brindaran interfaces de servicio para dar el soporte de sus reglas negocio, si no tuviera conocimiento o no hubiera sido participe en proyectos de gobierno federal diría que no es una tarea compleja, bueno pues resulta que la lógica, reglas, secuencia, flujos de cada tramite suelen ser complejos unitariamente, si lo pensamos de cierta manera son esos libros de legislación de mas 800 páginas que se convierten en sistemas; en mi opinion personal GOB.MX se puede dividir en 3 etapas para el hecho de salvar sus iteraciones, bueno inicialmente la idea era la centralización de tramites, lo siguiente fue normalización de distribución de tramites en dependencias y por ultimo convertirse en una especificación de diseño de sistemas, ¿Que ocurrió con la idea innovadora y revolucionará de reducir el proceso?, bueno fueron muchos factores a mi punto de vista y a mi parecer mas buenos que malos, ademas de la curva de aprendizaje obtenida la cual fue interesante. En el año 2013 me encargaba de la construcción de aplicaciones a nivel back-end, mi primer contacto con el equipo GOB.MX de Guadalajara fue asombroso y de respeto mutuo ya que me toco entablar dialogo con un equipo joven, lleno de muchas expectaciones y energía, manejaban tiempos apretados en las primeras etapas de construcción pero si bien con gestión e ingeniera logramos exponer en tiempos las interfaces que era solicitadas, uno de los problemas en lo que yo llamo la primera etapa fue la tecnología propuesta, algunos sabemos en que tecnología se estaba construyendo el núcleo central de aplicación y el service bus que se empleaba, recuerdo haber aplaudido la tecnología propuesta (software libre -gemas y mula-) la razón es que era una curva de conocimiento innovadora en su tipo y en México era primeriza ya que es muy poco conocido que se apliquen dichas tecnologías integrar y manejar amplio volumen de información; otro problema en la primera etapa fue que no aplicaron una táctica en proyectos “primero conoce tu ambiente”, si bien hay diversas dependencias de gobierno con diversos niveles de presupuesto desde la secretaria de economía hasta la secretaria de salud, puedo decir que cada una posee diversas infraestructuras tecnológicas y niveles de transacción que pueden ser con un nivel de concurrencia de 1000 hasta 1 por sistema, digamos facturación electrónica y patronatos de salud son grandes sistemas en la federación, la función requerida era estudiar dichos sistemas para revisar sus procesos con el fin de obtener sus puntos fuertes y construir una estructura genérica de arquitectura tecnólogica, mesas de trabajo donde debió ser requerido entablar relaciones con los creadores de dichos sistemas para homogeneizar un común denominador entre sistemas de amplio volumen y después hacer sintomatología con sistemas de mediana y pequeña escala en donde se podría apreciar si el diseño prototipo podría funcionar, hay dependencias donde hay manejo de php, java, .net, cobol y python e inclusive hay dependencias en donde hasta aceptan completamente nuevas propuestas tecnológicas (principalmente se interesan en BPMN y Service bus) virtualmente es una tarea difícil y es requerido arquitectos con amplia experiencia, con aptitudes y cualidades para analizar el problema muy rápidamente con el fin de diseñar y construir soluciones en base a su amplia experiencia profesional, básicamente lo que tenían que aplicar que aplicar era la ciencia de datos, científicos de datos que compusieran una mecánica, arquitectura y especificación de software, pero realmente ¿existe este tipo de personas en gobierno federal?, la respuesta increíblemente es si y son asombrosos, normalmente los tienen escondidos y reservados para los grandes proyectos, en la Secretaria de Salud (IMSS) hay científicos de datos (consultores, maestros y doctores de alrededor de 45 años que revisan y construyen las “arquitecturas"), en Servicio de Administración Tributaria de México hay grupos de líderes de proyecto, gerentes, directores y consultores que están haciendo muy bien su trabajo (están dando de que hablar en otras dependencias y empresas privadas por su buen servicio), Secretaria de energía y economía existen otros proyectos ambiciosos donde se pudo haber obtenido el común denominador de sistemas distribuidos y con amplia recolección de información; puedo decir que en lo que llamo la primera etapa fue la vision del proyecto lo que falto analizar y desarrollar.
Hace algunos años tuve la oportunidad de ser parte en el desarrollo de algunas integraciones con GOB.MX en el Servicio de Administración Tributaria de México y en el Instituto Mexicano del Seguro Social, proyecto que si bien era muy ambicioso por la idea de centralizar todos los trámites de diversas dependencias de gobierno en un solo sistema único, por lo que todas las dependencias brindarían interfaces de servicio para dar el soporte de sus reglas negocio, si no tuviera conocimiento o no hubiera sido participe en proyectos de gobierno federal diría que no es una tarea compleja, bueno pues resulta que la lógica, reglas, secuencia, flujos de cada tramite suelen ser complejos unitariamente, si lo pensamos de cierta manera son esos libros de legislación de mas 800 páginas que se convierten en sistemas; en mi opinion personal GOB.MX se puede dividir en 3 etapas para el hecho de salvar sus iteraciones, bueno inicialmente la idea era la centralización de tramites, lo siguiente fue normalización de distribución de tramites en dependencias y por ultimo convertirse en una especificación de diseño de sistemas, ¿Que ocurrió con la idea innovadora y revolucionará de reducir el proceso?, bueno fueron muchos factores a mi punto de vista y a mi parecer mas buenos que malos, ademas de la curva de aprendizaje obtenida la cual fue interesante. En el año 2013 me encargaba de la construcción de aplicaciones a nivel back-end, mi primer contacto con el equipo GOB.MX de Guadalajara fue asombroso y de respeto mutuo ya que me toco entablar dialogo con un equipo joven, lleno de muchas expectaciones y energía, manejaban tiempos apretados en las primeras etapas de construcción pero si bien con gestión e ingeniera logramos exponer en tiempos las interfaces que era solicitadas, uno de los problemas en lo que yo llamo la primera etapa fue la tecnología propuesta, algunos sabemos en que tecnología se estaba construyendo el núcleo central de aplicación y el service bus que se empleaba, recuerdo haber aplaudido la tecnología propuesta (software libre -gemas y mula-) la razón es que era una curva de conocimiento innovadora en su tipo y en México era primeriza ya que es muy poco conocido que se apliquen dichas tecnologías integrar y manejar amplio volumen de información; otro problema en la primera etapa fue que no aplicaron una táctica en proyectos “primero conoce tu ambiente”, si bien hay diversas dependencias de gobierno con diversos niveles de presupuesto desde la secretaria de economía hasta la secretaria de salud, puedo decir que cada una posee diversas infraestructuras tecnológicas y niveles de transacción que pueden ser con un nivel de concurrencia de 1000 hasta 1 por sistema, digamos facturación electrónica y patronatos de salud son grandes sistemas en la federación, la función requerida era estudiar dichos sistemas para revisar sus procesos con el fin de obtener sus puntos fuertes y construir una estructura genérica de arquitectura tecnólogica, mesas de trabajo donde debió ser requerido entablar relaciones con los creadores de dichos sistemas para homogeneizar un común denominador entre sistemas de amplio volumen y después hacer sintomatología con sistemas de mediana y pequeña escala en donde se podría apreciar si el diseño prototipo podría funcionar, hay dependencias donde hay manejo de php, java, .net, cobol y python e inclusive hay dependencias en donde hasta aceptan completamente nuevas propuestas tecnológicas (principalmente se interesan en BPMN y Service bus) virtualmente es una tarea difícil y es requerido arquitectos con amplia experiencia, con aptitudes y cualidades para analizar el problema muy rápidamente con el fin de diseñar y construir soluciones en base a su amplia experiencia profesional, básicamente lo que tenían que aplicar era la ciencia de datos, científicos de datos que compusieran una mecánica, arquitectura y especificación de software, pero realmente ¿existe este tipo de personas en gobierno federal?, la respuesta increíblemente es si y son asombrosos, normalmente los tienen escondidos y reservados para los grandes proyectos, en la Secretaria de Salud (IMSS) hay científicos de datos (consultores, maestros y doctores de alrededor de 45 años que revisan y construyen las “arquitecturas"), en Servicio de Administración Tributaria de México hay grupos de líderes de proyecto, gerentes, directores y consultores que están haciendo muy bien su trabajo (están dando de que hablar en otras dependencias y empresas privadas por su buen servicio), Secretaria de energía y economía existen otros proyectos ambiciosos donde se pudo haber obtenido el común denominador de sistemas distribuidos y con amplia recolección de información; puedo decir que en lo que llamo la primera etapa fue la vision del proyecto lo que falto analizar y desarrollar.
Emplear frameworks y herramientas que calculen y aseguren la efectivad de software facilita el trabajo del ciclo de desarrollo y la entrega del mismo a producción. Hace unos años tuve la oportunidad de conocer a un lider técnico que empleaba las pruebas unitarias como metodo para liberar las actividades y tareas del día de un programador, el me dijo que no permitia que sus programadores salieran a las 6:00pm si no demostraban una ejecución de pruebas unitarias de los componentes o servicios que habian desarrollado en el día (ni por ende se permitia su versionamiento), al principio puede ser desmotivante para el programador y un poco desgastante ya que si se calcula su día en 8-9 horas puede tardar una cierta parte de su tiempo en crear clases que demuestren el funcionamiento sin dejar a cargo la calidad de código, probablemente para programadores experimentados las pruebas unitarias se han intrinsecas al desarrollo de cualquier funcion en el sistema, a mi parecer cada vez que se produce y se te asigna una actividad esta debe ser medible y por lo tanto cuantificada para ser parte de un proceso y por lo tanto poder decir que empleas una metodologia de trabajo y formas parte de un equipo, por ello si se le indica al programador que las pruebas unitarias es una forma de indicar un buen desempeño en su actividad esto puede dar por hecho a la larga que la mejora continua puede darse en cualquier sistema.
La covertura de codigo es un pieza en plataformas de gestión de calidad, para asegurar que haces bien las cosas deben ser revisadas o comparadas contra un estándar, hay herramientas como Sonarqube o el propio VIsual Studio pueden ejecutar este reportes, bien para realizar "cobertura" empleando SonarQube es requerido la siguiente configuración: 1. Agregar las siguientes propiedades al archivo pom: 2. Agregar el plugin de JaCoCo para enviar el reporte a sonar dentro del pom: 3. Ejecutar con maven las siguientes lineas: $ mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install sonar:sonar 4. El resultado muesta una metrica de cobertura que puede ser estudia y revisada:
Si bien sonar puede ser un dolor de cabeza para algunas programadores, despues de uso comienzas a ver su utilidad y efectividad por el valor de que mejora tus habilidades en desarrollo, si bien su ejecución a mi parecer debe ser diaria o periodicamente semanal (esto se puede hacer facilmente con una tarea programada dentro de Jenkins). Best regards,
Emplear frameworks y herramientas que calculen y aseguren la efectivad de software facilita el trabajo del ciclo de desarrollo y la entrega del mismo a producción. Hace unos años tuve la oportunidad de conocer a un lider técnico que empleaba las pruebas unitarias como metodo para liberar las actividades y tareas del día de un programador, el me dijo que no permitia que sus programadores salieran a las 6:00pm si no demostraban una ejecución de pruebas unitarias de los componentes o servicios que habian desarrollado en el día (ni por ende se permitia su versionamiento), al principio puede ser desmotivante para el programador y un poco desgastante ya que si se calcula su día en 8-9 horas puede tardar una cierta parte de su tiempo en crear clases que demuestren el funcionamiento sin dejar a cargo la calidad de código, probablemente para programadores experimentados las pruebas unitarias se han intrinsecas al desarrollo de cualquier funcion en el sistema, a mi parecer cada vez que se produce y se te asigna una actividad esta debe ser medible y por lo tanto cuantificada para ser parte de un proceso y por lo tanto poder decir que empleas una metodologia de trabajo y formas parte de un equipo, por ello si se le indica al programador que las pruebas unitarias es una forma de indicar un buen desempeño en su actividad esto puede dar por hecho a la larga que la mejora continua puede darse en cualquier sistema.
La covertura de codigo es un pieza en plataformas de gestión de calidad, para asegurar que haces bien las cosas deben ser revisadas o comparadas contra un estándar, hay herramientas como Sonarqube o el propio VIsual Studio pueden ejecutar este reportes, bien para realizar "cobertura" empleando SonarQube es requerido la siguiente configuración: 1. Agregar las siguientes propiedades al archivo pom: 2. Agregar el plugin de JaCoCo para enviar el reporte a sonar dentro del pom: 3. Ejecutar con maven las siguientes lineas: $ mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install sonar:sonar 4. El resultado muesta una metrica de cobertura que puede ser estudia y revisada:
Si bien sonar puede ser un dolor de cabeza para algunas programadores, despues de uso comienzas a ver su utilidad y efectividad por el valor de que mejora tus habilidades en desarrollo, si bien su ejecución a mi parecer debe ser diaria o periodicamente semanal (esto se puede hacer facilmente con una tarea programada dentro de Jenkins). Best regards,
Emplear frameworks y herramientas que calculen y aseguren la efectivad de software facilita el trabajo del ciclo de desarrollo y la entrega del mismo a producción. Hace unos años tuve la oportunidad de conocer a un lider técnico que empleaba las pruebas unitarias como metodo para liberar las actividades y tareas del día de un programador, el me dijo que no permitia que sus programadores salieran a las 6:00pm si no demostraban una ejecución de pruebas unitarias de los componentes o servicios que habian desarrollado en el día (ni por ende se permitia su versionamiento), al principio puede ser desmotivante para el programador y un poco desgastante ya que si se calcula su día en 8-9 horas puede tardar una cierta parte de su tiempo en crear clases que demuestren el funcionamiento sin dejar a cargo la calidad de código, probablemente para programadores experimentados las pruebas unitarias se han intrinsecas al desarrollo de cualquier funcion en el sistema, a mi parecer cada vez que se produce y se te asigna una actividad esta debe ser medible y por lo tanto cuantificada para ser parte de un proceso y por lo tanto poder decir que empleas una metodologia de trabajo y formas parte de un equipo, por ello si se le indica al programador que las pruebas unitarias es una forma de indicar un buen desempeño en su actividad esto puede dar por hecho a la larga que la mejora continua puede darse en cualquier sistema.
La covertura de codigo es un pieza en plataformas de gestión de calidad, para asegurar que haces bien las cosas deben ser revisadas o comparadas contra un estándar, hay herramientas como Sonarqube o el propio VIsual Studio pueden ejecutar este reportes, bien para realizar "cobertura" empleando SonarQube es requerido la siguiente configuración: 1. Agregar las siguientes propiedades al archivo pom: 2. Agregar el plugin de JaCoCo para enviar el reporte a sonar dentro del pom: 3. Ejecutar con maven las siguientes lineas: $ mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install sonar:sonar 4. El resultado muesta una metrica de cobertura que puede ser estudia y revisada:
Si bien sonar puede ser un dolor de cabeza para algunas programadores, despues de uso comienzas a ver su utilidad y efectividad por el valor de que mejora tus habilidades en desarrollo, si bien su ejecución a mi parecer debe ser diaria o periodicamente semanal (esto se puede hacer facilmente con una tarea programada dentro de Jenkins). Best regards,
Emplear frameworks y herramientas que calculen y aseguren la efectivad de software facilita el trabajo del ciclo de desarrollo y la entrega del mismo a producción. Hace unos años tuve la oportunidad de conocer a un lider técnico que empleaba las pruebas unitarias como metodo para liberar las actividades y tareas del día de un programador, el me dijo que no permitia que sus programadores salieran a las 6:00pm si no demostraban una ejecución de pruebas unitarias de los componentes o servicios que habian desarrollado en el día (ni por ende se permitia su versionamiento), al principio puede ser desmotivante para el programador y un poco desgastante ya que si se calcula su día en 8-9 horas puede tardar una cierta parte de su tiempo en crear clases que demuestren el funcionamiento sin dejar a cargo la calidad de código, probablemente para programadores experimentados las pruebas unitarias se han intrinsecas al desarrollo de cualquier funcion en el sistema, a mi parecer cada vez que se produce y se te asigna una actividad esta debe ser medible y por lo tanto cuantificada para ser parte de un proceso y por lo tanto poder decir que empleas una metodologia de trabajo y formas parte de un equipo, por ello si se le indica al programador que las pruebas unitarias es una forma de indicar un buen desempeño en su actividad esto puede dar por hecho a la larga que la mejora continua puede darse en cualquier sistema.
La covertura de codigo es un pieza en plataformas de gestión de calidad, para asegurar que haces bien las cosas deben ser revisadas o comparadas contra un estándar, hay herramientas como Sonarqube o el propio VIsual Studio pueden ejecutar este reportes, bien para realizar "cobertura" empleando SonarQube es requerido la siguiente configuración: 1. Agregar las siguientes propiedades al archivo pom: 2. Agregar el plugin de JaCoCo para enviar el reporte a sonar dentro del pom: 3. Ejecutar con maven las siguientes lineas: $ mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent install sonar:sonar 4. El resultado muesta una metrica de cobertura que puede ser estudia y revisada:
Si bien sonar puede ser un dolor de cabeza para algunas programadores, despues de uso comienzas a ver su utilidad y efectividad por el valor de que mejora tus habilidades en desarrollo, si bien su ejecución a mi parecer debe ser diaria o periodicamente semanal (esto se puede hacer facilmente con una tarea programada dentro de Jenkins). Best regards,
Working around with Alfresco document management systems, it comes with an architecture to handle and dealing with files likely, in terms on building your interfaces that request/response the petition of document to be indexing, profiling, storing and managing following CMIS specification, the best way of doing an implementation of an interface if your using Web Service is handle the archive as attachments or MTOM in the best way previously passing the file thought discovering, encoding, binarization and packing for sending a file to well decoupled layer of services that handle asynchronously the reception of document and retrieving a correct response to a client who is waiting with a timeout in queue/streaming manner the processing of his document.
Alfresco uses open source in backstage (Apache Chemistry) which intermediately use a language to communicate repository with internal database is like JPQL or LINQ, is just simple like using hibernate HQL and you must develop an integration to dealing the document structure and normalization of their characterization with your systems, so to dealing with connection you could query Alfresco with: Chemestry OpenCMIS Workbench to start the tool you must execute: $ workbench.sh and you will get like this in Java Application:
Commons problems in development are that tables with column ObjectId respond lower in amount of time of 20 seconds after 2 million of records saved in the documents, this sound like a tunning database problem, solving will require some investing hours, after taking care of network problems handling with High Availability in your infrastructure and asynchronously retrieve a response of events and states with steps of document process. Best Regards,
I remembered that few years I told a manager to review Liferay Portal before doing an home development, my experience with portals give to suggest that it was going to fix to his solution, after working with Liferay may I say you have to be care and have well-configured, federated, not superpass and overloading the actual functions of the Portal Layer, for example federation is interesting topic where portal layer should be a pass-out and measure how the Authentication, authorization, and accounting (AAA) is doing and where an application should intervene (recovered cookies, tokens or sessions), Liferay as well as an application should live together with other applications in a container installed on a Application Server, you should probably think twice how all applications federated could be live together in a cluster with a server(s) running with Liferay. Liferay Portal has cool things that you probably you must not codify, configure or manage, for example considerations of being responsive to the client rendering content to the most common devices in the other hand a TUNNING is a priority in development state, the first thing is install the database in DMBS outside of memory fabric configuration (review index, table, partitions, users, columns), clustering is not of free version so you probably develop Security Agents to handle objects of authorization and accounting, review log files to view how you should perform jvm parameters (parallel is recommend) and spread functionality across the server To configurate a portlet you should the following next steps: 1. Required artifact in your pom file: 2. Configuration in web.xml (tld should be download from liferay distribution)
3. Create portlet file:
There is another consideration to be careful that is well programmed applications using portlets for example, timeout in any request/response in the front-end and in the back-end take care of the cost and duration of transactions for not converting your Application Server in a rock (it happens and is terrible). So after choosing your portal there is a benefit of using a technology and decisions of taking a path and this is the knowledge and ideas you probably you have experienced, if you are doing a home development is well suited decision to start for your infrastructure or having license for Portals like IBM where front-end should be carried in using and extends provider libraries, or built something from open-source resources which are paths that be well done when there is team up, management with vision and well suited timetables.
There is a list of previous steps for doing SSO between a Web app and OpenAm and the most important things are:
Start OpenAM and well configurated server.
Create users and specificate the rol names.
Install agentapp inside webserver
Execute agentadmin to create a policy between webapp and openam.
All those steps require some time, in the application context we need to do some configuration in context for conclude AAA, Authentication is taking for OpenAM, Authorization is given by Spring Security and OpenAM interconnection and Accounting is doing for WebApp when it asign the corresponding roles and access to the client (by now we are going to do some federation), so here the short list of configuration for doing with Spring security:
1. First required artifact in the app:
2. Start spring context with spring security:
3. The most import part filters and connection to retry OpenAM config:
4. Create the shared cookie: 5. The amconfig properties to taking url, user and password For the application is kind of simple for just federate permissions between components.
I have a Teacher/Sensei who teach me a lot the theory and principles of database engine really works his name is ++++++ a consultant and expert on Oracle, we worked together some months ago, my experience at that time was with Oracle Database 11g and Oracle Enterprise Manager, using some past knowledge I have to encourage a relative problem with Informix called "Dirty Reads" he explained to me that is a bad practice of consulting, updating or inserting data.
Informix is more sensible and treats data carefully based on ISAM which are algorithms in database in response a petition of users, so database principles are the same in other database engine, but on the other hand, at Oracle the engine resolves this problem internally and produce a problem or cost when it represents a problem causing interruptions in database, one of those is the best post I have introduced:
When your process is concurrent and you have multiple users in the background pieces of data have to move on in the engine, if you do not measure and take the cost of queries that you are sending to database eventually you degrade the performance of your application, a problem could be at the next one:
ISAM error: the file is locked (http://www.oninit.com/errorcode/index.php?pageid=-113)
For solving this kind of problems are two paths, one is correct the application (the better one) or give more time of waiting for the database (mitigating), so please check your query if you are doing an update of a bunch of elements you should go through the primary key o indexed fields, or in it is the case in a select check your where statement and modified to go to indexing field:
update table set column = :column1 where idprimarykey in (:idprimarykey); select column1, column2, column3 from table where idprimarykey in (:idprimarykey);
The other method is gained more time in transaction is not an effective way but informix provided: ... > echo "set isolation to dirty read; select count(*) from customer;" | dbaccess stores_demo ... > echo "set lock mode to wait; select count(*) from customer;" | dbaccess stores_demo ... http://www-01.ibm.com/support/docview.wss?uid=swg21508233
Dirty data are not welcomed to the database and you must carry the access to objects where are you doing transactions and service who are using it. Another important configuration when are using Informix is take care of Transaction Isolation and propagations after reading the documentation, Informix does not support readonly=true, and propagation must be in Serializable for betters ways, something like this if you are using spring framework: @Transactional(value =
"XXXXTransaccionManager", readOnly = false, propagation =
Propagation.REQUIRED, timeout = 6000,isolation =
Isolation.READ_COMMITTED)
And take care of using a version superior of 3 in the driver because it have some problems in the writing.
