I've stressed before that in order to be fast and scalable, you need to be using request/response logic. R/R do have some limitations, there are times where being state-full is necessary. The usual example is the traversing through a database table. In SQL you've a cursor in order to do this. In Embedded SQL you can only traverse one way, but in ODBC both ways. Just consider when you make a search in a web search engine, you get the results 10 at the time.
A part of the issue is that you should keep the data size in R/R down. If you need to transfer a lot of data, you usually can begin to present data to the user with only a partial transfer.
PS: I added the possibility to send multiple replies to a call in an attempt to remedy this problem.
Tuxedo solves this with a conversation. A conversation is done by having conversational servers providing conversational services. These are in a different name-space that R/R services. The client gets one or, reserves of with a tpconnect() call ,and releases it by tpdisconnect () call. The conversation is done through calling tpsend () and tpread () on both sides. An import limitation in Tuxedo is that conversations are half duplex, only one side may do a tpsend () at a time, and the connection is turned with a flag on tpsend().
It quite possible that Tuxedo got is conversation concept from CPI-C, or that they specifically chose to be CPI-C compatible. CPI-C is the programming API for SNA APPC. APPC is the session layer in SNA. In CPI-C you do an allocate, send, receive, and deallocate in order to do a (mw)call. This simple spell of 4 calls are what is normally done in all CPI-C programs, but the API clearly allows keeping a dialog going. (I must admit that CPI-C is second hand information to me, I've never used CPI-C, only read the API doc.) I've interview a couple of seasoned CICS programmers for this info.
Personally I would prefer to have a normal socket between the server and the client. Partly for having a full duplex connection, partly because I love the select(2) call. Another reason is for things like TCL that has the possibility to wait for an event either from the user (key-press or mouse-input) or data on a socket at the same time.
I've barely begun writing code in MidWay for socket based conversations, but I'm holding it a bit off since there are issues on how this should be handled when having a gateway between two MidWay instances, and through FireWalls. (See Road-Map)
Another tempting thing to do is to make an ORB. An ORB in the MidWay fashion would be to call methods in the mwcall() way. No data types, and objects could dynamically add and remove methods on themselves. We would have to add a mwnew() or mwbind() in order to bind or create objects. I need to give this some thought. hmmm, neat idea...
An advantage in the way Tuxedo does it in the . It goes back to the number of TCP connections. Tuxedo most likely multiplexes the conversations on the connection already established.
However, you can your self implement a socket based conversation. If you
read mwreply() you will notice that the service
routine do not return (the macro mwreturn() do). You can in your service
routine create a socket, bind it and listen, then return the address of the
socket to the client thru mwreply(). Then you do an accept in the service
routine. Just note that until your service routine do perform a normal C
return, your server are busy.
|© 2000 Terje Eggestad|