2012-04-11 20 views
6

Por motivos de investigación personal y universitaria, estoy pensando en construir un CRM simple utilizando una arquitectura orientada a servicios. Su significado es solo explicar la arquitectura en sí misma, no el uso comercial.Sugerencias de Arquitectura Orientada a Servicios

Estaba pensando en implementar un CRM que ofrezca un servicio de análisis simple y atención al cliente (almacenamiento de usuarios, comentarios personales y algunas otras cosas).

La arquitectura que soy define el diseño: - WebGUI (un cliente de los otros servicios) - AnalyticsService (un servicio que recibe los datos, análisis y recogerla) - CustomerCareService (un servicio que utiliza las API REST a aplicar operaciones CRUD).

Cada servicio tiene su propia base de datos, siendo completamente independiente de los demás. Exponen una interfaz pública. La interfaz, por supuesto, debe proporcionar algún tipo de autenticación para denegar solicitudes no autorizadas.

Las ventajas que me gustaría explicar en este tipo de arquitectura es la posibilidad de tener todas las cosas independientes y la capacidad de combinarlas para ofrecer nuevos servicios (por ejemplo, si hubiera un OrderService para manejar pedidos sería fácil para combinarlo con el Cliente utilizando las API públicas). La gran ventaja para mí es que sería bastante fácil crear otros clientes que usen estos servicios.

No sé lo que es un buen método de autenticación, que podría ser fácil de implementar, tampoco estoy seguro acerca de cómo hacer estas API (use XML o API REST simple con datos GET/POST). He trabajado con Amazon, PayPal y otras API de la compañía, parecen usar los servicios REST (PayPal usa un parámetro feo _cmd GET mientras que Amazon usa un mejor URI) para saber qué hacer, pero al leer algo sobre SOA, parece que las personas también usan XML. Por supuesto, también necesito tener en cuenta que la interfaz web debe poder reconocer al usuario que ha iniciado sesión, obtener los permisos (token o lo que sea) y usarlo con servicios para mostrar información. Así que no estoy seguro de que SOA sea el tipo de arquitectura que realmente estoy desarrollando ... ¿es SaaS en lugar de SOA? Creo que sería mejor usar aplicaciones RESTful, con JSON o algo así para implementarlo (no soy un gran fanático de XML, me parece demasiado prolijo).

Para mayor claridad estoy anuncio esté en mis preguntas:

  1. Es este tipo de arquitectura llamada SOA o SaaS (o ambos)?
  2. ¿Cuál es una buena implementación para lo que quiero obtener? (Por favor explique como más detallado posible)
  3. ¿Qué tipo de autenticación es más adecuado para un cliente (token de usuario vs OAuth o similar)
  4. ¿Tiene alguna sugerencia para este tipo de proyectos?

Tengo unos 3 meses para hacerlo, así que no puedo hacer algo realmente complejo (además del hecho de que no sería realista para un solo programador).

Conozco Python (frameworks WSGI), Ruby on Rails, C/C++ y otros idiomas (.net excluido) y me gustaría desarrollarlo bajo un entorno Linux (MySQL o Postgres, o incluso un NoSQL si tengo alguna sugerencia para la elección correcta), también podría combinar varios idiomas siendo estos servicios programas independientes.

Lo que me gustaría aquí es tener un buen punto de vista y una buena sugerencia.

Gracias!

Respuesta

1

Definiría SaaS como un modelo de negocio en lugar de una arquitectura; sin embargo, al igual que todos los requisitos del dominio empresarial, influirá en la arquitectura de los sistemas, pero no en sí misma. Lo que ha definido es esencial una arquitectura orientada a servicios.

Su declaración "independiente y la capacidad de combinarlos para ofrecer nuevos servicios" es el requisito esencial de diseño no funcional que sugiere SOA.

Una buena implementación para SOA se trata de tener interfaces bien definidas y flexibles, con muy clara delineación de responsabilidades. Sin embargo, es difícil ser prescriptivo. La prueba está en comer; proporciona esa reutilización flexible. Mi sugerencia es pasar tiempo leyendo los recursos del patrón de diseño de SOA y comprender las características definitorias con respecto al contexto de uso apropiado. Luego aplique el nivel de abstracción apropiado del principio de Responsabilidad Individual. c.f. (Domain) Space Based Architecture es una especie de meta-patrón de SOA.

En lo que se refiere a la autorización, recomiendo siguiendo el enfoque de servicio, uso una distribución de sistema de servicios de directorio como LDAP abierta, y observo que es totalmente razonable para el servicio proporciona y los usuarios a tener sus propias credenciales y se puede usar teclas Público-Privadas para firmar mensajes

La sugerencia principal es estudiar y aprender de la experiencia de otros:

+0

Gracias, respuesta impresionante! Lo hiciste bien, los recursos son muy útiles, también compré algunos libros, ¡es un negocio muy interesante! –

0

SOA no obliga a utilizar XML.

Actualmente las tecnologías web dominan y definen el futuro. Entonces, en nuestra empresa, seleccionamos los servicios JSON RESTful como base. Y SOA como principios.

no hay sentido de sugerir idiomas, porque el propósito de SOA y la buena aplicación es - para permitir a cualquier idioma o marco para ser utilizado

(FYI usamos Java con servicios web basados ​​en MVC primavera, Node.js, PHP)

Cuestiones relacionadas