Table of Contents

Date

14 Jun 2017

Attendees

Actions items from previous meetings

• Lynn Neir (Deactivated) and All: Review Tick42's proposal for a container API specification, including Leslie's email to the list and Kiril's pull request (especially the TypeScript specification), and comment on the mailing list.
• Former user (Deleted) and Leslie Spiro: follow up with Lynn Neir (Deactivated) to discuss Symphony LLC's strategy regarding Symphony Electron desktop interop/on-behalf-of functionality.
• Peter Monks: find and circulate notes from the meeting where JC presented Minuet's desktop interoperability functionality at a previous working group meeting.
• Lynn Neir (Deactivated): test Container.JS with Symphony Electron if possible
• Former user (Deleted): prepare a presentation on Synapse for the next WG meeting
• Lynn Neir (Deactivated): add file download API method (and any other planned methods) to list in Confluence
• Former user (Deleted): revise proposed charter to clarify that group's priority is portability of Symphony to various containers, with portability of other apps being a secondary goal.

Agenda

Meeting notes

Leslie Spiro: Last week, main topic was the API proposal, and whether to have a translation layer so that Symphony can keep doing what they want and map to the new UI. But we haven’t had those conversations yet. Lynn, there was a question about whether you were going to look at Container.JS with Symphony Electron.

Lynn Neir: Yeah, I haven’t done anything with that. We still have some internal conversations to have about how this would work with some of the legacy javascript that we need to work with. As it is, this would limit our functionality. Our previous wrapper, for example, uses window.open() in several places. And we were planning on using the same API in Electron because we have some users that depend upon that. And we have some future plans regarding opening windows that wouldn’t work with the Container.JS model.

Colin Eberhardt: I see. So you’re not writing a completely new codebase, you’ve got a preexisting codebase you need to work with.

Lynn Neir: Yeah, the Electron code is new, but it has to work with legacy code in our web app. And I need to figure out whether this new API limits us too much.

Leslie Spiro: Lynn, before the next meeting, let’s try to book a session to talk about whether Container.JS makes sense for the Symphony UI and what the issues might be. Now I’d like to hand it over to Slava to go through his deck.

Slava Kryukov: Thanks Leslie. For those of you not on WebEx, I’m sharing the same deck I already sent. I’ll give a brief overview. The primary scope is about interop between financial applications. It’s not aiming to replace other interoperability solutions, it’s specifically about interop between trade apps and symphony, pre- and post-trade apps, and so on. We’re not open-sourcing Autobahn, but we extracted the underlying framework and we call it Plexus. It’s part of our internal production solution and is well-tested. It’s gone through a full refactoring to ensure it doesn’t carry on any connections to DB. We’ve pushed it to a separate repo and are consuming it back in to our internal product.

Leslie Spiro: What do you think the timeframe is for the open-sourcing.

Slava Kryukov: I can’t tell you the date, and it depends on circumstances. We need a commitment from the LLC that it will get into the Symphony chat. We also have to finalize our internal open source contribution policy with legal. It’s getting close but it’s not there yet, probably 2-3 months.

Leslie Spiro: If you open source, will it be into your own repo or into the Foundation?

Slava Kryukov: To the Foundation. If it is going into the Symphony platform, our view is that it should be available to the members.

Leslie Spiro: And if the LLC doesn’t engage appropriately, this won’t happen correct?

Slava Kryukov: Yes, there may be alternatives, but that’s a fair statement.

The architecture is similar to some interop solutions. What makes it different is two things: 1) It’s container-agnostic. As long as the interop broker is running on the desktop, any container can launch and interact with it. 2) The solution is metadata-driven, which allows for implicit versioning and contract verification and fine-grained control over the usage and evolution of APIs, and the app registry allows you to instruct the launcher how to launch each particular app and pass context to it.

When we open source, we’ll be providing Interop Broker and App Lifecycle Manager, and reference implementations of the App Registry and Interop Registry. And for the launch capability, we’ll share a reference implementation for a generic launcher that can be customized for a specific app. And we’ll open source an open API specification for interactions between apps and the Interop Broker, and the App Lifecycle Manager and apps.

Colin Eberhardt: What does Synapse mean?

Slava Kryukov: That’s our internal name for Plexus interop. I should update that.

Lynn Neir: It says cross-platform. What does that mean?

Slava Kryukov: The implementation is .Net core. We’ve tested on Windows and Mac, but we haven’t tested it on Linux.

Lynn Neir: So you need .Net core installed on Mac?

Slava Kryukov: Yes.

Colin Eberhardt: The majority of the boxes here are on the desktop. But the App Registry and Interop Registry are on the Symphony pod and those connections are HTTP, correct?

Slava Kryukov: Correct.

Ok, I’ll skim through the rest. As I mentioned, the Plexus Interop is based around a metadata approach that provides a lot of benefits including testability—integration can be difficult in the interop world, so this gives you a lot of control over that. Interop types are point-to-point, streaming, broadcast, and discovery. You can do a discovery query to find out all of the options for handling a particular type of object.

The pipeline is: 1) you define metadata in the registry, then 2) provides codegen for .Net and typescript for the API for the connection to the broker, then 3) deployment, and 4) runtime.

Here’s an example of an FX trading system, then the client can trade currency pairs. One business use case we want to solve with open sourcing is where some clients want to incorporate into this trade flow a credit check to approve or reject the trade inside the firm. The problem for us is that clients don’t want to tie their checks to a single dealer platform. They want an API that’s supported by multiple banks and providers. So by open sourcing this, we can define a contract across several firms, and bring these clients on board.

The next steps are to decide whether to create a new working group for interapp interop, or to do it within this group. We may want to do a new group if it’s different people within banks dealing with interop.

Jonathan Christensen: Probably the same people, but a very different topic.

Leslie Spiro: This is an area we’re very interested in. A couple of questions. Are you planning on contributing Plexus definitions of objects like bonds, etc.?

Slava Kryukov: That wasn’t part of the plan. I’m not sure whether that’s a better topic for the FOS WG.

Leslie Spiro: So back to your diagram, you said there’s a question of cooperation from Symphony. What is it you need from them?

Slava Kryukov: Two things: first, someone needs to fire up the interop broker executable or make it part of their process. This is trivial. The key dependency is a trusted identity provider. This is a big topic, but what’s key for this to succeed is being able to have a trusted network and the ability to share the authenticated principal between apps coming from different firms through the trusted intermediary of Symphony. And Symphony is one of the few options for this.

Leslie Spiro: I have lots of questions about that, but first is anyone else interested in that, or is there anything anyone else wants to cover first?

Colin Eberhardt: How much of this is stuff you need to rewrite to open source them, and how much is just that you’re waiting on LLC and ready to push the button.

Slava Kryukov: We’ve already refactored the work and put it in a separate repo so we can open source fairly quickly once they’re ready. The only potential work left is on our open source contribution process internally, and how we continue to support it as a production system.

Colin Eberhardt: So the two production-ready implementations, what’s the language or technology?

Slava Kryukov: .Net core.

JS: You say you have something ready and working. Are you sending financial objects in some form already today? And would you be able to share some of those standards you’re using with the group?

Slava Kryukov: That wasn’t part of my scope, so I’ll have to talk to my colleagues and come back to you on that.

Leslie Spiro: Is it fair to say that interop is useful, you have a mature implementation, you’re ready to open source it if Symphony will intergrate with/bundle it?

Slava Kryukov: Yes.

Leslie Spiro: So, what is the identity requirement?

Slava Kryukov: For example, when you do a flow from one app to the other, if you don’t have a single trusted identity, you get login screens every time, and if you do a discovery request, e.g. from pre-trade, to get prices from multiple providers, each one will require authentication. So it’s not useable without single trusted identity.

Leslie Spiro: So the interop broker will securely get the logged-on Symphony user and pass that to the other apps?

Slava Kryukov: Yes. But we’ll need a way to transform the Symphony user to, for example, a DB identity.

Leslie Spiro: So it provides a kind of single sign-on, because everybody knows the Symphony ID and that it’s a trusted source of identity.

Slava Kryukov: Yes. There are complications in a multiple-to-one relationship and other edge cases. Like where the client has two accounts within a siloed organization, but has a single Symphony account. But that’s a more advanced problem we can solve when we encounter it.

Leslie Spiro: Anyone have other questions they want to raise? We certainly have an interest in making Container.JS interact with interop solutions like this one. But as you say, it could also go into another group.

Dov Katz: Well, this goes a level above the javascript abstraction of containers in the stack. But it’s kind of like we’re building a hierarchical architecture for multiapp aggregated runtime. Putting them into the same group might distract from what is essentially a separate conversation.

Lynn Neir: Who starts this broker process, destroys it, etc.? Does there need to be an API from the container that does all that?

Slava Kryukov: The broker lifecycle would be controlled by Symphony in this diagram. Could be other apps as well. The API is very simple between launching app and the broker, it’s a simple bootstrapping. The API becomes more sophisticated between the App Lifecycle Manager and the app launchers.

Leslie Spiro: Autobahn as a product is about clients connecting to brokers. Do your clients use the same technology to connect back into your DMZ?

Slava Kryukov: Plexus is confined to the desktop.

Aaron Williamson: What’s the state of your conversation with Symphony?

Slava Kryukov: We’ve seen no active resistance, and we’ve got an advocate within the LLC, but that’s about all I can say.

Jonathan Christensen: Yes, I’d say that we’re very interested in this. It would be helpful for us to get a sense of how many of our customers are interested in this functionality.

Lawrence Miller: We’re really encouraged by this and think the most value will be within the community, so we’re eager to see the conversation between members around this.

Action items

• All: If your organization is interested in seeing Symphony support DB's Plexus interbank interop framework, tell Jonathan Christensen.
• Lynn Neir (Deactivated), Leslie Spiro, and Former user (Deleted): schedule time before the members meeting to discuss compatibility issues between Container.JS and the Symphony web app.
•