As a dev team lead in a large Enterprise, I want to provide a launch pad / toolbar for my users that incorporates a number of non FDC3 in-house services such as :
- searching for an instrument which can then be viewed in the applications.
- Providing the primary UI access point for in house notifications
This means that my dev team can not take an existing Launcher from a platform provider.
The Launcher will to be able to launch applications defined from multiple source, so it will need to connect to multiple FDC3 App Directories. Example applications include :
- In house container hosted applications. The Enterprise will typically have a single container such as OpenFin, Glue42 or an in-house container.
- 3rd party container hosted applications.
NB In our experience this is not currently a real use case but the goal of FDC3 is to enable this use case - In house applications written in .Net which are installed onto the user' desktops using inhouse installers.
- TR applications from Eikon running on the user's desktop.
At startup the launcher prompts the user to logon, and defaults to the logged in windows user id. The user is validated by some Enterprise specific SSO system. This user identity is used by some of the Application Directories to control which applications the user can 'see'.
For inhouse applications that use the same SSO as the Launcher, the SSO identity/cookie is passed to the apps as they are launched to avoid forcing the user to repeatedly sign on.
The key issues here are:
- the launcher will be written by an in-house team so not be a platform provider so the cross platform and discovery issues need to be addressed even if discovery is just by config files or by hand crafted factory methods created by the launch developers.
- There are a mix of :
- In house and 3rd party applications
- Desktop Technologies.
- The use case explicitly excludes deployment of .Net applications since in our experience in the Enterprise deployment to desktop is tightly controlled and the deployment technologies used vary from application to application.
- The use case is not saying that SSO is part of the FDC3 interfaces but that mechanisms should be defined to allow SSO information to be passed to App Directories and App Launchers who are free to use it if they have that capability.
Although this is a technical use case it represents real requirements that face FDC3 users.