membership/role providers - transactions and integrity!

[mehdi]

Hi folks,
I got a general question that I cannot find the answer for. Consider a
3-tier application architecture with a Web Service handling the
business layer (BL) logic. The BL provides the client the facility to
create/update/delete or query any given Employee account within the
system. Each employee has got a username/password pair that's supposed
to be stored in the *aspnetdb* database using the Membership API. The
question is that how a client is supposed to create an employee account
with one web method, and create a new user name with another web
method, *transactionally* under a *stateless* web service???

[WebMethod] void CreateEmployee(Employee employee) { }

[WebMethod] void CreateUser(string username, string password) {}

How am I supposed to keep the integrity of the system? Maybe, you
suggest the following WebMethod instead of those two:

void CreateEmployee(Employee employee, string username, string
password) {}

However, this introduces a new bunch of problems under the
UpdateEmployee/DeleteEmployee and the like methods.

What should be done to handle the issue rationally?

Thank you for your time,
Mehdi

 

[John Saunders]

Hi folks,
I got a general question that I cannot find the answer for. Consider a
3-tier application architecture with a Web Service handling the
business layer (BL) logic.

Why is that a good idea? Below, you describe why it is not a good idea. Is
there something that overrides the bad?

John

 

[mehdi]

I don't get your point! Would you please describe more?

 

[John Saunders]

I don't get your point! Would you please describe more?

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

 

[mehdi]

I do agree with your approach - no ifs and/or buts.

Thank you for your time,
Mehdi