james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Stephenson" <...@thestephensons.me.uk>
Subject Re: Axis mailet / matcher
Date Wed, 11 Jun 2003 15:12:39 GMT
Noel,

I for one am definately looking for an SMTP only impl within James, HTTP
running in XXX app svr  can run along side.

Would you care to elaborate on your thinking in using a processor (as
opposed to a mailet) I didn't follow what you were getting at?

Tim
----- Original Message -----
From: "Noel J. Bergman" <noel@devtech.com>
To: "James Developers List" <james-dev@jakarta.apache.org>
Sent: Thursday, June 05, 2003 6:48 PM
Subject: RE: Axis mailet / matcher


> Guys,
>
> This discussion is all good, but please review the archives:
>
>
http://archives.apache.org/eyebrowse/SearchList?listId=&listName=james-user@
> jakarta.apache.org&searchText=soap&defaultField=body&Search=Search
>
> Also, Jason Webb indicated interest in this area:
>
http://archives.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apac
> he.org&msgId=589966
>
> I would sugggest the SOAP over SMTP approach.  We don't want to be a
> web-server, and the asynchronous properties of messaging protocols
> differentiate them from HTTP.
>
> I don't know if SOAP is best handled by a mailet or a processor, e.g.,
>
>    <mailet match="SoapMessage" class="ToProcessor">
>      <processor> SoapDispatch </processor>
>    </mailet>
>
>    <processor name="SoapDispatch" class="org.apache.james.soap.Processor">
>      ...
>    </processor>
>
> A mailet is portable, but more limited.  On the other hand, are those
> limitations reasonable in the case of a SOAP Dispatcher?  A mailet can
load
> a class, marshall parameters, and invoke methods.  That may be sufficient.
> The place where I think using a processor might work better is for
something
> like Sieve and possibly BSF.
>
> Just thinking out loud ... I'd be happy to see people contribute a SOAP
> support to James.
>
> --- Noel
>
> -----Original Message-----
> From: Mark Imel [mailto:james@imelshire.com]
> Sent: Thursday, June 05, 2003 10:28
> To: James Developers List
> Subject: RE: Axis mailet / matcher
>
>
> As far as James & SOAP:
> I can think of two types of use cases for integrating James & Soap:
> 1) Exposing administrative functions of James
> 2) Exposing other applications via a SOAP over SMTP protocol.
>
> Both of these are really, really cool.
> What i like about #1 is that right now the telnet manager is the only
> admistrative interface into James, not counting editing the config file.
> (Hopefully JMX will be coming along soon as well.) But with a SOAP
> interface, then the James doesn't have to invest any/much time in an
> administrative interface.  With some RAD soap tools, you can quickly come
up
> with a UI.  There's still an investment in ensuring that the adminstrative
> apis exist and work, but not the required GUI work.
>
> Secondly, exposing other applications via SOAP over SMTP can be even
cooler.
> Since James is already deployed inside of Avalon, there's support for
> application management that James wouldn't have to come up with on its
own.
> I think even more importantly, is the opprotunity to archive/audit SOAP
> requests very naturally.
>
> Moving forward with all/either SOAP/RMI/JMX, there's one thing that i
would
> recommend:  Make sure you're administrative apis are protocol independent.
> That way you can plugin in adapaters and support any/all of the above
> protocols.
>
> -----Original Message-----
> From: Vincenzo Gianferrari Pini
> [mailto:vincenzo.gianferraripini@praxis.it]
> Sent: Thursday, June 05, 2003 5:40 AM
> To: James Developers List
> Subject: RE: Axis mailet / matcher
>
>
> Tim,
>
> Just yesterday evening I started asking myself (dreaming) about that, and
> downloaded a fresh copy of axis to have a look!
>
> I think (dream) that there are two independent possibilities:
>
> 1) Have James deploy web services to respond to administrative requests
> (whatever they may be) using SOAP over HTTP: I think that RMI support
would
> be enough and better, and much easier to implement.
>
> 2) Have James become a "native" SOAP over SMTP server, both (i) to respond
> to administrative requests (mailets could be reconfigured runtime with
> messages - something that can obviously be done also with plain messages,
> but a protocol could be defined), and (ii) to deploy generic asynchronous
> web service *applications*: a grand new world, and probably very unique
> being James also a "general purpose" mail server. But this would be
probably
> a big project.
> Unfortunately Axis seems to not have any SMTP support. There exists an
> SMTP/HTTP bridge with Apache SOAP deployed on Tomcat
> (http://ws.apache.org/soap/faq/faq_chawke_smtp.html), but I have just
> started digging around, and know very little about.
>
> IMHO option 2-ii above is ambitious but exciting too! And totaly
independent
> of option (1), that as I said I would attack, if interesting, using RMI.
>
> Has anyone else ever thought about those topics?
>
> Vincenzo
>
> > -----Original Message-----
> > From: Tim Stephenson [mailto:tim@thestephensons.me.uk]
> > Sent: giovedì 5 giugno 2003 13.49
> > To: James Developers List
> > Subject: Axis mailet / matcher
> >
> >
> > hi
> >
> > anyone done anything to allow james to integrate an axis (or other soap)
> > engine?
> >
> > any suggestions for how it should be done?
> >
> > cheers, tim
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message