I'm possibly working for a client who has selected to use MFC and DCOM
to architect a solution on a LAN with no external access required. I
think the OS is W2K.
As far as I can gather the GUI will be a form based GUI with
There will be a large number of users on the network which has me
thinking about deployment and load balancing.
In terms of deployment, I was thinking about making the client as thin
as possible to minimise the impact of change on the client because
deployment may be a pain.
I was thinking about writing STA C++ components to be housed in
MTS/COM+ to support connection pooling/activation. The number of MTS
servers required I believe is 1 per 100 users. In terms of
load-balancing then I was thinking about using clustering services in
W2K. The client will create components via CoCreateInstanceEx,
providing the name of a cluster server that will route the request. If
the OS is NOT W2K then I will write a custom solution that will select
a server from a list by random.
My next question is around the passing of state between client and
server. I was going to use XML.
The user will use the MFC app to essentially retrieve/modify/delete
data stored in Oracle DB. I was going to have the MFC app then render
and allow the user to modify an XML representation of this data. The
user then submits the XML document to the server for storing.
My concerns in this area are as follows:
1 - Client side validation - business rules. If I am sending XML to
the client then maybe the business rules should be held in a schema
file that can be applied to the edited XML document prior to sending
to the server. On start up then the application could download the
latest schemas or take them from a mapped network drive. I believe the
schema language to use is XSD - would that be correct?
2 - I know SQL Server supports XML natively but I dont think Oracle
does which means a lot of time on the server will be spent
constructing XML documents.
As far as the server is concerned:
1 - I Will write STA components housed in COM+, each transactional
component will implement use the objectContext to commit/rollback.
There will be 2 kinds of components: Readers (simple return data) that
are non-transactional and Witers (Add/Update/Delete) data.
2 - On the server there will be a use case controller (UCC) class that
will be the entry point to the server and will inspect the XML doc
header and pass the XML doc to the appropriate Use case manager (UCM)
that will then do the retrieveing, editing, deleting of data. I dont
know if I like this though because the UCC being in an STA may become
a bottleneck in that it has to wait for each use case to finish before
being able to extract the next from it message queue and process
because of the syncronous nature of the STA. Once the UCM has finished
it's work it will return the results to the client (immeadiatley) so
no MSMQ involved.
In terms of client/server communication then I was going to use the
"Export" facility in COM+ that allows the creation of a client install
package with all the proxy stubs in it and then run this against each
client, although it may only be necessary to install the proxy-stub
for the UCC on the client...
Any thought on this would be much appreciated.