Steve Brewin wrote:
> We should define an interface that meets our requirements for dispatching
> work, most likely a subset of the JMS APIs. Implementations of which may
> use any SOA style service, be it JMS, WebServices, whatever.
We can, but I assert that although we can change the Mailet API to look more
like JMS, the put operation is already present as Mail.setState, and the
get/onMessage is exposed as a service method.
> One thing we can't be assured off is that the service can always consume
the
> work, so we have to have a clear contract for this. Probably no more than
a
> set of specialized Exceptions?
Seems likely, yes.
> > - Each processor is a transaction. What this means
> > is that we can try to wrap a global transaction
> > around behavior within the processor. This will
> > have some impact on Mailets, too
> I'ld suggest using javax transactions.
I expect so, yes. I don't have any experience with is XA implementation in
Java, other than using existing implementations, but the goal ought to be
for our queue managers and other applicable resources to play nicely in the
XA scenario.
> I would not define interfaces for the queue manager and processor,
> but rather define semantics and responsibilities.
> Lost me here. I'm not sure why we can't define interfaces for the
> things that we talk to and why we wouldn't want to. Perhaps you
> can elaborate?
Hmmm ... perhaps it wasn't clear that I was separating what JAMES needs to
define from what I see as at least potentially generic in the Mailet domain.
For JAMES, I would expect us to have specific interfaces, but I would not
impose them on the overall concepts, in order to leave maximum flexibility
to authors of independent Mailet servers.
I view the requirements as:
- What does the Mailet API need from the environment?
The mailet container is require to establish that, since it invokes the
Mailet API. For JAMES, the Mailet container is the processor.
- What does the Mailet container require from the environment?
In the proposed approach, the queue manager is responsible to establish
that, since the queue manager invokes the processor.
I can argue that we don't need to define the mailet container interface, and
that the processor interface can be JAMES-specific. However, I did comment
incorrectly earlier with the MDB example, which should not have been a
processor, and would like to define a processor interface, even as a
separate package, in order to open the door to sharing processor
implementations across server implementations.
Again, one can imagine many ways to configure and invoke mailets, so I sort
of view this as akin to Pluto. You can host the Mailet API however you
want, but we can provide you with pre-written containers to plug into your
messaging engine.
- What does the queue manager require from the enviroment?
Even if we provide pre-written containers, I feel that we can leave maximum
flexibility by defining the responsibilities of a queue manager without
requiring a specific queue manager interface. Certainly, for JAMES, we will
have interfaces for processors and queue managers. I just don't feel that
there is a *necessary* one in the generic case, even to use our pre-written
processors.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
