[Wsf-general] Messaging project concept

[Sanjiva Weerawarana]

James Clark wrote:
>> I'm familiar with MTAs.
> 
> But are you familiar with postfix and qmail?  Different MTAs have very
> different architectures.  The architectural difference I'm talking about
> is the difference between sendmail on the one hand and postfix or qmail
> on the other.

I wasn't familiar with qmail itself but just read thru that paper you 
pointed to. Very nice for sure.

>>  I'm unclear why you think the current library 
>> cannot be used to implement such an architecture though.
> 
> The Axis2 core is based on passing a message context between handlers
> within a *single process*.  Please explain to me how you would implement
> a qmail/postfix-like architecture using this; I can't see how to do
> that.

That's essentially how Sandesha supports shutdown and restart right now: 
by writing its state out to a database. So if you wanted to say do the 
security validation in a separate process, then we'd write a transport 
that picks up the message from the incoming message queue (instead of a 
socket), runs the security code only and then another transport that 
writes it out to a separate queue representing security cleared messages.

The point is, if the processing steps/stages can be separated, then it can 
be done in Axis2. In fact the same modules would work .. the difference is 
how you'd configure Axis2: you'd have only the specific module with custom 
transports to get the message in and dump it out after the module 
completes. Even things like message cleanup, which is currently done with 
a thread, can be done by a separate process.

Does that make sense?

> No.  That's not the point I'm trying to make.  I'm saying that
> 
> a) an modern MTA-like architecture (like postfix or qmail) is the right
> kind of architecture for Telegon (because of its superior security
> qualities), but

I'm +1 with a multi-process arch being the way to do this.

> b) it wouldn't be a suitable architecture for a general purpose WS-*
> stack (message throughput too small, not a good match for HTTP)

OK.

> However, it is of course true that using a high-level language rather
> than C is good from a security point of view in that it eliminates a
> whole class of potential security problems.

That's of course true. The reason we wrote in C however is to enable 
direct binding to multiple languages and because we didn't think (and I 
don't think you're suggesting this either) that re-writing the entire 
stack in Python, Perl, PHP etc. makes sense.

> My point was that the RM implementation needs to share the message queue
> infrastructure with the rest of the server.  I think Paul explained some
> of the issues here.

I don't see any issues .. let's see whether you agree after reading my 
explanation above.

> The queue as far as a modern MTA is concerned does not play the role of
> the transport: it's the heart of the MTA that connects all the parts of
> the MTA together.

Agreed- it effectively plays the role that the handler chain plays now 
except with more reliability: store and forward between stages of processing.

> The problem is the Axis2 core. This very much has a WSDL world view, in
> particular the two parallel Message/Operation/Service hierarchies, which
> is at the heart of the architecture.  This is going way beyond the part
> of WS-* stack that I think we need for Telegon, which corresponds
> roughly to the functionality of Axiom plus some of Rampart (without the
> dependencies of Rampart on Axis2 core).

I'm not sure how much of the context stuff and MEP stuff you can skip: the 
RM and secure conversation combination creates some complex state handling 
requirements.

You of course probably don't need the XSDs but Axis2 doesn't either 
(Synapse for example mediates messages without having the XSDs around). 
I'm pretty sure you'll need the operation concept (that is essentially the 
representation of a MEP). Service may be optional but even that I'm not 
sure because to do secure conversation you'll need to remember some 
context that spans interactions.

 > The other big problem with the
> Axis2 core is that it has a fundamentally single-process Java-esque
> architecture.

This is what I covered earlier- I think this can be dealt with.

> I think you're missing a crucial factor here: security, or, more
> precisely, perceived security.  This is important for any network
> application, but it's particularly important for Telegon:
> 
> - I envisage Telegon being used between organizations, which implies
> that messages will go across the firewall.
> 
> - The reason for using Telegon rather than email is presumably that the
> message is high-value.
> 
> - The sophisticated end-to-end security offered by WS-Security is one of
> the main potential selling points of Telegon relative to competing
> technologies (AMQP, REST, email).  AMQP also has to balance the needs of
> security against a requirement for high volume/throughput.

These are exactly the value propositions of WS-* as well: end-to-end 
reliable, secure and transactional delivery of messages. What you're 
talking about is delivering those benefits to users as a simple to use 
application.

> What drives how a product's security is perceived?  People look at the
> code, they look at the architecture and they look at the documentation.
> That's not to say every user does it, but a conscientious system admin
> will try to determine the net consensus about the quality of the
> security of a new security-sensitive product, and that will ultimately
> be driven by people who have had a detailed look at the implementation.
> Important distributions (at least RedHat) also do a security audit on
> any program that is a candidate to be included in the distribution.

OK this point I can't argue with :).

> I think the fastest/cheapest way to get something that is
> stable/reliable/secure up and running is to do a pure Python
> implementation, without spending any time creating Python bindings to C
> libraries. (There are already Python bindings to XML parsers, databases,
> openssl: I don't think we could manage without those.)  Spending time
> creating Python bindings to Axis2/C at this stage is not in my view a
> good idea: creating good bindings is a lot of work (just think how much
> effort has been spent on the PHP stuff); these bindings would then have
> to be kept up to date with the development of Axis2/C, which would an
> ongoing additional burden on Axis2/C development. Also introducing C
> into the picture complicates a lot of things: debugging especially
> becomes a nightmare; build and distribution are also made more
> complicated.

OK this is again a general point- whether the right way to bring WS-* 
features to a scripting language is the way we're doing it (C impl being 
bound to each language manually) or with a custom impl for each language. 
I'm not convinced that doing the custom approach is scalable but I don't 
disagree that for a fixed set of messages it would be faster to write a 
custom impl (in python or whatever) rather than write a bunch of C code.

> More importantly, I believe it would be an order of magnitude easier for
> somebody to convince themselves of the security of a self-contained
> 10,000 line Python program than of the security of program that has
> 5,000 lines of Python calling out to a 100,000 line C library. I also
> believe that we can have better security architecture, with a strong
> multi-process emphasis, if we are not constrained by the architecture of
> Axis2, which was designed for the JVM environment which is totally
> difference from a security perspective.

Axis2 is a library. It can be deployed/packaged/used in multiple ways. The 
default packaging we do is a single process packaging .. that doesn't mean 
that's the only way to do it however.

Let me give an example. Steve Loughran (a guy from HP) gave up on Axis2 
because he doesn't like the aar packaging model. See:
http://www.1060.org/blogxter/entry?publicid=B7BD2FFDD2C4C2647BE11D2B1DCE6376

But he's *DEAD* wrong. Axis2 does not *mandate* the aar deployment model; 
that's just the default way of doing things. If someone wants to change 
that and deploy classes from the normal class loader they can.

Similarly, just because in WSAS we package Axis2, Sandesha, Rampart etc. 
all into one process doesn't mean that's the only way to do it. In fact we 
already have an example of a multiprocess architecture: drop Synapase/ESB 
in front of Axis2/WSAS and let the front guy terminate RM etc. and forward 
the messages. So its entirely doable because of how flexible Axis2's 
architecture and deployment model is.

Synapse is actually a good example of how you can use Axis2 as a library 
and not be bothered by its deployment model and so on.

> Such a pure Python implementation would almost certainly have
> unimpressive performance, but my guess is that the performance would be
> good enough for people to experiment with.  However, at this point I
> think we shouldn't worry too much about performance, except to ensure
> that the performance critical parts are well isolated in modules that
> can be replaced by C implementations. It is very likely that we would
> need to evolve the design and implementation of Telegon substantially
> over a period of time based on our experience and feedback from others.
> Having all the code in Python would make this much easier.

No argument there .. C isn't by any means the easiest language for many 
things.

> When (and if) we get to the point that we feel confident that our design
> is right and we have a something for which there's a real demand out
> there, we can work on replacing the performance critical modules by C
> implementations.  That might involve Axiom or it might be based on the
> XML stuff I was working on or it might be something written specifically
> for this.

I don't want to bet you to a race but I'd be surprised if you could write 
this whole thing in Python faster than I can package up Axis2 (Java, in my 
case) bits into multiple processes ;-).

No no that's not a challenge!

Sanjiva.
-- 
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: sanjiva at wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000

"Oxygenating the Web Service Platform."