There has been a long running discussion across several threads on these forums about the "best" use of ProDataSets in an OERA context. One camp, mine, has advocated encapsulating the PDS in an object so that its definition appears only in one place. The other camp, principly argued by John Sadd, has advocated using a PDS as a "data exchange object", thus requiring the definition to be available at both ends or for it to be accessed using dynamic techniques. Recently, on this thread http://communities.progress.com/pcom/thread/16658?tstart=0 there was another discussion which bordered on this same topic, but focusing more on issues with regard to the UI. I thought it might be useful to bring the discussion over here and see what we can come up with.
Much of the earlier discussion focused on the interface between the data access layer and the business logic layer (see http://www.cintegrity.com/content/OERA-Strategies-Object-Oriented-or-Not ) for my summary of the issues in the discussion as of about 2 years ago). This recent thread, however, was focused on the client to AppServer boundary.
This focus raises several interesting issues. First, there is a question of where does an AppServer fit intothe OERA model? With a heavy client where there is business logic in the client, the client is clearly not just the UI. In fact, in the most extreme case, the AppServer may be functioning as little more than a remote data access layer. But, if we are designing for UI independence, which I believe to be one of the OERA goals, then it would seem that everything past the AppServer is UI and should have no business logic. Thus, one could have an ABL client, but one could also have a browser client or a .NET client and tyhe AppServer ideally wouldn't know which it was serving and would remain the same regardless of the UI technology. I understand that people who have existing fat ABL clients are often not motivated to go in this direction, especially since the ABL GUI for .NET means that they can have extremely nice clients, but it seems to me that, at least from the perspective of "how would I design if I was starting from scratch?", use of a fat ABL client is tying one into an ABL-only UI and this just doesn't seem to me to be good OERA or good design for optimal future growth.
Greg Higgins has talked a couple of times about using Sonic *instead of* AppServer or at least assigning a very limited role to AppServer. I hope he drops in an shares a bit more about his ideas since I don't feel like I am clear enough yet on what he is proposing to discuss them in this context.
Obviously, this architectural decision is a major watershed. If one assumes an ABL client containing business logic, then the AppServer divide is about putting logic close to where it is used and may or may not have much to do with the OERA model. At the very least it seems we would need an alternate OERA model in which the BL layer was divided in two and the UI and some of the BL were running in the same session. So, I'm going to focus more on the model where the AppServer boundary is the UI/BL boundary.
If we send a PDS over the wire, it is obvious that we are not making an allowance for a non-ABL client unless we are using the OpenClient technology to expose those PDS as a native technology. I don't know nearly as much about that as I would like and I hope someone who does know about it will pop in and say something about limitations and efficiency if the client is not ABL. My understanding is that, at the least, one is not able to support all possible client types.
PDS also have native serialization. While nice, this doesn't get me wildly excited since roll your own serialization is easy enough to do (and automate) and it seems that one has a lot more control that way. Some people will use a PDS even for a single business entity. This makes a certain sense in that it means that the interface between DA and BL is always a single PDS, whether simple or complex. But, since I want to pass an encapsulated object, not the raw PDS, when one gets to the single business entity, I am inclined to build it with properties, not a PDS. With roll your own serialization, this is not an issue and it is just as easy to spit out or take in a one "record" XML string as it would any other kind of object.
One of the advantages of passing a PDS to the client is that one can invoke the change tracking, make changes, and send the PDS back to the server for persistence of the changes and the AppServer can continue to remain stateless. Of course, this same information could be serialized into XML for a technology neutral solution, but it does raise the question of what is the right way to handle such things. Of course, there are some very difference circumstances. A number of usages are inherently read-only and don't raise this issue. Some are appropriate for client-side caching and one needs to consider subscriptions to be notified of changes.
Some usages are characterized by making minor changes in a potentially large object or set. One might wonder if sending back only the changes would be more appropriate, although this would require some kind of idenfifier so that the server side could determine whether the change was being applied to a record in the same state as the one that was sent.
And, some usages inherently involve moderately large amounts of data that needs to move in both directions. Is a PDS inherently a more efficient way to send such datasets to and from or might XML be more efficient in the end?
I'm sure there are other issues I should have mentioned, but perhaps this will get us started.