Re: Work progresses on ISO COBOL definition of native support for XML
From: Robert Wagner (robert.deletethis_at_wagner.net)
Date: 07/11/04
- Previous message: Robert Wagner: "Re: In answer to RW - again (was: Sorts (revised)"
- In reply to: William M. Klein: "Work progresses on ISO COBOL definition of native support for XML"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 11 Jul 2004 12:24:21 GMT
"William M. Klein" <wmklein@nospam.netcom.com> wrote:
>I thought you might be interested in the latest draft of the specification for
>"native language" support for "Standard" COBOL.
>
>Please see the document at:
>
> http://www.cobolportal.com/j4/files/04-0092.doc
>
>There is another document showing both those issues that have been
(tentatively)
>resolved and those issues that are still open. This document can be viewed at:
>
> http://www.cobolportal.com/j4/files/04-0093.doc
The document describes using an XML file (document) to communicate between a
client program talking to a user and a server program containing 'business
rules'. The XML file replaces a parameter structure passed by other means, such
as memory pointer, pipeline, message or database row.
The problem with this solution, IMO, is that it fails to link a sender with a
message and its response. In the real world there will be many clients running
in parallel. Suppose clients 1, 2 and 3 post simultaneous inputs and calls to
the server. Three instances of the server program are launched, each grabbing
one of the requests and responding with an answer. How does the server program
know which request is 'next up'? How does the system insure that answer 2 goes
to client 2 rather than client 1?
The document talks about a key, similar to an indexed file, and about an
occurence number, similar to an array. It doesn't deal with the issue of who
assigns these identifiers, how collisions are avoided, nor how this is managed
on the server side. It doesn't address disposal of old packets. And it doesn't
have any security. What prevents a 'sniffer' program from reading all the
replies? If the answer is encryption, how does the server decrypt packets from
an unknown source?
I recommend these changes:
..SELECT filename ASSIGN TO AUTOMATIC, rather than 'myfile'. Drop the notion of
application-managed ids.
..CALL 'target' USING filename. A program can have more than one XML file.
..Some form of CONNECT to insure the server is available.
>Although definitely still in a DRAFT stage, if you have any significant (or
>even not so significant) comments that you want considered by those working on
>this document, I suggest that you send them to the chair of J4 at:
>
> Don.Schricker <at> microfocus.com
Done.
- Previous message: Robert Wagner: "Re: In answer to RW - again (was: Sorts (revised)"
- In reply to: William M. Klein: "Work progresses on ISO COBOL definition of native support for XML"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|