Anyone know of any white papers or doc that shows the advantages or disadvantages between ACI and RPC implementation of EntireX ?
We are considering using this to replace our middleware and there is some confusion with some of our staff members over which is better, what the differences are and when you should choose one over another.
RPC is a higher-level interface that uses ACI underneath. ACI is more feature-rich. RPC is a lot easier to use, and most of the wizards and wrappers that allow for rapid development use RPC.
A rough analogy might be Natural vs. Assembler. You can do things in Assembler that you can’t do in Natural, and often do them more efficiently, but development is faster and easier in Natural.
In general, if you can use RPC, you probably should. RPC works well for synchronous request / reply communication - one request waits for one response. Conversations can be used to aggregate messages - a series of request/reply pairs between the client and a server. This model typically satisfies 90% of web enablement application needs and a large portion of point to point application integration scenarios.
An important difference is that RPC is field oriented - all of the conversion issues in transferring data from one platform to another are handled by the generated wrappers. RPC wrappers know about native formats on each side - for example, Natural date formats are automatically transformed to date formats in the client language - Java, .Net, etc. ACI messages are strings - the application programs will have to know what the layout of that string is and what conversion to apply to it - which typically means that the sender converts the data to a display format that the receiver will may have to convert back to its native format.
RPC is also required to expose and consume web services from EntireX.
More complex communication patterns will require using the ACI: single request with 0 to many responses, message queuing (known as UOW’s in EntireX and variable requests with variable responses (where the client/server roles are nearly interchangable). ACI messaging can be asynchronous - each call can determine if it needs to wait for a response or if it will check for a response at a later time or not at all.
With RPC I’m concerned about the fixed field/format restrictions. For example, if I have a web page that displays data from adabas and I need to add an additional field to the page (which happens frequently) then what changes do I need to make with RPC?
If I’m using ACI, with more of a free form message, then I can just append the new field to the message buffer - can’t I?
You would need to update the IDL to add the new field and regenerate the wrapper.
If you add more data to an ACI call, be sure to update the send and receive lengths for both the client and server programs.
Douglas,
Thanks for the reply.
RPC sounds like it would be a bit more work when adding/removing fields.
With ACI the buffer length could be set to something much larger than what is needed and that way it would accommodate any future fields and whitespaces could be ignored - true?
of course you can add padding, but your sending / receiving programs will need to be adjusted each time anyways to insert and extract the additional element(s) anyways, so adjusting the lengths is not a big deal, just something to remember to do. Adding padding can create some overhead since the padding is then transmitted on each call, so the amount of padding becomes a trade off between maintaining the program partners and the overhead involved.
With ACI, you can write applications that dynamically identify what their content is and calcuate the actual length on every call…but why bother? Seriously…if your communication model is satisfied by synchronous request / reply, you will be better off using RPC for 90+% of your applications!! If you do have a subset of the applications with very variable requirements then do that portion with ACI.
Don’t underestimate the amount of programming effort needed to interpret those message strings - and it has to be coordinated on both sides (sender and receiver), in addtion to the code required to maintain the infrastructure (server program and client calls). Adding or removing an element and regenerating a wrapper is a small effort and will reduce your possibilities of programming errors. With RPC the server is provided and most of the client programming is done for you.
As I said earlier, if you can use RPC, you probably should!
You can do the same with RPC - if you use variable length alpha fields (AV). But then you loose a lot of the power of RPC as Douglas has mentioned - your application logic (both on the client and server side) needs to know the exact offsets and lengths of the “fields” which are part of the ACI buffer or the AV variable.
With RPC you can also use any data type, not only alphanumeric data types, e.g. integer, floating point, numeric, boolean, binary, … If the client and server are running on different hardware platforms the RPC layer takes care of converting the data values from one internal representation to another.