I have an application that I believe to be an excellent candidate for a "web service". I realize, however, that a "web service" is just a rosey-peachy facility in my mind with very little in the way of actual knowledge to back it up, so I want to get some particulars out of the way before I propose it as the solution because this is a little more serious an issue than, say, planning on Mover Bars in a ListBox and finding out later that they don't apply to your RowSourceType of choice...

Background
The application is, at least at this time, a fee-based service between my client (the service provider) and a single customer. The data to be transmitted between them is highly confidential and of a personal nature and includes financial information.
The customer requires an internet-based facility to integrate this application easily into his existing infra-structure. The customer provides a service to people all over the world who are enrolled and who use the internet exclusively to access the service. At this time I do not know what platform(s) is in use for their existing services.
The transaction volume, at least in the initial months, is expected to be less than 300 transactions per day and is predicted to never exceed 10,000 per day. All transactions are (relatively) short in duration and small in parameters/return size, involving access to 3 tables (1 updated in half of the transactions) and writing to 2 other tables. All accesses are direct via SEEK and all writes are INSERTs.

Things that I need better understanding of are numerous (sadly):
Security
As noted above, security is paramount.
When I read about web services I invariably read about UDDI and the best I can make out is that it is a 'central repository' that describes available web services (and, I assume, facilitates their access).
Q1. Is it necessary for the service described above to be registered in UDDI?

Q1a. If so, what are the security implications of having it there?

Q1b. If not, what additional work/overhead/etc is implied in continuing accessibility to specific customers?

I have read a MSKB article that says that "Internet Protocol Security" (IPSec) is fine to use when the specific computers involved are known. In this case they are known.
Q2. Is this really true, or are there still ways that penetration is possible?

Q3. Can HTTPS still be used with IPSec ("account number" and PIN used for individual access (forwarded through the customer's system))

Programming/setup of the web service application
I have programmed some web applications using Web Connect and it is frequently mentioned in its (and related) documentation that web transactions are "stateless".
I've played with some of the VFP COM/COM+ samples on a single machine and they worked as described then. And looking more seriously at COM it seems clear to me that "state" must be maintained (by something 'automatic', external to me) in such cases. I understand the concept of a "use count" but I don't have a clue about what happens when a use count exceeds 1 (real user).
Q4. All examples seem to show a MTDLL being built. Is this the way it has to be done?

Q4a. Assuming it has to be a MTDLL, is registration in COM+ mandatory?

Q4b. If not, what do I lose if I choose not to register it with COM+?

Q5. Can I expect that prop-values/memvars/record-pointers/etc as set by one use (when there are several) will remain intact between method calls for that use?

Q5a. If not I guess this means that things are "stateless" here too, correct?

Q6. Are there specific gotchas that I should be wary of?

Thanks for any input you can provide.