Why do you feel it is a good idea to expose your business logic functions as
web services on a one-to-one basis? You described several reasons why it is
_not_ a good idea to do so. I was wondering if you had any reason to believe
it was a good thing to do.

This is a very oblique way of saying that you should consider more of a
Service-Oriented Architecture. Instead of exposing fine-grained operations
like "create user" and "create employee", expose operations which embody
larger operations, like "Provision New User". This might include the "create
user" and "create employee" functions, and could perform those two functions
within a transaction.

Now, I also dabble in UML. Several times, I have been able to find the
service boundary by working with use cases and UML Use Case Diagrams. I have
found it to be a good rule of thumb to find the "top-level" use cases,  then
to expose them as services. Now, use cases are meant to be descriptions of
pieces of useful behavior, from the point of view of one or more "actors".
"create user" and "create employee" might be considered use cases, but
they're not "top-level' use cases. No actor would use "create user" and then
feel that they'd really accomplished something. On the other hand, some
actor might have "provision new user" as something they needed to
accomplish, so that's the function you should expose.

So far in my web services career, this approach has also had the benefit of
showing me where transaction boundaries should be. An actor would expect
"provision new user" to be an atomic operation, so that's a natural
transaction boundary. The fact that "create user" and "create employee" are
business logic functions which can be transactional is irrelevant to what
the actor is trying to accomplish. If I were implementing using COM+, for
example, I might set "provision new user" as "Requires New Transaction", but
the two "creates" as "Requires Transaction".

John