FIXTradingCommunity / fix-orchestra-quickfix

FIX Orchestra / QuickFIX integration
Apache License 2.0
3 stars 5 forks source link

A few clarification questions based on the examples #6

Closed philipwhiuk closed 1 year ago

philipwhiuk commented 1 year ago

Given this slight adaptation of: https://github.com/FIXTradingCommunity/fix-orchestra/blob/master/interfaces/src/test/resources/examples/SampleInterfaces.xml

    <fixi:interface name="Private">
        <!-- one or more service offerings, with local orchestration file or internet address -->
        <fixi:service name="orderEntry" orchestration="https://mydomain.com/orchestra/orderEntry.xml"/>
        <!-- the protcol stack -->
        <fixi:userInterface name="ATDL" orchestration="https://mydomain.com/orchestra/algo.xml"/>
        <fixi:encoding name="TagValue"/>
        <fixi:sessionProtocol name="FIX4" reliability="recoverable" orchestration="https://mydomain.com/orchestra/session.xml" version="FIX.4.2" >
            <fixi:annotation>
                <fixi:documentation langId="en-us">FIX session protocol</fixi:documentation>
            </fixi:annotation>
        </fixi:sessionProtocol>
        <fixi:transport name="TCP"/>
        <fixi:sessions>
            <fixi:session name="XYZ-ABC">
                <!-- inherits services and protocols from interface -->
                <fixi:role>initiator</fixi:role>
                <!-- alternate addresses are supported -->
                <fixi:transport address="10.96.1.2:567" use="primary"/>
                <fixi:transport address="10.96.2.2:567" use="secondary"/>
                <!-- there can be any number of identifiers -->
                <fixi:identifier name="SenderCompID">XYZ</fixi:identifier>
                <fixi:identifier name="TargetCompID">ABC</fixi:identifier>
                <!-- tells when session becomes effective so it can be configured in advance -->
                <fixi:activationTime>2019-08-07T09:30:00Z</fixi:activationTime>
            </fixi:session>
        </fixi:sessions>
    </fixi:interface>
  1. Role doesn't seem to be a mandatory XML element - I added it in. If left out maybe we should assume it's for an initiator?
  2. There's no coverage on HeartBtInt either which means that initiators need extra config.
  3. Also there's no coverage for StartTime & EndTime type config
  4. For FIXT sessions there's no DefaultApplVerID picked up

Question 1 falls in a wider question I have which is:

Orchestra is machine-readable but is the same file expected to be used by both sides of a connection. Or can/should I trivially be able to generate the counter-party side and that's something I'll need to do when provided with one?

Question 2, 3 & 4 falls into a second wider question I have which is:

How best do we define the specifics of the connectivity between the peers within Orchestra. Is this the point of the orchestration file? Is there any example on an orchestration file / scheme I should look at for orderEntry.xml / session.xml (I'm assuming algo.xml is FIXAtdl)? Or should we propose schema additions?

donmendelson commented 1 year ago

@philipwhiuk

  1. Role is not mandatory because it is not a feature of all protocols.

To your broader question: an Orchestra file is issued by a service provider to tell peers how they must behave to use the service. Therefore, it will not necessarily give all details about both sides of a conversation. (Of course, it is free to use Orchestra schemas for its own internal usage, but it need not publish that publicly.)

2-4. The Orchestra committee is considering changes for Orchestra v1.1, and the plan is to form a working group specifically to address the Interfaces schema. I suggest that you join the group and suggest improvements to the schema and ways to extend it.

philipwhiuk commented 1 year ago

Thanks @donmendelson!