This subject was originally a reply to Peter Morris "N-tier" newsgroup thread but I start a new thread here on the subject of DCOM for others wondering about DCom.
Questions and worries about "problems with BoldCOM" are heard in the news groups and I here want to give some hints.
First I recommend to differ typical problems using a COMMON CPU for serving multiple clients from the "protocol" (and related tricks) connecting clients to the CPU (More on that in the summary far below).
Some screen shots visualizes some simplier solutions to some specific "DCOM UI component problem" caused by Bold components subscribing to individual fields of individual objects over a network (or even worse, over the internet...). Any transfer protocol will in a multi user environment reach any present day bandwith limits trying to do so without care. But if used with care and designing the entire environment (server & client) to support a three tier "protocol solution" the Bold DCom solution also has its benefits.
Look at the screen shots below and try to imagine what's behind the scenes, remembering that no business logic exist on the client side, no logic exists in the database, its all executed on one (1) server CPU in interaction with multiple clients. It also shows that a RAD DCOM UI doesn't have to be poor, 100% stateless and "dead" to the user. In fact it can be fairly "populated" and seemingly very active and responding to the user. With Bold DCom YOU can decide the "stateness" of the data transferred between server and client. YOU can vary your approach and UI solutions depending on frequency of usage, the CPU load caused by single actions, and the need of "active interaction" and support of alternative data displayed. All this depending on details in user actions and changing contexts in edit dialogs etc. Having this freedom the keywords are "vary" and "possible" concerning techniques. These keywords apply because you have an almost full range of technical and functional possibilities although you don't always have unlimited capacity (bandwith etc). Thus you must vary your approach.
Having said all this, reminding you of the fact that the form shown below is a fully functional in its final RT environment (DCom clients in MetaFrame), lets look at the screen shots;
Three screen shots showing data in "viewers" instead of displaying individual object members using separate DCom components for each attribute. (Note also that most of the list handles are used only when triggering search operations on demand, they are normally fairly passive when only viewing&browsing data with the form)
Fig 1: Order book form (parcels for later transport planning) Design time - The form looks fairly "empty" in design time (= many blank HTML viewers):
Fig 2: ...in runtime the UI is fully informative and interactive.
Clicking on the HTML viewer of the "Parcel Details" area opens a regular dialog with Delphi components (non Bold aware). On confirm the data is sent to the server which inserts the details into appropriate object fields causing the UI attribute 'ParcelDetailsAsHTML' to refresh the viewer by sending one single new (html) string back to the client. User messages are shown as errors, warnings or information to the far right using symbols, client unique user language in html formated text (or plain strings from code assertions or other code messages). Form captions and data and datalabels are displayed in the language defined by the user. The same server function returns text in different languages depending on "who is asking". Language can be changed in runtime (not fully implemented on this form though, you see both swedish and english mixed here, plus some debug tools in the upper right corner for browsing and manipulating everything from bold class members to meta data, states, manipulating state transitions, traversing the current object structure, sending/receiving intra-client chat, ditto mail and more, shortly - everything (Note - this is called a "thin" DCom client).
Fig 3 Here you can see the result of the previous dialog sent to the OSP and immediately parsed back to the client as one (1) html string for the viewer (to the right of the new dialog below). A fast and simple concept.
At last - fig 3 shows an example of a regular html hyper link triggering an event which determines which dialog and what data (since multiple partys are stacked in separate viewers to the left) to collect/to be displayed in the dialog. These fields are very special in that they are passiv displaying data but at the same time actively capable of searching for data over DCom and thus they are "active on demand". But this activity has a relatively low frequency and they are very temporary and thus doesn't affect overall performance very much - Viewing and browsing data is what saturates the network ! (The hyper links are "language sensitive" before we fully implemented this on the cleint side since the html text is generated by the OSP server and thus shown in my user language - swedish).
All the individual data fields shown in these examples where "passive while visible". Yellow COM components were used only to retrieve chunks of grouped data fields as long strings and sent back again after dialogs were closed (except for the grid which probably will be replaced later because this is a hot spot form in Attracs).
Data validation is to 100% validated by business rules on the server side(no business logic exist in the client).
With this approach of mixing concepts of "active" COM handles and "passive" html strings the user experiences an "active" UI but in technical terms it is almost "stone dead". Nothing actually happends except for regular format checking in dialog fields and sending data back to server logic. The upside is that the yellow handlers are refreshing the viewers with the latest current html data using the regular Bold subscription mechanism (Note that most subcriptions will be on the serverside since the html attribute keeps track of the multitude of fields internally on the serverside but only one field per viewer has subscriptions over DCom).
Since the captions and labels in the html text are language sensitive we have in effect many hundreds of "pseudo active" data fields on this form...! (seen from the server side). The viewer approach reduces that great number down to a fraction and the UI is in effect not "slow" at all even using a regular network connection. With many users (10+) a MetaFrame solution would reduce network performance problems to nearly "nothing".
Perhaps one can get mixed up about "performance problems with DCOM" and the fact that a DCOM solution implies using a common CPU as an Application Server. Note that the latter is related to the performance problem but not an explicit DCOM problem - efficient design and coding is a must for any solution using a common Application Server.
Efficient coding alone is definately not enough. Combining design & sharp coding will do though, one must "think efficient solutions/concepts" starting from the very model and keep it for the overall design all the way back and fourth to the clients. This is critical and we learnt a lot simply because we were forced to, we used a single *COMMON CPU* on the app server side.
Putting it all together it don't look too bad with the Bold DCom solution as far as I can see. Using it being aware of "its limits" (bandwith for detailed objects attributes, using tricks to reduce numerous objects in listings etc) then its all about you. It's powerful if used with care. Its useless if the design and application is not adapted for it.
When we started using the Bold DCom technique it was buggy and slow and it was obvious that it was "impossible" to achieve the required performance and reliability. Being stubborn and a little crazy, and Boldsoft fixing bugs and some optimizations, and sweetening it all with a little patience - and solving fundamental problems already in the model (avoiding coding tricks) - it looks completely different today. To me it looks promising. A talented designer fixes any bottle necks and any typical performance problems in one way or another.
New thoughts and never_seen_before_solutions are sometimes (often) required but isn't that what designers are good for anyway ? "The model is the system" applies for BoldCOM too.
Systems with many users would benefit from running clients in a MetaFrame environment.
// Rolf Lampa
(Current mail address: rolf-dot-lampa-at-rilnet-dot-com)