Hi,
> Hey
>
> Peter Michael wrote:
> > Yes, of course. You make an async call to an EJB. If the
> EJB does not return
> > anything, you are done. If the EJB need to return
> something, you specify an
> > return object in your async call to the EJB, which gets
> called by the EJB to
> > deliver return values. (Example: You have a call that take
> a long time. If
> > you
> > could send multiple returns, your client could display some
> results before
> > the
> > call is done as a whole.)
>
> But then your interface could look something like:
> public void doSomething(MyBean myCallBack)
> i.e. no return values, but the bean could send results to
> MyBean through
> the given callback.
>
> Could you please outline how a method with your design would look like
> and behave? Thanks.
>
Ok. Let's asume you have a bean that renders applies a filter to an image.
You
want to return parts the parts of the image that you already filtered. If
will also
include how is should behave if the call was canceled.
/* ATN: Simplified code */
public void filterImage( ImageClass image, FilterClass filter, AsyncCallback
callback ) {
[Set up your filter and your image]
for( int part = 0 ; part < maxParts ; part++ ) {
// if the call was cancled, return.
if( isCanceled() ) {
return;
}
// filter part of the image and get filtered part
ImageClass partialResult =
someInternalFilterMethod( image, filter,
(image.getHeight)/samevalue)*part );
// Send the filtered part of the back
// The boolean value in the call tells the client that there is more
to come
callback.sendResult( partialImage, ( part == maxParts -1 ) ? false :
true );
}
}
> > > > - It should be possible to cancel pending calls
> > > (for beans that
> > > > support this).
> > > > - It should be possible to suspend/resume calls
> > > (for beans that
> > > > support this), and
> > > > a bean may even be able to do this itself (i.e.
> > > suspend itself and
> > > > wake up when it
> > > > gets a message from JMS).
> > >
> > > Which problems would this solve?
> > > How would this work in reality? It would seem that re-entrancy is
> > > implied above.
> >
> > If you have a long running call, you might want to cancel
> it, because of
> > user action or other circumstances. Or you might want to
> suspend a call
> > because you have another call, which has a higher priority,
> but you don't
> > want to loose the results of your first call, which already
> ran for half an
> > hour. Re-entrancy is not an issue if you have a thread for
> each instance of
> > the bean. Cancel could be supported by having the bean
> check a isCanceled()
> > (as in Thread.isInterrupted()) periodically.
>
> I don't see why you need to change the spec to do this. It seems
Sorry? I really don't understand how. I don't think it is possible to
interrupt a ejb call once it's running. How can I unblock my thread in the
client? How can I implement different priorities without additions to
EJB? Please give me an example implementation that is able to do this.
> possible to do this today without additions to EJB. What part in your
> proposed EJB2.0 addition relies on the bean needing help from the
> container?
>
> >
> > >
> > > > - The caller should be able to wait for a
> return value and
> > > > optionally specify
> > > > a timeout.
> > >
> > > It can through transaction timeouts.
> >
> > A lot of things *could* be done with the current spec in
> one way or another,
> > the point is that you want to do this in an easy,
> convenient and consistent
> > way.
> > With async calls I only would have to make an getReply(
> long timeout) and
> > not
> > have to fiddle around with transactions, especially when I
> don't need a
> > transaction
> > for my call.
>
> Do you really want the container to be able to interrupt the bean
> whenever it feels like (because "best effort" would be the only likely
> possibility)? I sure don't.
See above. Interruption should be handled the way it is done with threads
in Java.
>
> > You might have a Singleton EJB that you want to inform if
> you timeout, but
> > not if you are being removed. There is a subtle difference
> between timing
> > out and being removed.
>
> I would imeplement the above with a stateless session bean. Why would
> you want a singleton EJB to do this instead of a Stateless SB?
Because your beans may reside in different containers on different JVMs
and maybe even different application servers!
>
> > > Sometimes it is not possible to get a list of instances.
> >
> > Why ?
>
> It might be possible to test for existance through
> findByPrimaryKey, but
> no complete "SELECT *" functionality is available in some cases. The
> object might even be created upon findByPrimaryKey, so it's not there
> until you ask for it.
>
But I should be able to get a list of running instances, don't I?
> > This is exactly the thing I don't want to do. If you have a
> large-scale
> > component-based
> > application, developed by a large team and additional component from
> > third-party vendors,
> > you want to invent thing yourself. You want to use
> functionality off the
> > shelf! If you
> > have, say, 50 EJBs running in multiple containers on
> multiple computers, you
> > need a
> > mechanism to determine if something goes wrong. And you
> don't want to do
> > this in your
> > client-code over and over (maybe you have no only one, but
> several different
> > clients, some
> > only using part of the application, some using the whole
> app) and you don't
> > want to
> > do this in your bean code over and over.
>
> Use code generation. Of course you don't do this kind of
> stuff over and
> over again. There's already a ton of stuff that I would want
> to automate
> through code generation; this is just one more thing to generate.
I think code generation cool, but what if you want to alter the code
once it has been generated (maybe in the next version of your app).
Then you would have to go through your app and change everything by
hand. Now take the above 50 EJBs. That would require a lot of time.
Apart from that, what you propagate here is code duplication, which
IMHO is never a good thing. Hard to maintain and error prone. I a
large development team there is always someone who changes the
generated code and all of a sudden strange effects happen. I would
be much more comfortable if there were one place where this
stuff is handled. If you want to use code generation a better way
would be aspect programming. See http://www.aspectj.org
>
> If you want I can do this kind of tool (using my CodeGen tool, see
> homepage, it would take about 30 minutes) and you can then use it "off
> the shelf" ;-)
>
> > Chaining statefull beans (as in the duke store) might not
> be a good idea as
> > someone
> > from the J2EE RI team admitted. There was a thread about
> > timeout objects on this list. The reason why I want to time
> > out multiple beans at the same time is simply consistency.
> > If one bean times out your app may be in an incosistent state.
> > Now if you had an error handler, it could send a message to your
> > client to inform it about this (Of course you could put this
> > code into each bean. Now that would be great idea!).
>
> How would you declare which beans should be grouped? How would this be
> implemented in an EJB server? Sometimes sending a message to
> a server is
> not very interesting (servlets are often clients).
I would like to group EJBs in my application descriptor. Group together
some EJBs and specify an error handler or error handling EJB. Would be
a nice and flexible solution. When I say client I don't have servlets in
mind, but Java clients, different components within your application and
maybe even components in different applications.
>
> > Where in an application do you use Singletons? Configuration, state
> > management, error management. There are a lot uses for singleton.
> > Sometimes you can simulate them with entity beans, but if you have
> > multiple containers on multiple JVM you are pretty much out of luck.
>
> I would probably simulate them with Stateless Session Beans in most
> cases. Or use RMI objects.
How would you simulate this across multiple examples. Could you give
an example? What do you mean by 'use RMI object'. You are not allowed
to use RMI from within an EJB due to the following restriction:
An enterprise bean must not attempt to listen on a socket, accept
connections on a socket, or use a socket for multicast.
(EJB 1.1 Spec 18.1.2)
>
> > > No you wouldn't. Since the underlying implementation would most
> > > certainly be transactionally aware an asynchronous invocation
> > > would only
> > > be propagated to the bean if the transaction as a whole
> > > commits, so the
> > > bean cannot throw any checked exceptions or return any
> return values.
> > > The only thing you can know right away is whether the
> call could be
> > > logged in the message queue.
> > >
> >
> > No. I would call this function with TX_NOT_SUPPORTED.
>
> But the problem is still that if you wait for exceptions or return
> values it's not asynchronous. It's synchronous (by definition).
That depends on how define asyncronicity.
a) You make your call and return. The call is than transported to the callee
in a differed thread. This is what JMS offers you.
b) You make your call and make sure it is delievered to callee, then you
return. The callee then processes you call and sends replies.
I would like to see both behaviors for async EJB calls.
Of course, you could simulate the second behavior with JMS by sending
an acknowledge, but what do you do when you communication partner is not
there? To make my point more clear, let me give you a little comparison:
An async call resembles the following. You want to send a note to someone.
Now you give your note to a messager, who delivers to note for you. When
your recipient is not available, your messager comes back to you to tell
you that he could not deliver your note.
Messaging is more like this. You have note for someone. Now you shout his
name into a crowd. If he answers everything is fine, you give him the note.
If nobody answers, the only thing you can do is wait. Which maybe not the
behavior you want.
>
> > > Suggestions are good, but IMHO you haven't quite thought
> through the
> > > consequences of your wishes. Please clarify where appropriate.
> >
> > All these are real world requirement. They come from very
> large-scale
> > (== hundreds of thousands of lines of code+, 100+ people development
> > teams, multiple years of development) projects, real enterprise
> > applications. When people talk of J2EE, they seems to talk about
> > Java 2 eCommerce Edition (or Java 2 Internet Edition as someone
> > called it here). All I hear is online stores, online stores, online
> > stores (especially if you look at the website of application server
> > vendors). I'm not interested in online stores or eCommerce at all.
> > All the changes I proposed have been used for a long time or have
> > been recognized to make development and maintaining large-scale
> > applications easier. The point is not so much if you could
> do it with
> > the current spec, but how easy, convenient and consistent it is.
> > All your concerns are valid as long as you only want to
> build relativly
> > small applications like online-stores or information
> systems, which seems
> > to be the focus of J2EE right now. But once you start
> building larger
> > applications, the things I mentioned here really start to
> make sense.
>
> The requirements are definitely real-world, no argument there, but I
> don't agree that your proposals make sense in the EJB spec.
> All of them
> can easily be put on top.
If I start to build frameworks on top of EJB/J2EE on top, why would I use
EJB/J2EE in the first place? I could start writing my own spec and build my
own container, but that's not something I want to do. I want EJB and J2EE to
deliver me the functionality that I need to write advanced enterprise
applications.
Just give us users the technology and let us decide what we need.
>
> The key question is whether any of your changes require the contract
> between the container and the bean to be changed. I don't
> think it have
> to do this for most of your suggestions.
Again, I beg to differ. If it makes the life of hundreds of developers
easier:
Put it in the spec. Why are there collection classes in Java? Every one of
us
could make his own. But they really improve the productivity, that's why
they
are there. The same thing is true for the EJB spec. The Spec is not
something
puristic that should just contain the bare-bone essentials, but build a
*broad*
foundation to craft our applications upon. Hey, EJB has been invented so we
can
concentrate on business logic, not frameworks!
Bye,
Michael
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
