Interface Definition Language

The basis of the original IDL (data_desc) was a simple flat file of message definitions.
Its primary weakness was that the developer had to ensure very exact syntax.
Its secondary weakness was that each message structure existed in its own right without regard to a dictionary.
Its tertiary weakness was that both 'Client' and 'Server' ended up with an IDL that could read and write all messages.
Without a dictionary it is possible to have a Field such as Status that has different storage types between different messages.
One change made was to introduce the ClientWrite-ServerRead ServerWrite-ClientRead pairs by way of the instruct syntax.
Where E means Encode or Write and D means Decode or Read.

The latest version addresses these problems and further created the IDL as object classes rather than global C structures.
It follows that the new IDL suite written in both Java and C++ can (according to command line arguments) :

  • Read the new IDL
  • Write C++ class objects
  • Write Java class objects
  • Write the old data_desc file

    • A Basic IDL File: ETS.SCH


    		    
    #schema ETS
; The SemiColon Is The Remark Character
$type , long  , LONG  
$type , int   , INT	  
$type , short , SHORT 
$type , char  , CHAR  
$type , bool  , UCHAR ; Java: $type,byte,UCHAR
#dictionary
MNO,Message Number,2,SHORT
LEN,Message Length,2,SHORT
ID_DestinationTSI, Destination TSI System Id, 1, CHAR  
ID_IPAddress,      Network Address,           4, LONG  
ID_User,Message    User Number,		  2, SHORT 
MemberNo,          Member Number,	 	  2, SHORT 
OrderNo,           Order Number,		  4, LONG  
VolumeOrder,       Order Volume,		  4, INT	  
LimitPrice,        Limit Price,		  4, INT	  
ReferenceAccount,  Account Reference,	 14, CHAR  
PrivateFlag,       Private/Public,		  1, UCHAR 
ContractNo,        Contract Number,		  2, SHORT 
SeriesNo,          Series Number,		  4, INT	  
BS,                Buy/Sell,		  1, CHAR  
#dictionaryEnd

$declare HEADER : ID_User,ID_DestinationTSI,ID_IPAddress ; Common To All Messages 

#message CmeWepAddOrder = 3  ; Server Reply To WepCmeAddOrderRequest
$instruct SERVER,ED,CLIENT,D ; CS May need to re-create message for CME
HEADER,			   ; Short hand saves entering User,Destination,Address in message
MemberNo,		   ; The Trading Member Of The Order
OrderNo,  
VolumeOrder,
LimitPrice,
ReferenceAccount, 
PrivateFlag, 
#SUB			 ; Columns That Are Repeated In The Message
ContractNo,SeriesNo,BS,			 
#messageEnd		; CmeWepAddOrder
; ------ The Next Message Is The Extent That A Sub Inclusive Message Can Be Compacted ------
#message CmeWepModifyOrder=4 
$instruct SERVER,ED,CLIENT,D 
HEADER,OrderNo,VolumeOrder,LimitPrice,ReferenceAccount,PrivateFlag
#SUB
ContractNo,SeriesNo,BS
#messageEnd

#schemaEnd ; ETS

    The Command Syntax #schema must be followed by a name of the schema
    Since the definition is IDL syntax it can start with numbers or underscores but cannot include whitespace in the Name
    #schema must be the first instruction in the IDL file
    #schemaEnd must be the last instruction in the IDL file but any unused information can follow this in the file

    The Command Syntax $type requires a , either side of the native type.
    Note forward declarations or forward notify is not supported.
    This means the $type alias must be declared before it is used in the #dictionary

    The Command Syntax #dictionary and #dictionaryEnd determines the Field Names, size and data type.
    It follows that unless a Field has been defined in the Dictionary it cannot be used in a Message.

    The Field Names MNO and LEN are reserved, but this is more to do with certain legacy tools.
    It is simply better to avoid using these cryptic names.
    Field Names cannot include white space and should not start _12 or 12_ (See Java)

    The Command Syntax $declare requires a Collection Name (e.g. HEADER)
    Followed by a colon : and a comma , delimited list.
    Since Collections are IDL syntax they can start with numbers or underscores but cannot include whitespace in the Name
    Multiple Collections are supported but they cannot be nested.
    Remember you are IDL scripting the Enterprise rather than creating a program language source file.

    The Command Syntax #message requires a Message Name
    Message Names cannot include white space and should not start _12 or 12_ (See Java)
    Message Names are then followed by an assignment = to a number.
    #messageEnd is required syntax to finish the message definition.
    #SUB which does not have a SUBEnd is an instruction that the columns are to repeat in the message
    Once the #SUB instruction is used all Fields until #messageEnd are part of the #SUB.

    The Command Syntax $instruct is the least flexible.
    SERVER must be first and CLIENT must be second
    The Scope required by both deliveries must be as follows: ED E or D
    Reversing the Scope DE is not suppported.

    The rules of the Schema Syntax are as follows:

  • ; Is the remark character. All Characters Until The Next New Line Are Ignored.
  • Command Syntax is Case Insensitive
  • The Command Syntax Must Be Supplied On A Single Line:
    #schema
    $type
    #dictionary
    Field,Title,Length,Type
    #dictionaryEnd
    $declare COLLECTION : Field0,Field1
    #message
    $instruct SERVER,ED,CLIENT,D
    #SUB
    #messageEnd
    #schemaEnd
  • Named Fields Can Appear On The Same , Delimited Line inside the message definition.

    • IDL Schema Error Checking

    There are many potential mistakes: missing hash signs ; missing commas; missing dollar symbols; missing colons.
    Fields used that are not declared ; Fields duplicated in messages
    Collections being used that have not been declared or based on Fields not defined.
    Command Syntax pairs not being followed and so forth.
    The scope of this page is not really to cover the range and scope of errors that the parser can capture however.

    IDL Output

    Using the Message Schema above the following IDL files created.
    In the case of the Java output listed here it covers the ServerWrite-ClientRead in the Decoder.
    The Java code here can be a 'Server Service' that is it Reads Replies from the C++ Server only.
    For the Java code to be a 'Server for Servers' it would need to Read Requests such as WepCmeAddOrderRequest and also Write them on to the appropriate Server
    The C++ code presented here has the full Decoder Support and Read Write capabilities in the object class

    CmeWepAddOrder.h
    CmeWepModifyOrder.h
    Decoder.h
    Decoder.cpp
    CmeWepAddOrder.java
    CmeWepModifyOrder.java
    Decoder.java

    Click on the links above to open the source code in another browser window.

    IDL Framework

    ReplyMessage reply = Decoder.readReply( is ); /* Wait For Message From IDL Package */ MessageReply* reply = Decoder::readReply( m_fd ); /* Wait For Message From IDL Package */

    The above function calls are taken from ServerConnection.java and Connect.cpp respectively.
    The polymorphic message can then be applied to ModelEntities via a Distributor after checking for ServerPush during ClientPull MessageLoader phase
    (see The Model )
    The IDL framework contains a number of other objects, for example a port of the MFC Collection classes exists in "TheTemple.h" to support the Server C++ code in either Windows 2000 or say IBM AIX Unix.

    Further Ideas For Extending The Scripting IDL

    Previous experience in Systems Architecture Design has shown that creating the database and message protocol independant of each other leads to a much more complex end to end product.
    Imagine then that the IDL scripting creates not only the code for messages but also the script for creating the database.
    For example the Field OrderNo in AddOrder message should map to a column OrderNo in the Order table.
    By seeing both schema's together helps to minimise inconsistancies between the two. 

    #schema FURTHER_IDEAS
$dbtype , datetime , LONG  
#dictionary
Number,   Identiciation Number,	4,  INT	  
Today,    Some kind of Date   , 4,  LONG  
Surname,  Person ,	            30, CHAR  
Forename, Reference ,	        30, CHAR  
Title,    Job Title ,	        30, CHAR  
#dictionaryEnd

#table Payments
Number,Today
$index 01xCluster, unique : Number
#tableEnd

#table Employee
Surname,Forename,Title
$index 01xCluster, unique : Surname,Forename
$key   02xNonCluster : Title
#tableEnd
#schemaEnd

    Note we could define a new $type instruction to support Database Types
    As well as three new Command Syntax rules: #table #tableEnd ; (Clustered) $index ; (NonClustered) $key
    It may be that the field definition would need extra column(s) to support items such as not null but even so the potential is enormous where ever generic code is part of the final product.

    From the schema above it should not be too difficult to create the output below 

    create table dbo.Payments (
	Number int not null,
	Today  datetime not null
)
go
create unique clustered index 01xCluster on dbo.Payments( Number )
go

create table dbo. Employee (
Surname  varchar(30) not null,
Forename varchar(30) not null,
Title	 varchar(30) not null
)
go
create unique clustered index 01xCluster on dbo.Employee( Surname, Forename )
go
create unique nonclustered index 02xNonCluster on dbo.Employee( Title )
go

    The final stage would potentially be to create an Integrated Development Environment Application
    that created the raw script file from GUI based input.
    If you think about it that is actually handled within Database environments.


    Services  JSW  JSW Model  JSW Client  RUP  Cut Red Tape  Java Merlin Patch