× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.