membership/role providers - transactions and integrity!

Discussion in 'ASP .Net Web Services' started by mehdi, Nov 30, 2006.

  1. mehdi

    mehdi Guest

    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
     
    mehdi, Nov 30, 2006
    #1
    1. Advertising

  2. "mehdi" <> wrote in message
    news:...
    > 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
     
    John Saunders, Dec 2, 2006
    #2
    1. Advertising

  3. mehdi

    mehdi Guest

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

    John Saunders wrote:
    > "mehdi" <> wrote in message
    > news:...
    > > 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, Dec 2, 2006
    #3
  4. "mehdi" <> wrote in message
    news:...
    >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
     
    John Saunders, Dec 2, 2006
    #4
  5. mehdi

    mehdi Guest

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

    Thank you for your time,
    Mehdi

    John Saunders wrote:
    > "mehdi" <> wrote in message
    > news:...
    > >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, Dec 3, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mehdi
    Replies:
    0
    Views:
    382
    mehdi
    Nov 30, 2006
  2. Replies:
    0
    Views:
    389
  3. Replies:
    1
    Views:
    361
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Feb 20, 2007
  4. =?Utf-8?B?Ym9iYnk=?=

    Membership and Role Providers

    =?Utf-8?B?Ym9iYnk=?=, Sep 23, 2007, in forum: ASP .Net
    Replies:
    4
    Views:
    298
    =?Utf-8?B?TWFuaXNo?=
    Sep 24, 2007
  5. Roger Martin
    Replies:
    0
    Views:
    305
    Roger Martin
    May 28, 2008
Loading...

Share This Page