Post by Sanjiva WeerawaranaHowever, key point is that that its a
*utility tool* that we're offering. A command that does something useful.
Do you agree?
Yes.
Post by Sanjiva WeerawaranaYour suggested architecture is not anything like what I think is a
reasonable architecture for this application. The right architecture in
my view would be similar to an MTA (qmail or postfix). Here's a good
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.
Post by Sanjiva WeerawaranaI'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.
Post by Sanjiva WeerawaranaThe main goal on the receiver side needs to be security. Unless we can
demonstrate a good security architecture, it won't become popular. (For
a start it won't get included in major distributions, which do a
security audit before they include new applications.) The key to a
high-security architecture for something like Telegon is
compartmentalizing it into independent processes, which are small and
simple and each have limited security permissions. This is not
something you can retrofit to Axis2/C. Indeed I don't think it's
possible to design a general purpose WS-* architecture that would give
the same level of security as an architecture optimized just to handle a
specific Telegon-like service.
OK so this is a general argument against anything written in C then?
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
b) it wouldn't be a suitable architecture for a general purpose WS-*
stack (message throughput too small, not a good match for HTTP)
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.
Post by Sanjiva WeerawaranaOn the sender side, security is less of an issue. However, I don't
think a python script on top of wsclient will do it. The problem is our
memory-based single process architecture, particularly as regards RM.
The command line client should add the message in an queue, so that it
ends up in a file somewhere, and then exit. All the work should be done
by a daemon that picks up messages from the queue and sends them on.
This should happen whether RM is being used or not. The RM
implementation would I believe be radically different, because it would
share the message queue infrastructure with the rest of the server. Even
here there are security issues because there should be a single daemon
to handle messages from all users.
This is a trivial thing you describe- a transport that drops the message
to a queue. No RM or anything involved .. "sending" amounts to saving the
message in the send queue and returning.
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.
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.
Post by Sanjiva WeerawaranaPeople trust email. How many people do you think ever tried to understand
the mess that sendmail was/is? I'm not a Linux developer any more but when
I was I certainly didn't introspect the source of all the cool stuff I
used to use. Maybe that was not the norm!
The sendmail example is a good one. If you came out with a mailer with
sendmail-like architecture today, you would not find many takers.
Sendmail achieved popularity because for a long time it was the only
game in town. But it's had a long history of security problems. Newer
MTAs that have managed achieved popularity (notably qmail and postfix)
and take some market share from sendmail have all done so for a large
part on the strength of a proper security architecture. This isn't just
theory: postfix and qmail have had very few security problems compared
to sendmail.
Post by Sanjiva WeerawaranaAnother key part of winning people over is overcoming the perception
that WS-* is a indivisible blob, that they have to take or leave as a
whole. In particular, it's important that people realize that they can
take advantage of the relatively small and simple parts related to
particular message instances (SOAP core, MTOM, WS-Security), without
buying into all the complexity and controversy surrounding the parts
that relate to types/contracts and message payloads (XSD, WSDL,
WS-Policy). It's hard to do that if your implementation is based on a
full WS-* stack.
Not at all! That's *EXACTLY* the design of Axis2 .. bring these in as
needed.
Many of the WS-* opponents are really arguing about the fact that there
are 100+ WS-<something> specs out there and its not clear what really
matters vs. what's fringe. The core you identified (SOAP core (not
adjuncts) and MTOM) are what Axis2 do and Rampart does WS-Sec. I don't see
how Axis2 (C or Java) can be lumped into the "WS-* blob" category.
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). The other big problem with the
Axis2 core is that it has a fundamentally single-process Java-esque
architecture.
Post by Sanjiva WeerawaranaHowever, whether people will use the Telegon product or not is a
function of its usefulness and its stability.
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.
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.
Post by Sanjiva WeerawaranaIf we can achieve that with
Axis2/C *and* if that helps get this done faster/cheaper why wouldn't we?
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.
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.
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.
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.
James