Difference between revisions of "AppSuite:Architecture Overview"

 
(47 intermediate revisions by 6 users not shown)
Line 1: Line 1:
[[File:appsuite_architecture_diagram_2.png|1200px]]
+
__NOTOC__
 +
This page gives an overview of the most important internal components, plugin capabilities, public interfaces (APIs) and data communication streams of the Open-Xchange server.
 +
 
 +
[[File:appsuite_architecture_diagram_3.png|1200px]]
 +
 
 +
 
 +
=<span style="background:#dcdcdc">Frontend and client based communication flow                                </span>=
 +
*'''1''' All communication from and to the users client is purely based on HTTP. It is strongly recommended to use only encrypted HTTPS. For security reasons, some modules require HTTPS connections in the default configuration. The HTTP(S) communication is terminated at Apache.
 +
 
 +
*'''2''' Within Apache, the mod_proxy_http module is used to forward the request to the OX server. Apache can also be used to configure session stickiness and load balancing in clustered environments.
 +
 
 +
*'''3''' OX Web UI
 +
** The [https://documentation.open-xchange.com/latest/middleware/http_api.html HTTP API] is the core API for all user functionality. Every function of the Web UI is using this API. In addition to that, all possible user functionality is available via this API and can be used from external applications as well. It is based on JSON via HTTP(S).
 +
** [http://oxpedia.org/wiki/index.php?title=Portal:AppSuite_UI Web UI Documentation]
 +
** [[HTTP_API_Examples|Programming Example]], how to use this API to build an Email widget, accessing the HTTP API
 +
 
 +
*'''4''' The OXtender for Business Mobility is a server based Active Sync Implementation. The "Microsoft Exchange Active Sync" protocol supports Push via HTTPS, therefore the email backend needs to send push events to the OX server. Details, see: [[OXtender for Business Mobility Installation Guide]]  and [[OX_EMail_Push_Introduction|Email Push Introduction]]. Serverside, the synchronization makes use of the "Universal Sync Module (USM)", which is a server bundle containing the synchronization logic for several clients. It also communicates via HTTP(S) transporting JSON objects.
 +
 
 +
*'''5''' The [[OXtender 2 for Microsoft Outlook]] is a MAPI plugin, installed in the Outlook client to synchronize data between Outlook and the OX server. It makes use of the same HTTP(S) and JSON based communication to the Universal Sync Module (USM), like Active Sync.
 +
 
 +
*'''6''' [[Caldav carddav Bundles|CalDAV and CardDAV]] interfaces are available to synchronize calendars and address books with Apple OS X and iOS applications as well as Thunderbird: [[CalDAVClients|CalDAV Clients]] and [[CardDAVClients|CardDAV Clients]].
 +
 
 +
*'''7''' A WebDAV implementation provides the possibility to access the documents in the Files-module directly via any WebDAV client, like the Windows Explorer.
 +
 
 +
=<span style="background:#dcdcdc">Administration, provisioning and operations related components and communication flow</span>=
 +
*'''11''' Data Migration and Im-/Export of user data can be done via automated tools, using these interfaces:
 +
** [[Using the import servlet]], [[Building an importer]]
 +
** [[Using the export servlet]], [[Building an exporter]], [[Export_ical/vcard| iCal/vCard]]
 +
** A tool is available to upload data from Outlook profiles or PST files to OX: [http://oxpedia.org/wiki/index.php?title=OX_Outlook_Uploader Outlook Uploader]
 +
 
 +
*'''12''' All provisioning tasks, like creating and editing users can be done with [[AppSuite:AdminGuide_7.8.4#OX_App_Suite_Management_.28CLT.29|Commandline tools]]. The command line tools make use of the Java RMI API internally.
 +
 
 +
*'''13''' The native, central provisioning API is available via Java RMI and split into the [http://software.open-xchange.com/OX6/doc/RMI/admin-core/ Core API]  and the  [http://software.open-xchange.com/OX6/doc/RMI/admin-hosting/ HostingAPI].
 +
 
 +
*'''14''' Central control panels and billing systems, which are not implemented in Java, can use the [[Open-Xchange-SOAP|SOAP API]].
 +
** For OX as a Service, there's a specific [[OX_as_a_Service_Provisioning_using_SOAP|SOAP API documentation]]
 +
 
 +
*'''15''' Authentication is implementable via highly customizable plugins, different standard and custom implementations are available
 +
**[[Authentication IMAP Plugin description| IMAP]]
 +
** LDAP
 +
** Database
 +
** custom
 +
 
 +
*'''16''' Monitoring the OX application is done via JMX, for a description see [[OX monitoring interface]], or a commandline tool
 +
** An example how to use the monitoring interface is available as pre-built Scripts for the monitoring tool Munin: [[OX munin scripts]]
 +
 
 +
=<span style="background:#E5E5E5">Backend related components and communication flow</span>=
 +
*'''21''' All OX-internal data - users, contacts, calendars, tasks and document metadata is stored in a MySQL Database, accessed via JDBC
 +
**'''22''' Native MySQL contacts storage
 +
 
 +
*'''23''' Other sources for contacts than the MySQL storage can also be used. For this an OSGi bundle needs to be implemented, overriding the standard contact storage.
 +
** An implementation using LDAP is publicly available
 +
** Several custom implementations are available on request or can be implemented by partners
 +
 
 +
*'''24''' Email storage is accessed through the pluggable [http://software.open-xchange.com/OX6/doc/mal/ Mail Abstraction Layer API]
 +
** The default implementation uses IMAP
 +
** Sending Emails is done via SMTP
 +
** For Active Sync or Outlook the email backend needs to send push requests to the OX server, for details see [[OX_EMail_Push_Introduction|Email Push Introduction]]
 +
** Several custom implementations are available on request or can be implemented by partners
 +
 
 +
*'''25''' Documents in the Files module are accessed via an API, which allows customized implementations.
 +
** The default in large environments is to use NFS
 +
** In small environments the local filesystem is used
 +
** [http://www.scality.com/ Scality] is also available
 +
** Several custom implementations are available on request or can be implemented by partners
 +
 
 +
=<span style="background:#E5E5E5">Social/Public Data related components, plugins and communication flow</span>=
 +
 
 +
A <em>subscription based plugin system</em> allows to access data from external systems like webmail systems or social networks. The underlying concept is called SocialOX and a list of some plugins can be found here: [[SupportedCrawler]]. The integrations of messaging, contacts and calendars are done via the official API of the respective 3rd-party-service if there is one. For authentication, OAuth is used for security and privacy control if available. All plugins use HTTP(S) connections to the external services only. Access to the external email systems is done via IMAP(S) or POP3(S), depending on the service.
 +
 
 +
*'''31''' For subscription to an external calendar a plugin to subscribe to Google Calendar is available.
 +
 
 +
*'''32''' Supported external messaging services are Twitter and SMS/MMS.
 +
 
 +
*'''33''' Contacts can be imported from Xing, LinkedIn (removed since 7.10.0), MSN/Windows Live/Outlook.com, Yahoo and Google.
 +
 
 +
*'''34''' External email accounts can be integrated via POP3(S) or IMAP(S)
 +
** There are pre-configured settings for many popular services so that users only need to enter their e-mail address and password.
 +
** Look here how to [[install and configure the mail-account plugin]].
 +
 
 +
* '''35''' RSS feeds are loaded remotely, filtered for exploits and can be read in the UI
 +
 
 +
* '''36''' Image services like Flickr and Tumblr are integrated directly into the UI, bypassing the backend completely. Authentication is handled via OAuth.
 +
 
 +
=<span style="background:#dcdcdc">Publicly Available Plugins</span>=
 +
* An overview of the existing public plugins can be found here: [[Open-Xchange Plugin Overview]]. Many others are available on request or through partners.

Latest revision as of 05:53, 20 June 2018

This page gives an overview of the most important internal components, plugin capabilities, public interfaces (APIs) and data communication streams of the Open-Xchange server.

Appsuite architecture diagram 3.png


Frontend and client based communication flow

  • 1 All communication from and to the users client is purely based on HTTP. It is strongly recommended to use only encrypted HTTPS. For security reasons, some modules require HTTPS connections in the default configuration. The HTTP(S) communication is terminated at Apache.
  • 2 Within Apache, the mod_proxy_http module is used to forward the request to the OX server. Apache can also be used to configure session stickiness and load balancing in clustered environments.
  • 3 OX Web UI
    • The HTTP API is the core API for all user functionality. Every function of the Web UI is using this API. In addition to that, all possible user functionality is available via this API and can be used from external applications as well. It is based on JSON via HTTP(S).
    • Web UI Documentation
    • Programming Example, how to use this API to build an Email widget, accessing the HTTP API
  • 4 The OXtender for Business Mobility is a server based Active Sync Implementation. The "Microsoft Exchange Active Sync" protocol supports Push via HTTPS, therefore the email backend needs to send push events to the OX server. Details, see: OXtender for Business Mobility Installation Guide and Email Push Introduction. Serverside, the synchronization makes use of the "Universal Sync Module (USM)", which is a server bundle containing the synchronization logic for several clients. It also communicates via HTTP(S) transporting JSON objects.
  • 5 The OXtender 2 for Microsoft Outlook is a MAPI plugin, installed in the Outlook client to synchronize data between Outlook and the OX server. It makes use of the same HTTP(S) and JSON based communication to the Universal Sync Module (USM), like Active Sync.
  • 7 A WebDAV implementation provides the possibility to access the documents in the Files-module directly via any WebDAV client, like the Windows Explorer.

Administration, provisioning and operations related components and communication flow

  • 12 All provisioning tasks, like creating and editing users can be done with Commandline tools. The command line tools make use of the Java RMI API internally.
  • 13 The native, central provisioning API is available via Java RMI and split into the Core API and the HostingAPI.
  • 14 Central control panels and billing systems, which are not implemented in Java, can use the SOAP API.
  • 15 Authentication is implementable via highly customizable plugins, different standard and custom implementations are available
    • IMAP
    • LDAP
    • Database
    • custom
  • 16 Monitoring the OX application is done via JMX, for a description see OX monitoring interface, or a commandline tool
    • An example how to use the monitoring interface is available as pre-built Scripts for the monitoring tool Munin: OX munin scripts

Backend related components and communication flow

  • 21 All OX-internal data - users, contacts, calendars, tasks and document metadata is stored in a MySQL Database, accessed via JDBC
    • 22 Native MySQL contacts storage
  • 23 Other sources for contacts than the MySQL storage can also be used. For this an OSGi bundle needs to be implemented, overriding the standard contact storage.
    • An implementation using LDAP is publicly available
    • Several custom implementations are available on request or can be implemented by partners
  • 24 Email storage is accessed through the pluggable Mail Abstraction Layer API
    • The default implementation uses IMAP
    • Sending Emails is done via SMTP
    • For Active Sync or Outlook the email backend needs to send push requests to the OX server, for details see Email Push Introduction
    • Several custom implementations are available on request or can be implemented by partners
  • 25 Documents in the Files module are accessed via an API, which allows customized implementations.
    • The default in large environments is to use NFS
    • In small environments the local filesystem is used
    • Scality is also available
    • Several custom implementations are available on request or can be implemented by partners

Social/Public Data related components, plugins and communication flow

A subscription based plugin system allows to access data from external systems like webmail systems or social networks. The underlying concept is called SocialOX and a list of some plugins can be found here: SupportedCrawler. The integrations of messaging, contacts and calendars are done via the official API of the respective 3rd-party-service if there is one. For authentication, OAuth is used for security and privacy control if available. All plugins use HTTP(S) connections to the external services only. Access to the external email systems is done via IMAP(S) or POP3(S), depending on the service.

  • 31 For subscription to an external calendar a plugin to subscribe to Google Calendar is available.
  • 32 Supported external messaging services are Twitter and SMS/MMS.
  • 33 Contacts can be imported from Xing, LinkedIn (removed since 7.10.0), MSN/Windows Live/Outlook.com, Yahoo and Google.
  • 34 External email accounts can be integrated via POP3(S) or IMAP(S)
  • 35 RSS feeds are loaded remotely, filtered for exploits and can be read in the UI
  • 36 Image services like Flickr and Tumblr are integrated directly into the UI, bypassing the backend completely. Authentication is handled via OAuth.

Publicly Available Plugins

  • An overview of the existing public plugins can be found here: Open-Xchange Plugin Overview. Many others are available on request or through partners.