Analogy between Beans and Activated Objects


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 6 of 6

Thread: Analogy between Beans and Activated Objects

  1. #1
    Peter Leong Guest

    Analogy between Beans and Activated Objects


    Hi All,

    I'm very new to .NET framework but I've done some 3 tier development work
    in Java. Recently after attending a conference on MSDN about distributed
    development application. I could not seem to daraw the analogy on Server
    Activated Objects and Client Activated Objects ...

    I'm not sure if analogy can be drawn here between Java Beans and Activated
    Objects ....


    Stateless Session Beans = SingleCall Server Activated Objects
    Statefull Session Beans = Singleton Server Activated Objects
    Entreprise Beans = ???

    I don't even know if the above is true.



    Thanks in advance
    Peter
    peterlck@hotmail.com




  2. #2
    Aaron Sevivas Guest

    Re: Analogy between Beans and Activated Objects



    >Entreprise Beans = ???


    A session bean is an enterprise bean, along with the entity bean. Their
    called Enterprise Java Beans (EJBs).. An EJB in the MS world is a .NET component.
    I don't think there is such a thing as an Entity Bean in the .NET world.
    Best practice in the java world is to not build entity beans on big systems
    anyways because of the performance hit.

  3. #3
    Peter Leong Guest

    Re: Analogy between Beans and Activated Objects


    Hi Aaron,

    Thanks for replying ... really appreciate that ...

    Since MS World does not have Entity beans ... Can I say that all persistence
    of data is also done at the Server Activated Objects level and the container/server
    that these objects reside in will also have Transaction management to handle
    all the persistence issues.

    I think in EJB, developers are not encouraged to write multi-thread development
    code as they are handled by the container/server. I was wondering if it
    is a must to write multi-thread application in .NET or transaction services
    are offered by the MS server/container as well.

    Please do not hesitate to ask should the above does not make sense to you.

    I'm really very new to this and was thinking of trying out .NET framework.

    Thanks in advance,
    Peter





    "Aaron Sevivas" <aaronsevivas@hotmail.com> wrote:
    >
    >
    >>Entreprise Beans = ???

    >
    >A session bean is an enterprise bean, along with the entity bean. Their
    >called Enterprise Java Beans (EJBs).. An EJB in the MS world is a .NET component.
    > I don't think there is such a thing as an Entity Bean in the .NET world.
    > Best practice in the java world is to not build entity beans on big systems
    >anyways because of the performance hit.



  4. #4
    Aaron Sevivas Guest

    Re: Analogy between Beans and Activated Objects


    >Since MS World does not have Entity beans ... Can I say that all >persistence
    >of data is also done at the Server Activated Objects level and the container/server
    >that these objects reside in will also have Transaction management to >handle
    >all the persistence issues.


    yes. Exactly like the java world, feature for feature if my research is
    correct correlating .net services and app servers like weblogic. What the
    java world doesn't have are code level attributes. These look like custom
    tags that allow frameworks (like an application server) to inject code (like
    macros) into your code. This helps when it comes to security and transaction
    handling, not to mention the fact that u could write your own custom attributes..
    pretty cool stuff.. Plus the complexities of rolling an ejb (the config
    files, the special compilers(wls ejbc) etc) are simplified in the MS world.
    In my opinion, SUN's component architecture has reached a level of complexity,
    where its better to NOT use J2EE and just create your own, monolothic app
    that exposes an rmi server, uses reflection for class lookups, u can handle
    the threading (its not that hard!), and u can handle load balancing (fairly
    simple algorithm if u keep state off the application layer).. And use a dirty/clean
    data scheme to enforce transaction processing. This type of application
    would work in most cases (small to mid-range, 10,000 concurrent)..

    Personally, I like lazy component registration in .NET. I haven't had too
    much experience with writing an enterprise app with .NET, so I can't honestly
    say its better, but I certainly see the potential here.


    >I think in EJB, developers are not encouraged to write multi-thread >development
    >code as they are handled by the container/server. I was wondering if it
    >is a must to write multi-thread application in .NET or transaction >services
    >are offered by the MS server/container as well.


    no. in the .net component world, u should (still) not create new threads
    in components running within the app server because threading is handled
    by the app server. Upon close inspection u will see that the design principles
    in J2EE and .NET component building are more similar than not.

    >
    >Please do not hesitate to ask should the above does not make sense to you.
    >
    >I'm really very new to this and was thinking of trying out .NET framework.
    >


    I believe I understand all that u have said and U def should check out .NET's
    component architecture! J2EE has so much caked on grime, thick slow layers
    of inefficiency, its almost painful to look at an enterprise J2EE system...
    Ick! I am and have been working with J2EE for 2 years now developing a mobile
    bank for a large bank in Scandinavia. I am not too impressed with J2EE or
    the vendor software that goes along with it..

    my $.02

    ~aaron

  5. #5
    Peter Guest

    Re: Analogy between Beans and Activated Objects


    Hi Aaron,

    Thanks for the info ... I would think i'm very lucky to have someone like
    you with J2EE experience explaining .NET to me ... hmmph! Well I think it
    more or less confirm what I've heard about .NET prowess or its potential
    ...

    Really appreciate that ... hopefully we'll have the chance to talk about
    .NET in the workings of enterprise applications in future.

    Thanks again. I think I'll just swim into it ... "grinning"

    Cheers,
    Peter



    "Aaron Sevivas" <aaronsevivas@hotmail.com> wrote:
    >
    >>Since MS World does not have Entity beans ... Can I say that all >persistence
    >>of data is also done at the Server Activated Objects level and the container/server
    >>that these objects reside in will also have Transaction management to >handle
    >>all the persistence issues.

    >
    >yes. Exactly like the java world, feature for feature if my research is
    >correct correlating .net services and app servers like weblogic. What the
    >java world doesn't have are code level attributes. These look like custom
    >tags that allow frameworks (like an application server) to inject code (like
    >macros) into your code. This helps when it comes to security and transaction
    >handling, not to mention the fact that u could write your own custom attributes..
    >pretty cool stuff.. Plus the complexities of rolling an ejb (the config
    >files, the special compilers(wls ejbc) etc) are simplified in the MS world.
    > In my opinion, SUN's component architecture has reached a level of complexity,
    >where its better to NOT use J2EE and just create your own, monolothic app
    >that exposes an rmi server, uses reflection for class lookups, u can handle
    >the threading (its not that hard!), and u can handle load balancing (fairly
    >simple algorithm if u keep state off the application layer).. And use a

    dirty/clean
    >data scheme to enforce transaction processing. This type of application
    >would work in most cases (small to mid-range, 10,000 concurrent)..
    >
    >Personally, I like lazy component registration in .NET. I haven't had too
    >much experience with writing an enterprise app with .NET, so I can't honestly
    >say its better, but I certainly see the potential here.
    >
    >
    >>I think in EJB, developers are not encouraged to write multi-thread >development
    >>code as they are handled by the container/server. I was wondering if it
    >>is a must to write multi-thread application in .NET or transaction >services
    >>are offered by the MS server/container as well.

    >
    >no. in the .net component world, u should (still) not create new threads
    >in components running within the app server because threading is handled
    >by the app server. Upon close inspection u will see that the design principles
    >in J2EE and .NET component building are more similar than not.
    >
    >>
    >>Please do not hesitate to ask should the above does not make sense to you.
    >>
    >>I'm really very new to this and was thinking of trying out .NET framework.
    >>

    >
    >I believe I understand all that u have said and U def should check out .NET's
    >component architecture! J2EE has so much caked on grime, thick slow layers
    >of inefficiency, its almost painful to look at an enterprise J2EE system...
    >Ick! I am and have been working with J2EE for 2 years now developing a mobile
    >bank for a large bank in Scandinavia. I am not too impressed with J2EE

    or
    >the vendor software that goes along with it..
    >
    >my $.02
    >
    >~aaron



  6. #6
    Aaron Sevivas Guest

    Re: Analogy between Beans and Activated Objects


    Happy to help Pete!

    "Peter" <peterlck@hotmail.com> wrote:
    >
    >Hi Aaron,
    >
    >Thanks for the info ... I would think i'm very lucky to have someone like
    >you with J2EE experience explaining .NET to me ... hmmph! Well I think

    it
    >more or less confirm what I've heard about .NET prowess or its potential
    >...
    >
    >Really appreciate that ... hopefully we'll have the chance to talk about
    >.NET in the workings of enterprise applications in future.
    >
    >Thanks again. I think I'll just swim into it ... "grinning"
    >
    >Cheers,
    >Peter
    >
    >
    >
    >"Aaron Sevivas" <aaronsevivas@hotmail.com> wrote:
    >>
    >>>Since MS World does not have Entity beans ... Can I say that all >persistence
    >>>of data is also done at the Server Activated Objects level and the container/server
    >>>that these objects reside in will also have Transaction management to

    >handle
    >>>all the persistence issues.

    >>
    >>yes. Exactly like the java world, feature for feature if my research is
    >>correct correlating .net services and app servers like weblogic. What

    the
    >>java world doesn't have are code level attributes. These look like custom
    >>tags that allow frameworks (like an application server) to inject code

    (like
    >>macros) into your code. This helps when it comes to security and transaction
    >>handling, not to mention the fact that u could write your own custom attributes..
    >>pretty cool stuff.. Plus the complexities of rolling an ejb (the config
    >>files, the special compilers(wls ejbc) etc) are simplified in the MS world.
    >> In my opinion, SUN's component architecture has reached a level of complexity,
    >>where its better to NOT use J2EE and just create your own, monolothic app
    >>that exposes an rmi server, uses reflection for class lookups, u can handle
    >>the threading (its not that hard!), and u can handle load balancing (fairly
    >>simple algorithm if u keep state off the application layer).. And use a

    >dirty/clean
    >>data scheme to enforce transaction processing. This type of application
    >>would work in most cases (small to mid-range, 10,000 concurrent)..
    >>
    >>Personally, I like lazy component registration in .NET. I haven't had too
    >>much experience with writing an enterprise app with .NET, so I can't honestly
    >>say its better, but I certainly see the potential here.
    >>
    >>
    >>>I think in EJB, developers are not encouraged to write multi-thread >development
    >>>code as they are handled by the container/server. I was wondering if

    it
    >>>is a must to write multi-thread application in .NET or transaction >services
    >>>are offered by the MS server/container as well.

    >>
    >>no. in the .net component world, u should (still) not create new threads
    >>in components running within the app server because threading is handled
    >>by the app server. Upon close inspection u will see that the design principles
    >>in J2EE and .NET component building are more similar than not.
    >>
    >>>
    >>>Please do not hesitate to ask should the above does not make sense to

    you.
    >>>
    >>>I'm really very new to this and was thinking of trying out .NET framework.
    >>>

    >>
    >>I believe I understand all that u have said and U def should check out

    .NET's
    >>component architecture! J2EE has so much caked on grime, thick slow layers
    >>of inefficiency, its almost painful to look at an enterprise J2EE system...
    >>Ick! I am and have been working with J2EE for 2 years now developing a

    mobile
    >>bank for a large bank in Scandinavia. I am not too impressed with J2EE

    >or
    >>the vendor software that goes along with it..
    >>
    >>my $.02
    >>
    >>~aaron

    >



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center