RE: Messaging protocol (was: IIS to as/400 odbc)

["Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx>]

Buck,

1) ODBC _could_ be used to call those programs. We've e-nabled 2E
applications using exactly that scenario, EXCEXTFUNs are great things.
Especially with the advent of componentization in release 7. Mind you, with
external trading partners I'm NOT advocating the use of ODBC, just pointing
out that ODBC doesn't require knowledge of the database schema.

2) Why not look at using XML for moving the data back and forth? Or did you?
Your client and server would still work as is, just the text you move would
be in XML format. The advantage being that you could use XML validators to
make sure the received XML stuck to the defined schema.

3) MQ Series?

-Walden

-----Original Message-----
From: Buck Calabro [mailto:Buck.Calabro@commsoft.net]
Sent: Wednesday, August 15, 2001 1:49 PM
To: midrange-l@midrange.com
Subject: Messaging protocol (was: IIS to as/400 odbc)


>> I have looked into Scott Klements socket programming 
>> site is this what you are talking about?
>> If so (and I have not looked at the whole thing) how 
>> would this be different than opening acces to ODBC?
>
>The difference is that you would have your own protocol, 
>so a hacker is less likely to be able to figure out how to 
>access your data.

I'd like to chip in here for what it's worth.
I doubt that Joe is suggesting the creation of what the communications
people strictly call a protocol; i.e. not creating a private version of
TCP/IP or APPC.  Rather, it sounds more like creating a private command
language.  Here's where brighter minds than mine should start their
critique.

I have a similar situation where I'm creating an API for outside vendors to
access my application.  I don't want to give them my database via
ODBC/DRDA/SQL, because then I need to explain (in gory detail) all the
relationships between all the files.  The application is created by Synon,
so the business rules are "enforced" by program code; not the database.  

I'm having the Synon folks write me a handful of functions to retrieve from
and to update the database.  Eventually, they'll be able to use these
functions within the Synon application, but for now, they're only for my
use.  

Now the hassle is how to how to enable an outside vendor easy access to
these functions.  I settled on sockets.  I'm writing my own set of commands
so to speak, that the vendor can use to "call" my new API functions, so a
typical transaction might go like this:

(client)GET NEXT ORDER
(server)  order=1234567
(client)GET ORDER 1234567 
(server)  name=Fred Bloggs
(server)  address=123 Broadway
(server)  total=555.00
(server)  ok
(client)UPDATE ORDER 1234567 STATUS=APPROVED
(server)  ok

You get the idea.  A hacker can connect to the socket port by scanning, but
my socket server program won't respond because the hacker doesn't know any
of the proper commands.  Now, I didn't create commands to foil hackers, and
this isn't sniffer-proof, but it's a little better than giving open ODBC
access, in that there isn't a command to list all the tables in the system,
like "select * from systables".

We're working on a challenge/response authentication system to help secure
this even more, but using  an encrypted session would be better than that.
Challenge/response goes something like this:

(client)CONNECT
(server)hash=73a5r0kl3pa5ffg6
(client uses an encryption algorithm to create a passkey, using the hash as
a seed)
(server uses the same algorithm using the same hash)
(client)pass=5hh9as85ghy
(server)login accepted

I hope I've made a contribution...

Buck 
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com