Discussions

News: Opinion: EJB 3.0 is not ready yet! That's your chance!

  1. Michael Nascimento Santos is blogging about EJB 3.0, and how we all can put comments to the EJB committee, and should do so NOW!

    He had some ideas of his own, including:

    Access to the actual Subject returned by the JAAS login mechanism: OK, we can use JAAS in J2EE. JAAS is great, because it gives you enormous flexibility regarding login mechanisms, credentials, principals etc. But how is it supposed to be useful if you can't access the credentials and principals after you have authenticated the user? That's how it works now. Hope it changes, really.

    Instance-based security: I've never been able to make any meaningful use of the security features provided by the current EJB spec. It is impossible to do it if your only option is declarative security - and I am not using it in the sense the spec uses it, but I am referring to static security. You need to be able to restrict access based on what values instance properties hold. That is how real world systems work. Interceptors - or advices - would be a good way of implementing this.

    Dynamic security: In real world enterprise systems, there is no such thing as this role will access these functionalities. Users want to define new roles and new security mappings without having to call the developers and redeploying the application. It is a fact and it is reasonable, but not supported by the current spec. It should be.

    Paging facilities: If your application server does a good job when it comes to its CMP engine implementation, then probably the only JDBC code you have to write for your application is in order to provide paging facilities. If that's so, why don't we have paging facilities as part of the spec? Why aren't they supported? A solution would be to have finders that return Lists. Then, you would be able to take a slice of it and your container would know you are going to use only this little piece. So, it could load a page, instead of the whole Collection.

    Threading facilities: If know something about the EJB 2.1 draft spec, you may argue that we already have these as Timers. Really? Don't think so. Take a look at the latest proposed final draft for the JCA new spec. That's support for multithreading! We should have some kind of thread pool provided by the container or a Work-like interface. Linda didn't quite like this suggestion, though. What do you think?

    Meaningful names for commit options: Do you know what commit option A means? Those who have some experience with EJB unfortunately do. Why couldn't it be named container-exclusive-database-access or something like it? According to Linda, the commit options were supposed to be just an example, but nearly every application server uses the terms commit option A, B or C as if the difference between them was so clear as between Entity Beans and Session Beans.

    What do you think of these, and what would you like changed/added?

    Read EJB 3.0 is not ready yet! That's your chance!

    Threaded Messages (58)

  2. I'm not sure whether we can still re-direct the 3.0 spec even now. But I do find the point about paging facilities valid. On the other hand, maybe security models are too solution-specific. It would be very hard to put all kinds of fine-grained (instance-based security, etc) considerations into the spec.

    Anyway it's nice to have such a discussion: if anybody can influence the spec writers, it must be here at TSS:P

    Cheers,

    Jacques
  3. I'm not sure whether we can still re-direct the 3.0 spec even now.


    Hum, I guess Linda wouldn't ask us for suggestions if she wasn't intending to use them. I really think she's going to consider them.

    > But I do find the point about paging facilities valid.

    Thank you :-)

    > On the other hand, maybe security models are too solution-specific. It would > be very hard to put all kinds of fine-grained (instance-based security, etc) > considerations into the spec.

    I am afraid I have to disagree with you (that would be the kind of thing you would expect from the guy who suggested those :-P). All the security facilities EJB provide are useless to me and many other architects I talk to agree with me. Interceptors would solve the problem without the need to make any other changes to the spec. All you would have to do is to implement your own SecurityInterceptor. Not bad. :-)

    > Anyway it's nice to have such a discussion: if anybody can influence the spec > writers, it must be here at TSS:P

    And @java.net, hopefully. Hope to get more comments from you guys, whether you agree or not. And keep on checking my blog. I have written a new piece today about OOP to AOP transition.

    Regards,
    Michael
  4. Ooops, wrong link[ Go to top ]

    Try this link to access my blog.
  5. <Michael>
    All the security facilities EJB provide are useless to me and many other architects I talk to agree with me. Interceptors would solve the problem without the need to make any other changes to the spec. All you would have to do is to implement your own SecurityInterceptor. Not bad. :-)
    </Michael>

    I cannot agree with you more (despite of your disagreement :-P). It's true that all the security facilities are useless, and I prefer dynamic security models to declarative ones. But as you put it, this all leads to an interception based solution, which can be very orthogonal with the container issues, or namely, the specs.

    Call it AOP. And maybe AOP is sth beyond the current EJB horizon. Will the spec writers be willing enough to adopt this?

    And with an interception architecture, we can implement various security models, however complicated and tangled they are. That's why I referred to security issues as "solution-specific". Maybe they are just too liquid to be settled down in a, say, 400-page PDF document.

    Yes, there is the concern that if we go with interception, we can hardly have it standardized, and we have to use home-grown or proprietary frameworks. There is the danger of being locked-in. But there is AOP-Alliance already at sourceforge. Maybe the guys in this alliance are much easier to deal with than the spec writers (well, I'm not sure...).
  6. But as you put it, this all leads to an interception based solution, which can be very orthogonal with the container issues, or namely, the specs.

    >
    > Call it AOP. And maybe AOP is sth beyond the current EJB horizon. Will the spec writers be willing enough to adopt this?

    > Yes, there is the concern that if we go with interception, we can hardly have it standardized, and we have to use home-grown or proprietary frameworks. There is the danger of being locked-in. But there is AOP-Alliance already at sourceforge. Maybe the guys in this alliance are much easier to deal with than the spec writers (well, I'm not sure...).

    It depends on how you approach the problem. Servlet Filters act like - note I am not saying they are the same! - a special kind of Interceptors for Servlet Container calls. I think we could have something similiar: some kind of EJBInvocation class, with subclasses for the 3 EJB types we have, an EJBInterceptor interface with only one method, doInvoke or whatever, you should implement. Your doInvoke() method would take an EJBInvocation and an EJBInvocationChain so you could call the next interceptor or call the actual method.

    Then, we would map our instance to some/all components using deployment descriptor new tags. And that is it: portable and powerful. Think of how many serious application servers support Interceptors right now: most of them. They just need to implement a classical GoF Adapter, it can't be that hard for people who write application servers :-)
  7. Great point, and I believe it can be competitive with the existing approaches. Some AOP frameworks are over-complicated, IMHO.
  8. Call it AOP. And maybe AOP is sth beyond the current EJB horizon. Will the spec writers be willing enough to adopt this?

    Adopt what, AOP?

    AOP is an implementation detail, it doesn't belong in the specification. It would be similar to require the use of dynamic proxies to implement the EJB container. Just let vendors decide what they think is best.

    However, defining an SPI to allow for some kind of interception, yes. But it has to be justified by more than just "being cool". Come up with some use cases and send them to Linda, she is very receptive to all these ideas for EJB 3.0.

    --
    Cedric
    http://beust.com/weblog
  9. Well, I guess that beyond the hype and I think J2EE is (it should be), it should provide a developers with strong set of tools to deal with enterprise issues and currently it lacks a lot, from my experience I go to proprietary solutions/hacks as it comes to caching, singletons, security (dynamic and instance-driven) that I need it like air (what we do is using base class for our Session facades aka "Interceptors"), weak (real weak) EJBQL support, Entity batch processing and concurrent processing (background processing/crunching).
    So at the end of the day there is too littlie support I get from the spec features and sometimes it is worse I had to fight and twig things in order to be spec compliant (not using sockets/file handles/threads), it is almost too hard to develop this way. Java in itself can hardly compensate for J2EE grievances and something should be done about it and fast.
  10. However, defining an SPI to allow for some kind of interception, yes.


    Hi Cedric,

    What do you think about my suggestion? Though it wasn't carefully thought, I think it would be a very useful way of allowing us to support complex security models, for example, and also giving us power to do nearly everything. I don't want a full-blown AOP API; support for interceptors and deployment descriptors for them would be enough.

    []s
    Michael
  11. Interceptors in EJB 3.0[ Go to top ]

    After pondering this for a while, I am beginning to think it would be a bad idea to add interceptors to the EJB 3.0. I explain my reasons in my blog. Feel free to comment there or on this thread.

    --
    Cedric
    http://beust.com/weblog
  12. Interceptors in EJB 3.0[ Go to top ]

    I whole hearted agree with Cedric's points in his blog. I would like to add something we all seem to have forgotten about, the virtue of EJB.

    One thing we seem to loose sight of these days id that not all programming has to be done using EJBs, and thus not every cool (or indeed useful) thing has to be covered by the specification. EJBs were meant to be a simple component model for business entities and processes, providing many of the core services required in business applications. A lot of the stuff that people are suggesting threads, direct AOP and the like go against some of the value propositions of the EJB model.

    As an example AOP is cool and yes very useful! However this is very early days people are still chewing on the paradigm as a whole and on the syntax issue (language features - AspectJ or configuration file - JBoss). So use this technology if you wish indeed I hope to do so in the near future, but it does not have to be in the spec, your code will still compile and run.
  13. Interceptors in EJB 3.0[ Go to top ]

    Cedric In his blog:
    <Cedric>
    Lack of use cases

    Interceptors have an undeniable "cool factor". They make for great demos and allow you to take peek inside what used to be seen as a magic black box. Over the years, I have talked to several customers using EJB intensively and only a few of them asked for interceptors. What was interesting is that when I drilled down and asked them why exactly they wanted interceptors, it always turned out that their needs could be met through different means than EJB interceptors (some of them being flags that we already provided and they didn't know about, others being telling them about some EJB lifecycle events they didn't know about).
    </Cedric>

    Maybe we can scroll back and watch how it began. Actually Michael suggested interception be used as the architecture for security models. That does offer many meaningful use cases, instead of just being "cool" for the sake of "coolness".

    I believe the comparison btwn servlet filters and the lightweight interception architeture Michael suggested is valid. It's much easier to understand and implement than most existing AOP solutions. And with such facilities, one can implement one's own specific security model on the fly. Please consider it, no matter you call it AOP or not.

    I'm wrorrying about the political issues here. We could lose our practical perspectives if we treat everything as a religious war. Simple interception IS practical even though we don't convert ourself to AOP.

    And I noticed a visitor left such a comment at Cedric's blog:
    <visitor>
    It would be too early to build J2EE on top of AOP. AOP is still too new. Good efforts have been made so far but not enough. making interceptors part of the EJB spec might be a good introduction to AOPfied J2EE.
    </visitor>

    That's exactly what I meant.
  14. Re: Interceptors in EJB 3.0[ Go to top ]

    Maybe we can scroll back and watch how it began. Actually Michael suggested interception be used as the architecture for security models. That does offer many meaningful use cases, instead of just being "cool" for the sake of "coolness".
    I believe the comparison btwn servlet filters and the lightweight interception architeture Michael suggested is valid. It's much easier to understand and implement than most existing AOP solutions. And with such facilities, one can implement one's own specific security model on the fly. Please consider it, no matter you call it AOP or not.
    I'm wrorrying about the political issues here. We could lose our practical perspectives if we treat everything as a religious war. Simple interception IS practical even though we don't convert ourself to AOP.


    It is pretty obvious I agree with this one :-) I have to agree with Cedric that sometimes people think about using AOP just because it is cool - which is exactly why 99,5% of all developers are using webservices right now -, but I find it very hard to think of another solution that solves all the issues I talked about in such a elegant and practical manner. Adding simple interceptors - and not a full-bloated AOP API, for God's sake don't do it!!! - would be a small yet very powerful addition.
  15. EJB != servlet[ Go to top ]

    Jacques:
    I believe the comparison btwn servlet filters and the lightweight interception architeture Michael suggested is valid.


    Actually, I don't believe it is.

    Servlets are as simple components as it gets: one entry point, no user-defined methods, no code generation, no lifecycle. Writing a chained interceptor framework for servlets is straightforward and useful, no questions about it.

    But EJB's are very different.

    If you want a comparison that is a little bit more meaningful, think of JSP's. JSP's involve code generation and user-defined methods. Now, specifying an interception framework for JSP's is much more tricky. Don't forget to account for tag libraries as well.

    Next in the complexity chain is EJB's, and I think you are beginning to understand why specifying interceptors in the EJB specification would be a big mistake.

    --
    Cedric
    http://beust.com/weblog
  16. EJB != servlet[ Go to top ]

    <cedric>
    Next in the complexity chain is EJB's, and I think you are beginning to understand why specifying interceptors in the EJB specification would be a big mistake.
    </cedric>

    It is for the same reason that (currently) I believe within the standard (J2EE or EJB) interceptors should be specified along with access to various contexts (app/module, security, transaction,...). I have been involved in an AspectJ / homegrown application server project for the last 2 weeks, and I can inform you that though AspectJ is a powerful and maturing technology, it still cannot help with any herioc attempt to untangle Java code that has concerns across various components with different communication and interaction styles.

    AspectJ is great within a standard J2EE environment because its easy to aspectize around specified interfaces but there is still the issue of capturing context and not just target(), this() and arguments(). By specifying interceptors the application server can hide any pecularities of their particular implementation and provide much more contextual information (passed in). Once people get passed the initial cool factor of AspectJ when introducing a simple call logging facility they start that introducing powerful aspects requires more complex aspect code and better design/implementation in the application itself. Lastly, its hard to for an powerful and useful aspect not to be tied to a particular container implementation.

    Cedric, do you really want ever single customer writing the same aspect code over and over again.

    I am still open to other suggestions around the problems mentioned above.

    William Louth
    JDBInsight Product Architect
    www.jinspired.com
  17. EJB != servlet[ Go to top ]

    William:
    Cedric, do you really want ever single customer writing the same aspect code over and over again.


    Certainly not.

    I see the Aspect work for J2EE broken down in three categories:

    1) Pointcut definitions. These should be provided by the application server vendor. A neutral body could probably standardize the names of the said pointcuts.

    2) Generic aspects. Some of these can be provided by the vendor.

    3) User-level aspects. Obviously developed by the users.

    Lastly, its hard to for an powerful and useful aspect not to be tied to a particular container implementation.

    Agreed, hence the break down above, which should address this limitation. And which, by the way, is exactly how we architected the WebLogic Aspect Framework.

    --
    Cedric
    http://beust.com/weblog
  18. EJB != servlet[ Go to top ]


    > But EJB's are very different.
    >
    > If you want a comparison that is a little bit more meaningful, think of JSP's. JSP's involve code generation and user-defined methods. Now, specifying an interception framework for JSP's is much more tricky. Don't forget to account for tag libraries as well.
    >
    > Next in the complexity chain is EJB's, and I think you are beginning to understand why specifying interceptors in the EJB specification would be a big mistake.
    >
    > --
    > Cedric

    I must be missing it... JSPs are just compiled to Servlets anyway, so I can already apply filters to them. XWork allows arbitrary code to be executed, and I can intercept the call to that with our Interceptors, so what's your point? The only thing necessary to make interceptors viable is a well-defined calling semantic and lifecycle, which EJBs have in spades. It's the perfect spot for interceptors. Code generation is not required by the spec, that's just how you do it. All that's really needed, if you introduce Interceptors, is the framework to call them in order. It's easy. Believe me.
  19. Interceptors in EJB 3.0[ Go to top ]

    Agree.

    AOP is definitely an implementation issue - not the spec. However, with emergence of JSR 175, spec will hopefully become more AOP-friendly by introducing metadata attributes as a declarative way to define transactions, security and more. By AOP-friendly I mean that with metadata both, user and container will have a clear notion of where orthogonal concerns are. How container chooses to implement this should still remain totally transparent and may not even be AOP-based.

    Regards,
    Dmitriy Setrakyan
    Fitech Labs, Inc.
    xNova™ - Service Oriented Technology for Java and .NET
  20. Re: Interceptors in EJB 3.0[ Go to top ]

    AOP is definitely an implementation issue - not the spec. However, with emergence of JSR 175, spec will hopefully become more AOP-friendly by introducing metadata attributes as a declarative way to define transactions, security and more. By AOP-friendly I mean that with metadata both, user and container will have a clear notion of where orthogonal concerns are. How container chooses to implement this should still remain totally transparent and may not even be AOP-based.

    Dmitriy,

    You need to have a component _you define_ to solve the security issues I mentioned. Business logic is too specific and it is related to security. The way to do it I envision is to intercept the calls and allowing custom components developers wrote to be called and to determine the call as valid or not. The best name to a component that intercept calls is an Interceptor, right? So, that's why I think simple interceptors are the way to go.
  21. Interception in EJB[ Go to top ]

    I don't see why interception concepts should be made part of an EJB spec. Aren't the two needs sort of orthogonal to each other?

    That's not to say containers cannot offer interception capabilities, but why should this be in the EJB spec. A servlet container could offer these as well, for example.

    Hardwiring in interception concepts into the EJB spec would create potentially incompatible interception APIs/hooks in the different specs that could benefit from formal interception capabilities.

    It would be a better option to add a full fledged JSR that deals with interception at all levels, nooks and cranies in the J2EE stack. This could, for example, take advantage of JSR175 (community review draft now available). Other specs (such as EJB3.0) could leverage this for their needs.

    Sandeep.
  22. Interception in EJB[ Go to top ]

    I don't see why interception concepts should be made part of an EJB spec. Aren't the two needs sort of orthogonal to each other?

    >
    > That's not to say containers cannot offer interception capabilities, but why should this be in the EJB spec. A servlet container could offer these as well, for example.
    >

    The Servlet spec DOES provide this. It's called Servlet Filters. This is exactly the same thing.
  23. Interception in EJB[ Go to top ]


    > The Servlet spec DOES provide this. It's called Servlet Filters. This is exactly the same thing.

    This is true. However, the point I was trying to make is the one of "wider applicability".

    Sandeep.
  24. Why should the developer be made aware of aop or interceptors? Isn't this an
    implementation issue?

    The EJB spec basically defines a contract. If the spec wants to specify instance level security, then define the requirements and functionality
    to achieve instance level security, and let the container decide how to best
    implement it.

    A lot of the functionality of the spec is already implemented in an interceptor
    or aop like manner, isn't it? We write the business logic, and the container takes care of things like security, transactions, ect. Whether this is achieved by interceptors, aop, or a new class implementing all the services is hidden from the developer. We just know the container is doing what it needs to do before and/or after our business logic is executed. Beyond a better understanding of EJB or a particular container implementation, did developers have to know that to write a J2EE application?

    Joe
  25. Why should the developer be made aware of aop or interceptors? Isn't this an
    implementation issue?
    A lot of the functionality of the spec is already implemented in an interceptor
    or aop like manner, isn't it? We write the business logic, and the container takes care of things like security, transactions, ect. Whether this is achieved by interceptors, aop, or a new class implementing all the services is hidden from the developer.

    Joe,

    Think of simple interceptors the same way you think of Servlet Filters. Could these be just hidden somehow? Don't really think so. The Interceptors I suggested wouldn't be related to any AOP framework out there, are simple and effective. If we allow containers to implement instance level security, well, welcome to the non-portable world. Even if we wanted it, it is hard to support the kind of flexibility I mentioned - how would your _end user_ be able to change the rules dynamic? What if you are selling a product that should be deployed anywhere? Your application wouldn't be really secure if your session beans were doing the security logic. Anyone could call your Entity directly without any check. Take a more careful look at what I suggested.
  26. Cedric, check out what we've done with XWork (http://wiki.opensymphony.com/space/XWork). We've added exactly these types of interceptors in the call stack. The classic interceptors which are already applied are security, transactions, etc. Make them pluggable (so I can have my own security interceptor which hooks into my security framework which is based on some long forgotten mainframe system, etc.).

    This allows real power in the J2EE spec.
  27. Meaningful names for commit options[ Go to top ]

    I would change this comment to: Meaningful commit options.

    The names are not the only problems the options themselves are close to useless and render the concept of having entity beans as shared objects impossible (always refresh the cache, never refresh the cache come on!). Mark Fluery of JBoss makes some good comments about this in his "Blue" paper http://www.jboss.org/blue.pdf

    Most of the major vendors give you some more useful options, however the nature and behavior of your cache significantly affect your application design. If you make use of such features you depend on them behaving a certain way, welcome (back) to vendor lock-in land!
  28. If you make use of such features you depend on them behaving a certain way, welcome (back) to vendor lock-in land!


    Unfortunately, today it is pretty hard to write an application that doesn't depend on *any* app server specifics. If you try to do it, you come up with code you weren't supposed to be writing - that's why we have a spec and an implementation -, that is difficult to write, debug, mantain and that is error-prone. That is just what they promised us we wouln't be doing anymore... :-)
  29. Threads
    I am also for including a facility such as a thread pool to lookup like a DataSource. There have been numerous times when I have wished I could launch a thread or two from my beans and I suspect I'm not the only one.

    File system access
    It would be useful to have a standard interface for getting (read and write) access to the file system from EJBs.

    Nested transactions
    The 2.0 spec rejected nested transactions because not enough existing database/TP vendors supported them. I don't know if that's changed but it would be nice to have at least optional support for them.
  30. Threads

    > I am also for including a facility such as a thread pool to lookup like a DataSource. There have been numerous times when I have wished I could launch a thread or two from my beans and I suspect I'm not the only one.

    I couldn't agree more :-)

    > File system access
    > It would be useful to have a standard interface for getting (read and write) access to the file system from EJBs.

    Well, that's something hard to do. What if your application is running in a clustered environment? If your application depends on a file which is in a single machine, your whole cluster may go down if it fails - back to the single point of failure problem. If you want to replicate the files you need, what happens if the replication process fails? Also, there is the waiting time problem. File systems may slow down at any moment and your transactions may roll back. It is too complicated, I think. If your problem is access to static files - that are not going to be changed after you read them once, it is totally different.

    > Nested transactions
    > The 2.0 spec rejected nested transactions because not enough existing database/TP vendors supported them. I don't know if that's changed but it would be nice to have at least optional support for them.

    I agree.
  31. Lasse said:
    It would be useful to have a standard interface for getting (read and write) access to the file system from EJBs.

    Michael responded:
    Well, that's something hard to do. What if your application is running in a clustered environment? If your application depends on a file which is in a single machine, your whole cluster may go down if it fails - back to the single point of failure problem. If you want to replicate the files you need, what happens if the replication process fails? Also, there is the waiting time problem. File systems may slow down at any moment and your transactions may roll back. It is too complicated, I think. If your problem is access to static files - that are not going to be changed after you read them once, it is totally different.

    True, it's hard and the performance can vary from acceptable to snail-motion. Yet I would like to have that capability. It can't be technically that difficult to add file replication to an existing cluster solution if latency can be accepted as the norm rather than an exception. Anyway, the file system wouldn't need to be everything from the root up. It could be any configured part of the file system. Furthermore, the replication strategy could be configurable just as a caching strategy or database locking strategy. Explicitly configuring a timeout for the "FileSource" could help alleviate the pain caused by a file that is not yet on this server instance.

    Your comment about file systems slowing down at any moment is true but I think you are forgetting that JDBC connections to a dedicated database server can be just as bad. You never know when your network goes down for some extraterrestrial reason even in a top-dollar dedicated hosting environment, unfortunately.

    Having that said, I am also very suspicious about ever seeing this happen. But it's still a nice dream :)
  32. Having that said, I am also very suspicious about ever seeing this happen. But it's still a nice dream :)


    OK, got your point now. But the problem is more complex than I thought when I read your message. What if you have a cluster with different OSes running on each machine? It is possible and I have seen it more than once.

    Anyway, as I originally blogged, the important thing is to send your suggestions to Linda. I can't change the spec myself, but she can :-)
  33. <Binil>
    I have been using MDB in many of my works. But the main problem I faced is if I have two MDB instances doing parallel tasks, there is no (or perhaps I dont know) STANDARD, EFFECTIVE way to "join" these two instances just like we do Thread.join(). I am fully reluctant to use any busy wait or polling (which again depends on busy wait) from within the App Server components, which means, I am practically constrained by the inability to split my processing into parallel branches (where the branches need to join at the end) using MDBs.

    Dont know whether this would be addressed by any/similar/some of the following suggestions:

    1. Annotate the MDBs which needs to be joined in a Transaction context
    2. A standard Thread API which we can use from within EJB tier, which will expose something similar to join() and join(long millis)
    </Binil>
  34. 1. Annotate the MDBs which needs to be joined in a Transaction context

    There is no transaction context propagation for MDBs and I think it makes sense.

    2. A standard Thread API which we can use from within EJB tier, which will expose something similar to join() and join(long millis)

    I think it is really a threading issue. To me, it just looks like you are using MDBs to doing something the spec doesn't allow today: multithreading. So, I think I go with number 3:

    3. Adding threading support to J2EE.

    :-)
  35. Use MDB's wisely[ Go to top ]

    Binil:
    I have been using MDB in many of my works. But the main problem I faced is if I have two MDB instances doing parallel tasks, there is no (or perhaps I dont know) STANDARD, EFFECTIVE way to "join" these two instances just like we do Thread.join().


    You are using MDB's for the wrong purpose. You can't even be sure a message will reach your MDB, why would you want to perform a join on them? Do you realize how fragile that is?

    I suggest stateless session beans with a simple rendezvous scheme.

    --
    Cedric
    http://beust.com/weblog
  36. Use MDB's wisely[ Go to top ]

    <Binil>
    Yes, I agree. I dont mean to say that I have been using MDB "for above purpose". What I'd like to have is very simple: A way to do threading from within EJB components. I agree that J2EE has made life cool, by taking away all complexities from developers. But, I think it shouldn't end up in limiting the developer's ability to do something.

    Regarding the second issue of Guaranteed Message Delivery for MDBs - I hope it could be guaranteed if we can propogate the Sender's TX context to the JMS provider, and then by using Persistant queues (Of course it is for message delivery only, not to propogate TX to MDB which acts on the delivered message, as Michael Santos pointed out).

    As a last note, I agree very much that MDB is a means to process asynchronously, and not for doing parallel tasks.

    Now, if I have to do some parallel tasks from within EJB, and the main process needs to wait till all the parallel tasks are completed, could someone tell me a solution (not violating the specs and not vendor dependent)

    :-(
    </Binil>
  37. WebSphere Enterprise Async Beans[ Go to top ]

    WAS 5.0 E has full J2EE threading support for applications using the async beans APIs. These offer a complete set of APIs for developing J2EE applications, servlets or EJBs that can take advantage of threads. The APIs provides safe threads (short duration and daemon threads), asynchronous events between threads and safe managed transient scoped timers. The combination of basic threading, events and alarms allows very sophisticated applications to be built that can take advantage of SMP boxes as well as be used to use advanced integration patterns such as dynamic MDBs, integrating products such as Tibco RV etc easily.

    For more information, check out the info center.

    Billy
    WAS-E Architect, IBM.
  38. WAS 5.0 E has full J2EE threading support for applications using the async beans APIs.


    I was aware of that and I am pretty happy some vendors recognize J2EE threading as a real world need and include proprietary solutions for that issue. However, I think this it is such a crucial feature we should have it standardized as part of the spec.
  39. A few comments ...


    > Threads
    > I am also for including a facility such as a thread pool to lookup like a DataSource. There have been numerous times when I have wished I could launch a thread or two from my beans and I suspect I'm not the only one.

    I agree that it is necessary to move beyond EJBs as passive/reactive elements. However the introduction of such active components would need to be at a much higher level of abstraction that a 'thread'. Right now we have the Timer component (periodic activity) and the MDBean (event driven).

    What is required is the introduction of the notion of Agent/Worker beans.

    >
    > File system access
    > It would be useful to have a standard interface for getting (read and write) access to the file system from EJBs.

    This is already addressed by J2EE specifications. (You may wish to review the Connector spec.)

    So what is needed is a standard "application contract" (using the terminology of the connector spec.) for (Enterprise) File Systems.


    Peace.
  40. File system access[ Go to top ]

    File system access

    > > It would be useful to have a standard interface for getting (read and write)
    > > access to the file system from EJBs.

    > This is already addressed by J2EE specifications. (You may wish to review the
    > Connector spec.)
    >
    > So what is needed is a standard "application contract" (using the terminology
    > of the connector spec.) for (Enterprise) File Systems.

    Exactly. Whether the "standard interface" is based on JCA or something else, we need something _standard_.
  41. Paging Concepts in EJB[ Go to top ]

    It's a good idea to have paging concepts in EJB. Instead of going for custom implementations for Paging we can follow the standard procedure. That would really play a vital role in the EJB spec, if that's there.
  42. Instance level EJB Security[ Go to top ]

    At the simplest level, all you need is the ability to apply security with expression language qualifiers.

          <method-permission>
               <role-name>Teller</role-name>
               <method>
                   <ejb-name>AccountService</ejb-name>
                   <method-name>transfer</method-name>
                   <method-qualifier><![CDATA[amount < 10000]]></method-qualifier>
               </method>
           </method-permission>

    This would allow you to set security constraints based on the instance values. This could just as easily be applied to entity EJB's properties.
  43. At the simplest level, all you need is the ability to apply security with expression language qualifiers.

    >
    >       <method-permission>
    >            <role-name>Teller</role-name>
    >            <method>
    >                <ejb-name>AccountService</ejb-name>
    >                <method-name>transfer</method-name>
    >                <method-qualifier><![CDATA[amount < 10000]]></method-qualifier>
    >            </method>
    >        </method-permission>
    >

    Jason,

    You showed us a solution that is too narrow to the scope of problem I was talking about. You ignored the fact that values and groups may change at any time. So, we got back to the static problem of declarative security. Instance-based security should be dynamic, not a part of the deployment descriptor; otherwise, we would be limiting ourselves unnecessarily.
  44. Jason,

    >
    > You showed us a solution that is too narrow to the scope of problem I was
    > talking about. You ignored the fact that values and groups may change at any
    > time. So, we got back to the static problem of declarative security.
    > Instance-based security should be dynamic, not a part of the deployment
    > descriptor; otherwise, we would be limiting ourselves unnecessarily.

    I disagree... For the most part these rules will be set in stone (or a business rules engine, but that's another story) and won't want to be changed on the fly. What I showed was something relatively easy to implement based on what's there now. For something on-the-fly you could make the EL able to call out to static methods (or methods on the instance) which could access on-the-fly information, etc. It's not to far a jump, and, given an implementation as it stands now of a security interceptor and a quick download of OGNL I could have this added in a matter of hours. It's not that much of a leap, and would add most everything you're asking for. Check out the XWork validation framework I built. It does this type of thing pretty easily with the ExpressionValidator.
  45. EJB new features[ Go to top ]

    Just some comments :

    I am glad to see your energy. You are pushing valuable suggestions to EJB spec. But IMHO EJB spec will grow (in scope) much slower that we would like. There are many political and comercial concerns to be considered. Big vendors have much more influence than us, mere developers fighting to deliver projects on budget and on time. Sometimes may be they want to keep feature X out of the spec just because they want to deliver their own proprietary implementation so in this way they have some diferential do sell... (see the impressive WAS 5 feature list and IBM "extensions to J2EE"). The business rules, again...

    Anyway, we will keep using J2EE for many years (including EJB) but from my personal experience I really don't care about EJB roadmap anymore. In fact, it´s the most controversial J2EE piece, (see O/R mapping X JDO X CMP endless war) and it does not matter for many projects I worked in, even for really big corporates.

    For example, I just finished a small project with a couple of persistence beans using plain J2EE patterns and a smart JDBC framework to handle up to 800 concurrent users ! (mostly 600). We just need a Web Container so we are using Tomcat. The client is a big blue customer, but doesn´t have enought budget to buy WAS for this project - btw the client its from a government sector.

    Not to mention that JSP and Servlets applications has growing much faster than EJB apps. So as a developer, I prefeer to keep focusing in frameworks and tools like Spring, Hibernate, iBatis (for legacy SQL), WebWork2, XWorks, PushToTest, etc. If the project´s stakeholder want (and you know it's happen every day) to deploy the app in Tomcat or in a big WAS cluster, not problem ! The developers can still keep focused in funcionality, develop and test in their desktops (not a powerful server) and the architect (myself in many cases) will easily map these implementations to any J2EE container that supports the architecture (security, scalability, fault tolerance, etc) requirements.

    Conclusion : J2EE is great, but we can't expect J2EE to solve all development problems, witch will be delivered by custom vendors, be commercial or open source. And it´s great, think how can you be creative if all you have to do is follow specs for everything..

    Let's improve current J2EE specs but let it as generic as possible, please !!

    Cheers

    Rodolfo
  46. Another point to mention: CMP Entities are still unusable for large transactions like imports or &quot;Batchjobs&quot;. Any Entity which is part of a Transaction can't be passivated. So if you make eg. a Billingjob running through thousands of Orders and create 100K of Enititys ( Orderlines, Accountinformation etc) all of them have to stay in memory - and believe me, 4 GB are reached quickly and NOBODY wants to see a JVM swapping :-).

    This is a major drawback since you have to fall back to traditional SQL/JDBC instead of using your businesslogic in your Beans (Session and Entity).

    And it would be easy to fix; you could also passivate newly created Entities as there state can be reloaded from Database even if not yet commited. I dunno why this is so :-(
  47. "Another point to mention: CMP Entities are still unusable for large transactions like imports or &quot;Batchjobs&quot;. Any Entity which is part of a Transaction can't be passivated. So if you make eg. a Billingjob running through thousands of Orders and create 100K of Enititys ( Orderlines, Accountinformation etc) all of them have to stay in memory - and believe me, 4 GB are reached quickly and NOBODY wants to see a JVM swapping :-)."

    This is not true. Borland's application server provides a transaction windowing mechanism which can be configured for particular beans, especially when they are accessed in a read-only manner for a 'large' transaction. I am sure BEA has something similiar in their persistence engine as most appservers copy feature for feature from each other.

    That said do you consider it appropriate to have such a large amount of data accessed and possibly updated in a single transaction. No transaction chopping?

    I have worked on various GSM billing engines and do not ever recall the need to have a batch, in the order of 100,000 accounts, run in a single transaction. of course I am not saying that a billing engine should be written using EJB technology. It can be done but we would need to trade off the slight,;-), performance issue with an engineering benefit derived from promoting the domain object to a component such as extensibility and customization.

    Regards,

    William Louth
    JDBInsight Product Architect
    www.jinspired.com
  48. Thomas:
    And it would be easy to fix; you could also passivate newly created Entities as there state can be reloaded from Database even if not yet commited.


    And how passivating Entity beans would be different from swapping pages belonging to the JVM?!?

    The solution is not passivating Entity beans, it's providing scrollable result sets so that even if you activate 100k of Entity beans, the state they contain is limited to only what your application needs at a point in time.

    --
    Cedric
    http://beust.com/weblog
  49. New security feature in J2EE 1.4[ Go to top ]

    Please note that at least some of the security features you are looking for became a standard part of the J2EE 1.4 platform (i.e EJB 2.1 and Servlet 2.4) as a result of the addtion of the Java Authorization Contract for Containers as a required element of all J2EE 1.4 Compatible containers.

    You can find the (PFD) of the Java Authorization Contract for Containers
    specifcation at: http://java.sun.com/j2ee/javaacc

    At a high level, the contract requires that all J2ee 1.4 (and beyond) containers
    perform their access decisions by interacting with the J2SE Policy decision
    interface (i.e. java.security.Policy) which is a replacability (or to use
    your term, interception) point in the 1.4 JRE.

    The contract also defines standard callbacks that authorization policy modules can use to obtain additional (including instance specific) context from the container. The contract also defines java.security.permission objects to represent the permissions tested by containers and per application policy
    scoping mechanisms to support application isolation.

    The dynamic aspects of policy were left to be encapsulated within the policy provider which could in affect be a bridge between the container policy enforcement machinery and external policy decision infrastructure.

    The intent is to preserve the stable declarative role based permission model (which maximizes application portability) while also qualifying the determination of subject in role based on additional context relating to the invocation. For example, you need to be in role owner to access your bank account, but who is in role owner depends on the additional context of what bank account you are talking about.

    On the point of integration and bridging, folks here at Sunvare working to develop bridges to xacml policy providers capable of performing dynamic policy decisions. As a result of the the container authorization contract, such opportunities are available to anyone who can implement a Policy module.

    On the point about access to the subject, the EE container authorization contract
    requires containers to associate a java.security.AccessControlContext with the call thread before dispatching to a component. Thus the subject under whose identity the component is available to the component using standard java security interfaces.
     
    I hope you find this information helpful, and if you have any other questions, or concerns, send them to me and I'll do my best to answer them.

    Ron
  50. Enhancment of EJBQL[ Go to top ]

    EJBQL is not proper for complex queries, queries which need to be dynamicly constructed at runtime (according to user input, ...) because it is hardcoded in the xml file and cannot be changed at runtime.
    A good solution is to place EJBQL in the code instead of XML file
    for example:

    An EJBQL in a select method (not in xml file):
    public collection ejbSelectExample(){
    IF
      (a>0) SELECT object o from Book o;
    else
     {
     SELECT object o from Author o
      }
      return result;
    }
    and the delpoyed code would be:
    String sql;
    if(a>0) sql = "SELECT * from Table BOOK";
    if(a<0) sql = "SELECT * from Table AUTHOR";
    ....
  51. Enhancement of EJBQL[ Go to top ]

    Pasha:
    A good solution is to place EJBQL in the code instead of XML file


    True, which is why we offer two ways to approach this problem with WebLogic Server:

    - EJBGen, which allows you to specify the static EJB QL above your finder/select declaration in metadata

    - Dynamic queries, which allow you to compose EJB QL queries at runtime.

    --
    Cedric
    http://beust.com/weblog
  52. head aches of developers[ Go to top ]

    Hi..
    i been quiet out of EJB for while coz .(Not in eJB pjt now..)
    but pretty happy see the sparking of 3.0 spec..

    I think most imp problem in j2ee is always related 2 DB related stuff

    what i feel is it would be cool if some interface is defined
    which can guide developer to write query (Having bit of it in EJBQL..may be the static part)and way to provide a dyanmic part also like a where, having ,grp by or thing relating CUD...(factory type stuff)which should strong enough for most wanted queries.

    The pagination part is another intresting thing....but shd we provide it as part of EJB is greasy question.

    One more thing i would like to have in 3.0 is a testing frame work build in
    EJB spec it self so that while wrting the EJB user is forced to write the testing stuff also so that most of head ache is over..

    may be over used or Over protected features are not what end business man need
    but what can bring in business in less time and error free solutions...

    in most development effort ( i think ard 65 %) development is wrapper over existing system ( may be contaminated by limtations of some senior (old) tech..
    so plz do suggest keeping all this stuffs in mind..

    Manu.M.R
    SA
  53. I think most of these suggested improvements to the EJB specification are best addressed at the container provider level (i.e. new/enhanced SPIs), and a serious re-evaluation of DDs and interfaces to dynamically manipulate the DD.

    J2EE/EJB is a Component Framework, with customization at the deployment stage.

    Analogous to the notion of write-once, run-anywhere in context of Java objects, is the notion of write-once, deploy-again & again for Java Components (aka EJBs).

    That is the motivation behind EJBs. The EJB specification does NOT defining an application development framework. (It was never supposed to.)

    All of your suggestions are, however, best suited to an application development framework, and if implemented, would definitely preclude 'WODA+' from becoming a reality.

    J2EE (and specialy the EJB) specs, unlike an application development framework specification, are focused on articulating the necessary boundaries between various layers (& aspects) of an object based system to facilitate the creation of custom enterprise applications using off the shelf components.

    And there ain't no way you can write 'off the shelf' components if you are going to be concerned with application specific information inside your EJB method bodies.


    > Access to the actual Subject returned by the JAAS login mechanism: OK, we can use JAAS in J2EE. JAAS is great, because it gives you enormous flexibility regarding login mechanisms, credentials, principals etc. But how is it supposed to be useful if you can't access the credentials and principals after you have authenticated the user? That's how it works now. Hope it changes, really.

    Your line of thinking is characteristic of an application developer.

    A component developer, on the other hand, is concerned with standard (or minimally well understood) entities, relationships, and semantics within a given domain.

    And the EJB spec was written for Component developers and component users.

    > Instance-based security: I've never been able to make any meaningful
    use of the security features provided by the current EJB spec. It is impossible to do it if your only option is declarative security - and I am not using it in the sense the spec uses it, but I am referring to static security. You need to be able to restrict access based on what values instance properties hold. That is how real world systems work. Interceptors - or advices - would be a good way of implementing this.
    >

    I believe the reason for your inability to make 'meaningful' use of these features is that you use EJBs to write applications. (You think like an application developer.)

    Start thinking like a component developer or architect & you may see quite a few 'meaningful' uses for EJB security mechanism.


    > Dynamic security: In real world enterprise systems, there is no such thing as this role will access these functionalities. Users want to define new roles and new security mappings without having to call the developers and redeploying the application. It is a fact and it is reasonable, but not supported by the current spec. It should be.

    Is that so?

    The whole point of 'security' is to establish (relatively) centralized and authoritative constraints. The notion of users defining roles on the fly is analogous to workers in an enterprise devising (functional) positions at their own whim.

    "Hey, I wanna be the CEO now!".
    "Hey, I feel like granting myself TOP SECRET clearance!"

    And that, sadly, is just not the way this bad world works :)

    Again, a component developer is delighted to know that with EJBs, s/he can design a suite of components performing domain specific tasks, and implement a security regime using well established (and finite) set of 'roles' of the given domain.

    Certainly it is quite realistic to expect that a given user with in a domain can have a multiplicity of roles. But it is neither realistic, nor desirable, for users to elect to define brand new roles in a given (business) context.

    >
    > Paging facilities: If your application server does a good job when it comes to its CMP engine implementation, then probably the only JDBC code you have to write for your application is in order to provide paging facilities. If that's so, why don't we have paging facilities as part of the spec? Why aren't they supported? A solution would be to have finders that return Lists. Then, you would be able to take a slice of it and your container would know you are going to use only this little piece. So, it could load a page, instead of the whole Collection.

    Again, see the general comment above.

    You know, the idea behind EJBs was that many entry level developers would fleshout the bones designed by a few expert component designers, and then put their product (components) on a shelf to be picked up and wired together as an application by deplyers under the guidance of a few expert architects.

    (A nice division of labor which (frankly) also quite nicely maps to the reality of the distribution of programming/design/conceptual skills in the developer community at large -- a broad base, and spectacularly pointy peaks ;)

    And that is why J2EE is a (s)mothering framework. (And rightly so, if one accepts the motivation behind this architecture.)

    And exposing 'paging' meachanims, threading decisions, etc., to the Bean developer pretty much makes that goal an impossibility. (And transforms EJB containers from a highly constrained programming environment to a very promiscuous one.)


    > Threading facilities: If know something about the EJB 2.1 draft spec, you may argue that we already have these as Timers. Really? Don't think so. Take a look at the latest proposed final draft for the JCA new spec. That's support for multithreading! We should have some kind of thread pool provided by the container or a Work-like interface. Linda didn't quite like this suggestion, though. What do you think?
    >

    (Answered in my prior post in this topic).


    In general, I think what is needed is not yet more complex EJB spec., but a great effort to provide the facilities that would make the projected seperation of concerns (e.g. developers, depolyers, etc.) a practical reality.

    That is what is missing in the J2EE/EJB specs/space.


    Peace.
  54. Joubin,

    > J2EE/EJB is a Component Framework, with customization at the deployment stage.

    *EJB* is such a Component Framework. J2EE specifies all kinds of container services that are perfectly usable without a middle tier component framework.
     
    > That is the motivation behind EJBs. The EJB specification does NOT defining an application development framework. (It was never supposed to.)

    > And there ain't no way you can write 'off the shelf' components if you are going to be concerned with application specific information inside your EJB method bodies.
     
    That's an interesting point. Indeed, EJB was originally intended for an off-the-shelf component market that never lifted off. Flashline is history, and to the best of my knowledge, there isn't any such market today.

    Most kinds of developers use EJB where an application framework like the Spring Framework would be much more appropriate. For example, if you'd like to leverage declarative transactions within your application, choosing local Stateless Session Beans gets you involved in all that component deployment stuff that you don't get any benefit from - as you don't need *components*.
     
    > The whole point of 'security' is to establish (relatively) centralized and authoritative constraints.

    > Certainly it is quite realistic to expect that a given user with in a domain can have a multiplicity of roles. But it is neither realistic, nor desirable, for users to elect to define brand new roles in a given (business) context.

    Not users themselves, but *administrator* users that want to this on the fly without any redeployment or restarting. But again, you're right that this doesn't matter for components but just for application objects. EJB just isn't meant for application services.

    > You know, the idea behind EJBs was that many entry level developers would fleshout the bones designed by a few expert component designers, and then put their product (components) on a shelf to be picked up and wired together as an application by deplyers under the guidance of a few expert architects.

    Unfortunately, that doesn't match typical development styles. If one just wants to create an application with a bunch of developers, then a component model that assumes all those roles like "component developers" and "application deployers" is complete overkill. You can achieve proper layering, loosely coupled services, a high degree of reusability, etc in much simpler ways.

    > In general, I think what is needed is not yet more complex EJB spec., but a great effort to provide the facilities that would make the projected seperation of concerns (e.g. developers, depolyers, etc.) a practical reality.

    Agreed, noone needs an even more complex EJB spec. I'd really like to see that Entity Beans get deprecated in one way or the other, instead of adding more and more bloat in each revision. They were meant as "persistent components", a completely different league than integrated POJO persistence like with Hibernate or JDO. The idea just hasn't worked out.

    I don't mind facilities for separation of roles, but only if the marketing machineries switch from "you want to develop a serious J2EE app? then you need EJB in any case" to "J2EE without EJB is a perfectly viable choice for small to mid-sized development teams" and "choose EJB if you need separately deployable components - live happily without it otherwise".

    Juergen
  55. <quote>
    I don't mind facilities for separation of roles, but only if the marketing machineries switch from "you want to develop a serious J2EE app? then you need EJB in any case" to "J2EE without EJB is a perfectly viable choice for small to mid-sized development teams" and "choose EJB if you need separately deployable components - live happily without it otherwise".
    </quote>

    Separately deployable components (presentation and business components) are a good practice, IMO. This "physical" separation helps many developers to stricly divide the work of each layer. Surely a "logical" separation would be enough in many cases as you said. IMO, it's not about the size of the development team or the size of the application. It's about the long term target of your project whether you would choose to use EJB or not. Choose EJB if you want to offer standardized reusable components, which can be deployed phisically and logically separated from the presentation layer.

    Regards,
    Lofi.
  56. It's about the long term target of your project whether you would choose to use EJB or not. Choose EJB if you want to offer standardized reusable components, which can be deployed phisically and logically separated from the presentation layer.


    If there isn't any physical separation involved, EJB introduces a lot of unnecessary complexity, as it is designed for deployment of individual components. Considering the abundant use of EJBs in typical web apps that will never get physically separated, I wonder what the point of such purely local EJBs is. People seem to have misunderstood the intent of EJBs, applying them where they don't really fit - at least according to this line of thought.

    In the end, the rationale behind the introduction of local interfaces in EJB 2.0 was to enable local dependencies between Entity Beans. Local EJBs weren't intended for application objects that want to leverage declarative transactions locally within a web application or the like. Application frameworks with IoC and AOP support like the Spring Framework can offer a higher level of convenience for such local application objects, being designed for this.

    Even with distributed applications, it might make sense to just use EJB for remote facades, not for fine-grained business services. Remote Stateless Session Beans are a fine choice for this, and Remote Stateful Session Beans for certain cases too. Behind those facades, we're in the application domain again, where an application framework fits nicely. In many scenarios, there is simply no need for separately deployable components behind such facades.

    I believe that Local Session Beans are horrendously overused for applications that don't need such full components at all. As I said, local SLSBs just for the sake of declarative transactions is overkill. And frankly, I consider Entity Beans a failed expirement, as remote components by any means but also as local ones. They have been superseded by fine-grained POJO persistence tools, the segment where they actually deliver advantages is hard to find.

    With an appropriate application framework like the Spring Framework, EJB is essentially "yet another remoting mechanism", alongside Web Services and the like. Compared to the latter, it offers particular advantages like a well-defined transaction and authentication propagation mechanism. But locally within a container, a proper application framework can give you everything from application object lifecycle to declarative transactions in much simpler ways.

    Juergen
  57. EJB = Component[ Go to top ]

    I agree with most of your opinions.

    The main idea of EJB is actually to have components to be reused. Optimally they should be "black-box" reusable. Until now I always try to reuse every single OSS components (especially EJB) available on the market in my project. Problems I face are normally:

    - Many EJBs are very tight to their own user management and security. Normally you have already your own user and security management, so you don't need them again. It's very difficult to reuse them in black-box style. Writing EJBs for reuse and no-reuse is a different task, IMO. And most of EJBs (at least in Open Source Software) are just written for "one" application and not for reuse.
    - Many EJB applications are using their own framework and using their own directory structure, which make the black-box reuse harder.

    In many cases I end up with:
    - Business Objects, Entities: inheritance (white-box) and composition (black-box) reuse of those EJBs by writing "entities glue" EJBs to my application.
    - Workflow Objects, Sessions: inheritance (white-box) and rewrite/overwrite (no reuse) by writing "sessions glue" EJBs to my application.

    As the domain-sensitive layered software architecture tells you: on the top of the pyramid where the domain is very specific, it is harder to reuse.

    I think it would be nice if EJB spec also gives some recommendations to the developers ("developer role") how they should write EJBs for reuse and not only for their one and only application.

    Best regards,
    Lofi.
    http://www.openuss.org
  58. EJB = Component[ Go to top ]

    The main idea of EJB is actually to have components to be reused. Optimally they should be "black-box" reusable.


    Right. The conceptual model fits within a paradigm that I call 'Black Boxes, Blue Sky'.


    > I think it would be nice if EJB spec also gives some recommendations to the developers ("developer role") how they should write EJBs for reuse and not only for their one and only application.

    (It's about time, isn't it? :)

    There is a fundamental disconnect between the creators of J2EE architecture and their client community (vendors, developers, etc.).

    This disconnect is entirely pedagogical, and the fact of its existence is demonstrated simply by reviewing the comments on this topic.

    > Lofi.

    Best regards,

    Peace.
  59. All of your suggestions are, however, best suited to an application development framework, and if implemented, would definitely preclude 'WODA+' from becoming a reality.

    Not really. Most of them - except for threads and paging - should be implemented using other components which could be assembled together at deployment time. If you see my proposed solution - interceptors - they are just that. Components that intercept calls to components.

    And there ain't no way you can write 'off the shelf' components if you are going to be concerned with application specific information inside your EJB method bodies.

    There is no need for it as I said above.


    Access to the actual Subject returned by the JAAS login mechanism: OK, we can use JAAS in J2EE. JAAS is great, because it gives you enormous flexibility regarding login mechanisms, credentials, principals etc. But how is it supposed to be useful if you can't access the credentials and principals after you have authenticated the user? That's how it works now. Hope it changes, really.
    Your line of thinking is characteristic of an application developer.


    Yes, as I am an architect, component and application developer.

    A component developer, on the other hand, is concerned with standard (or minimally well understood) entities, relationships, and semantics within a given domain.

    Security is a domain security component developers are concerned about. So I think you aren't able to follow my line of thought

    And the EJB spec was written for Component developers and component users.

    That is why it should provide better support for security in component development. That is an area of concern. If you think we souldn't be concerned about security as component developers - and we have access to it through the current API, what means the expert group thought we may be concerned about them -, well, let's take the whole security section out of the spec.

    Instance-based security: I've never been able to make any meaningful
    use of the security features provided by the current EJB spec. It is impossible to do it if your only option is declarative security - and I am not using it in the sense the spec uses it, but I am referring to static security. You need to be able to restrict access based on what values instance properties hold. That is how real world systems work. Interceptors - or advices - would be a good way of implementing this.
    I believe the reason for your inability to make 'meaningful' use of these features is that you use EJBs to write applications. (You think like an application developer.)

    Not true. I've already developed components for other consumers not myself - and I mean reusable ones - and it was necessary. What I did was to define an interface you should implement and pass to the bean constructor so that I could delegate to your component my security decisions before making the call. If EJB had facilities for that, it wouldn't be necessary. My solution was ugly and wasn't really secure, but that's what the EJB spec allows me to do right now.

    Start thinking like a component developer or architect & you may see quite a few 'meaningful' uses for EJB security mechanism.

    Yep. For blueprint, academic, fictious applications and business that have been the same for ages. At least, these are not my clients.

    Dynamic security: In real world enterprise systems, there is no such thing as this role will access these functionalities. Users want to define new roles and new security mappings without having to call the developers and redeploying the application. It is a fact and it is reasonable, but not supported by the current spec. It should be.

    Is that so?


    Definetely.
     
    The whole point of 'security' is to establish (relatively) centralized and authoritative constraints. The notion of users defining roles on the fly is analogous to workers in an enterprise devising (functional) positions at their own whim.

    "Hey, I wanna be the CEO now!".
    "Hey, I feel like granting myself TOP SECRET clearance!"



    Well, let's get back to your point which is all about component development. If I am developing a component someone else is going to use to build their application, I don't know which possible roles this someone else will need for their application and if these are going to vary or not. And yes, users want to create roles dynamically and I am tired of doing or telling the developers to use app server specific features or inventing YASF (yet-another-security-framework). That's what the spec is supposed to solve.
     
    And that, sadly, is just not the way this bad world works :)

    Yes, it is.

    Again, a component developer is delighted to know that with EJBs, s/he can design a suite of components performing domain specific tasks, and implement a security regime using well established (and finite) set of 'roles' of the given domain.

    Certainly it is quite realistic to expect that a given user with in a domain can have a multiplicity of roles. But it is neither realistic, nor desirable, for users to elect to define brand new roles in a given (business) context.


    Well, I can remember right now more than 20 applications I developed users needed to do so. Quite a realistic count to me :-P

    Paging facilities: If your application server does a good job when it comes to its CMP engine implementation, then probably the only JDBC code you have to write for your application is in order to provide paging facilities. If that's so, why don't we have paging facilities as part of the spec? Why aren't they supported? A solution would be to have finders that return Lists. Then, you would be able to take a slice of it and your container would know you are going to use only this little piece. So, it could load a page, instead of the whole Collection.

    Again, see the general comment above.

    You know, the idea behind EJBs was that many entry level developers would fleshout the bones designed by a few expert component designers, and then put their product (components) on a shelf to be picked up and wired together as an application by deplyers under the guidance of a few expert architects.
     
    (A nice division of labor which (frankly) also quite nicely maps to the reality of the distribution of programming/design/conceptual skills in the developer community at large -- a broad base, and spectacularly pointy peaks ;)
     
    And that is why J2EE is a (s)mothering framework. (And rightly so, if one accepts the motivation behind this architecture.)
     
    And exposing 'paging' meachanims, threading decisions, etc., to the Bean developer pretty much makes that goal an impossibility. (And transforms EJB containers from a highly constrained programming environment to a very promiscuous one.)


    Well, if you think the EJB spec shouldn't allow you to write components that perform fast, ok. The best way to implement paging is to have it built into the container. And, for your components to be WORA, paging facilities must be standard, not vendor-specific. Same about threading. Using your line of thought, how do you want to have WORA if you need to change your code so that it performs???

    In general, I think what is needed is not yet more complex EJB spec., but a great effort to provide the facilities that would make the projected seperation of concerns (e.g. developers, depolyers, etc.) a practical reality.

    I don't want a more complex spec, all I want is a spec that makes it easier for developers to write EJB components that work and perform well.