Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

EAI example

5.835 visualizaciones

Publicado el

EAI example for software architecture an

Publicado en: Educación, Tecnología
  • Sé el primero en comentar

EAI example

  1. 1. Engineering Support System Group 12
  2. 2. Project Vision“The vision of this project is to provide abetter customer service through anintegrated enterprise application systemand enhance the efficiency of engineeringsupport teams.”
  3. 3. Project Goals• integrate a set of existing and proposed systems in such a way that their collective functionality is directed towards achieving the above mentioned vision.
  4. 4. System’s Main RequirementsFunctional Requirements• Recording the email conversations with the clients.• Engineers and clients should be able to access SLAs.• Clients should be able to inform an issue and request patches.• System should be able to create client accounts automatically.
  5. 5. Non Functional Requirements• Security• Availability• Unified view of data• Accuracy• Availability
  6. 6. Proposed Architecture Engineer Client Multiple Access Channels (eg. Web, Mobile, Email, etc.) Unified portal CS App ES App WSO2 ESB WSO2 WSO2 SugarCR Jira governance identity M registry server
  7. 7. Technical decisionsEngineer Client Multiple Access Channels (eg. Web, Mobile, Email, etc.) Unified portal Device sensitive web portal CS App ES App WSO2 ESB WSO2 WSO2 SugarC Jira governance identity WSO2 identity server RM registry server will be used as the LDAP instance
  8. 8. Lead to Contract activity flow
  9. 9. Report Issue to Resolution
  10. 10. Advantages of proposed architecture• New portals can be easily integrated to the existing system• Central authentication server can be added for security• No single point of failure• Unified view of data through portal• Less redundant data (Each system maintains data which are specific to that system)• Low latency and no blocking operations• High extendibility• Technology independent subsystems (Each subsystem can be implemented using different technologies)• Loosely coupled subsystems• Authentication and authorization support at every level
  11. 11. Advantages of proposed architecture• Complexity of Jira is hidden from customer throu CS portal.• Engineers get a unified view of data form ES portal.• Data is not replicated in ES or CS.(They are in the base systems : Jira, Sugar, Registry)
  12. 12. Quality Attributes• Security o Authorization/authentication based on a central LDAP o Role based access control• Performance o Zero latency o Streamline processes o Minimum response time• Availability o 24/7 availability• Maintainability
  13. 13. Assumptions Made• support accounts are not activated until a contract with the client is signed.• There is a common mechanism relate data of a user account distributed in different servers.(E.g. user ID is similar for an user in every server)• Different subsystems used in this overall system support a web service interface. If not an adapter has to be developed.
  14. 14. Assumptions - Continued• All the authentication must happen through a centralized LDAP server• No monetary payments has to be considered as they have not mentioned.• New system to manage patches is not needed. It can be done through JIRA.• Users can directly interact with the existing subsystems as previously even in the new system
  15. 15. Ambiguities• User roles are not well defined (e.g. if a user is logged as an engineer he will have the access to data of all the engineers)• Disaster recovery and backups are not specified.• Security requirements other than role based security is not specified
  16. 16. Other Considered Architectures•Client-Server Architecture Presentation Layer Sugar Web browser Control Layer Jira Document Repository Engineering Support support portal portal backend backend
  17. 17. Other considered Approaches DrawbacksFile Transfer Pattern • A common file type has to be agreed between different subsystems Portal Portal • Each subsystem must be 1 2 modified as it can convert own data in to agreed file format and to extract data from receiving Controller files. • Adding new functionality in to each subsystem is difficult andSubsyst Subsys Subsys time consuming em 1 tem 2 tem 3 • Transferring data using files is less efficient. • Controller has do complex tasks to manage file transfers
  18. 18. • Remote Procedure Invocation Pattern Middleware (Object Request Broker) Subsystem 1 Drawbacks • Applications has to be aware of Portal A other applications • Integrating new applications or Subsystem 2 altering existing applications is difficult. Portal • Systems like sugar CRM does B not support RPC Subsystem 3