Page Comparison

Attendees

• Frank Tarsillo (IHS Markit)
• Leslie Spiro (Glue42)
• Jorge Santos 
• Jonathan Teper (JPM)
• Nimit Shah (OpenFin)
• Riko Ekstein (JP Morgan)

Discussion items

...

•  Clarifications required on attributes based on discussions with group around latest proposal.  - Frank to bring this into future meetings
•  Identify documentation subsystem to support specifications - Frank
•  Ask FINOS if they have anyone who would act as a Scribe - Frank
•  Ask FINOS if we can enable WebEx recording - Frank

App Directory PoC Server Walk Though led by Frank Tarsillo.

Frank describes the scope of the project (see GitHub ReadMe) .

Leslie:  The code can be built and run anywhere but will there be a FINOS hosted place. It would be very useful if we also had a set of representative applications.

Frank : We can deploy the server to FINOS Open Shift cluster. Soon there may be three publicly available App Directory servers available for people who want to play with the API's. The PoC, the OpenFin demo and Tick42.

Riko: We should include the URLs as they become available. Confluence already has URL for the OpenFin server. .

Leslie: What is OpenShift?

Frank: It is as a Platform as a container, container orchestration. It is basically Enterprise Kubernetes. Red Hat are providing a Cloud version of this to RedHat and the FINOS build platform can distribute a version to OpenFin.

Leslie: If we want publish a demo version of the Glue42 App Directory  can we use the FINOS OpenShift service, even though the Glue42 App Directory is proprietary ?.

Frank: I think we can do this because it offers an open standards interface.r

Frank starts walking through the PoC project.

• Starts with Swagger definition, showing in Swagger Editor app.
• Walk through the Application schema

Leslie: It is important to note that only fields marked with Red Asterix are required.

Frank: The specification is based on the one that Leslie contributed for the last meeting but it has been edited to support the service impementation in the PoC Server. 

Riko : This is great, but what works well is having a repo to hold the specification and then raise issues and make proposal via Pull Requests on the GitHub.

Frank: Agree, <There was a discussion about where to host the Swagger spec compared to the Auto generated code and implementation code. Options were discussed and agreed at the end of the meeting>

       showed the three REST API end points in the first version of PoC; Get single app, put app and search (but no parameters yet). Methods are not complete, Scarmbel to get a running version for this meeting, more work required. le this 

       Demo'd Swagger Gen to create Java 'stubs' and then the code required to run a server. .

       GitHub also contains a simple Node JS server of the App Directroy.

       Currently the Stubs are built whenever the project is generated, but as agreed at end of the meeting, this will be changed when project is split.

       We can publish this to FINOS Nexus (if required).

Leslie: Check everyone comfortable walking through simple Java project. No one raised an objection.

Frank:

      showed POM file etc - emphasised the stubs are auto generated.

      So specification drives the code, this is a big advantage of using Swagger and auto-gen

Riko: We should not ship built objects like the auto generated stubs in GitHub. < This led to another discussion about GitHub structure, see end of meeting>

Leslie: Anbother benefit of using Swagger and auto-gen is that it ensures consistency across languages e.g. JavaScript, C# and Java.

Frank : Auto gen also creates a REST server.

     Also showed auto generated Node.JS server version. Can just do an NPM start after the build.

Leslie: And GitHub project only contains the definitions and not the auto generated stuff.

Frank : Normally keep spec separate from implementation, for convenience the impl is in the same repo, but at the end of the meeting it was agreed the specification and implementation will be split, using the Symphony Java API as a model.

     Talked us through the implemented service. .

     Showing implementation of Java version of the App Directory Service, shows use of (and override of) auto generated stubs.

     About to add S3, currently in memory only. Concurrent Hash Maps

Leslie: How would Frank like people to work on this. For example from Glue42 point of view we would like test servers to have a preloaded set of methods, so add support to the PoC server to read some 'predefine' application definitions from a set of JSon file, which can not be modified by calling the Put methods. Will Frank add this, or if a Glue42 developer workd on this, how would Frank like him to structure his work. 

Frank: Discuss this soon. Frank went on to show how the Java project creates a Docker Image.

     Shows build of Java version then move to Docker and build docker image and then run the image in Docker

     Demo'd accessing the server from Postman

Leslie; So will we eventually have a version of the PoC running in FINOS OpenShift with some predefined applications and people can use these to explore/test/evaluate the FDC3 client apps ?

Frank : Yes and we would have other app directories from companies like OpenFin and Glue42.

    Can we get a list of applications from people for apps that can be referenced and run.

Jorge: Can you provide access to the GitHub, Frank made it public in the call.

Frank: will move appd-api to a different public project, he uses S3 a lot as an object store.

Questions: None.

Frank: Should we keep the spec with the auto-generated stubs?

Riko: Really important to emphasise in the README that the spec if NOT ratified.

Nimit: This is a good idea to keep spec with auto-generated API appd-service

Meeting ran over time and was bought to a quick close.