¿Cuáles son las ventajas y desventajas de la arquitectura basada en plug-ins?

Question

Quiero hacer el diseño arquitectónico de un software que se puede usar para integrar varios software de terceros (ejecutables) en una sola plataforma.

Los tipos de proyectos estándar se agregarán a la plataforma de forma predeterminada. El tipo de proyecto define la forma en que se ejecutarán los diferentes programas y sus archivos de entrada y salida.

El usuario puede personalizar el tipo de proyecto estándar disponible y que se agregará a la plataforma como un nuevo tipo de proyecto que define un nuevo flujo de ejecución personalizado.

También debe admitir la extensión fácil y la personalización de las funciones. Leí que la arquitectura basada en plug-ins admite ambos.

¿Cuáles son las ventajas y desventajas de la arquitectura basada en plug-ins? ¿Tenemos una arquitectura mejor que pueda usarse para este tipo de escenario?

Gracias de antemano :)

Answer 1

Los beneficios de un sistema de acoplamiento activo son

• extensibilidad: la aplicación se puede ampliar de forma dinámica para incluir nuevas características.
• desarrollo paralelo: dado que las características se pueden implementar como componentes separados, pueden desarrollarse en paralelo por diferentes equipos.
• dirección de desarrollo clara: dado que el marco de plugin ofrece una interfaz y documentación bien definidas para los escritores de plugins, los desarrolladores tienen una hoja de ruta clara para el desarrollo.
• simplicidad: un plugin normalmente tiene una función, por lo que los desarrolladores tienen un solo foco

Pero algunos de estos puntos fuertes son también puntos débiles:

• extensibilidad: ¿la interfaz de complementos anticipar las formas de plugins escritores qué extender la aplicación, o restringe la extensión. El diseño de la extensibilidad para satisfacer todos los casos de uso a menudo requiere varias iteraciones o un análisis de requisitos extremadamente bueno.
• mantenimiento: el proveedor del marco de plugins no solo debe asegurarse de que la interfaz del plugin satisfaga los casos de uso indentados, es clara y está bien documentada, sino que también puede evolucionar. La administración de versiones y la compatibilidad con versiones anteriores de plugins existentes pueden ser muy difíciles.Lo suficientemente difícil como para que muchas implementaciones prácticas no se molesten, y empujan la responsabilidad de los escritores de plugins para actualizar sus complementos con cada versión.
• complejidad: aunque cada complemento funciona cuando se prueba solo, las interacciones entre complementos pueden causar nuevos problemas, con errores que aparecen solo con ciertas combinaciones de complementos.
• prueba: los plugins de prueba pueden ser difíciles si el plugin no proporciona algún tipo de plugin de plugin para pruebas, lo que a veces no es posible, y las pruebas solo están disponibles ejecutando el plugin real, lo que ralentiza el desarrollo.
• separación artificial: un complemento generalmente tiene un único foco, pero lo que constituye un solo foco lo establece el proveedor de API de complemento. Si un escritor de complementos descubre que necesita un complemento que pueda hacer razonablemente dos cosas (como lo define la API del complemento) en tándem cercano, puede terminar teniendo que implementar dos complementos y encontrar formas de proporcionar comunicación entre ellos que no está provisto actualmente por la api. Él entonces tiene que trabajar alrededor o contra el marco de plugin.

Diseñar un buen entorno de complementos tiene muchos de los mismos desafíos que el diseño de una buena biblioteca. Si está produciendo tanto el entorno como los complementos, no es tan malo, ya que puede actualizar todos los complementos a medida que evoluciona el entorno, pero si la API del complemento está abierta para todos, entonces se requiere una planificación y ejecución cuidadosas para obtener el diseño. derecho a evitar demasiadas reescrituras de plugins a medida que evoluciona el entorno.

"Second-system syndrome" descrito por Fred Brooks defiende que el segundo sistema desarrollado es a menudo excesivamente genérico, buscando la máxima flexibilidad, a veces produciendo una "plataforma dentro de una plataforma"/"inner platform effect". Un diseño conectable a menudo se ve como una salida cuando los requisitos son inexistentes o no están especificados. Para compensar, el software se hace lo más flexible posible para tratar de manejar "lo que viene".

Apologías si esto pinta una imagen lúgubre: los sistemas enchufables pueden ser fantásticos y ofrecen muchos puntos fuertes, pero tienen un alto precio. Antes de sumergirse en un sistema conectable, es prudente establecer requisitos para todos los complementos que necesitará para cubrir la funcionalidad requerida. Esto le ayudará a decidir si el diseño conectable vale la pena el esfuerzo, o un enfoque más simple serviría igualmente bien.

Answer 2

Puede encontrar las ventajas y un pequeño marco plug-in que pueden aprovechar al link text

Answer 3

Las ventajas de una arquitectura plug-in es, obviamente, el aumento de la flexibilidad. Esto permite a otros desarrolladores extender su aplicación de una manera que no esperaba en primer lugar. Tenga en cuenta que hay varias arquitecturas de plug-ins que van desde flexible hasta extrema flexible. El más flexible se llama arquitectura Full Plug-in, que se usa en eclipse.

La desventaja es que para ser realmente flexible debe desarrollar un marco sólido que incorpore carga, descarga y comunicación entre complementos. También habrá una ligera sobrecarga de rendimiento en la comunicación entre los complementos.

Para un debate sobre cómo crear una arquitectura de plug-in, consulte la pregunta this.

Answer 4

Aunque no es fácil de mantener la arquitectura basada en complementos, ¿por qué las personas se desarrollan de esa manera? Porque aún es mejor que otros enfoques "fijos". Diga si sus requisitos cambian uno después de otro y el diseño necesita ser reparado, entonces piense qué va a hacer con otros enfoques.

Lo mejor de todo es el desarrollo paralelo. Cuando el cliente quiere algunas características CUANTO ANTES, los desarrolladores pueden trabajar en paralelo y enchufar su código como Complementos/Componentes. Básicamente, la arquitectura Plug-n-Play brinda flexibilidad y complejidad, pero la complejidad es por primera vez. Una vez que su equipo se sienta cómodo con él, es fácil para ellos manejar código, errores, etc. ...

Cuando quiera integrar diferentes aplicaciones de terceros, como ha mencionado, será mejor desarrollarlo como complemento O componente/Servicio basado. (No quiero confundirlo pero SOA podría ser de interés.) Para que pueda activar/desactivar el servicio/complemento cuando no sea necesario. Incluso puede obtener beneficio de esto cuando desee hacer SAAS (modelo de software como servicio), donde obtiene ingresos por cada servicio/función diferente :).

Como referencia, puede consultar los siguientes marcos JAVA. Hay muchos ESB disponibles que proporcionan una arquitectura plug-n-play basada en componentes/servicios.

• jBPM (JBOSS Business Process Manager)
• Apache ServiceMix (An Enterprise Service Bus)

espero que esto ayude.

gracias.