[Wsf-general] Messaging project concept

[Sanjiva Weerawarana]

James Clark wrote:
> 
> The main product would be a command-line program.  Like most
> properly-designed Unix command-line tools, it would be usable both by
> end-users from the command-line and by developers from scripts or C
> programs.  Think of something like the "cvs" program or the client part
> of the "sendmail" program.

OK understood.

> You could do a variety of GUIs (GNOME, Web), but in the Linux world
> these are frosting.  As an alternative interface for programs, you could
> also do a very thin C library that would talk some simple protocol to a
> Unix socket. But again, this is frosting. A solid, command-line
> interface is the main thing, and plenty to start with.

+1.

> I see the key point about the positioning is that it's something
> designed to appeal to the mainstream Linux, open source hacker world,
> and in that world, I don't see the user/developer dichotomy that you do.

I'm fine with that positioning. However, key point is that that its a 
*utility tool* that we're offering. A command that does something useful. 
Do you agree?

Yes I'm setting up for my argument below ;-).

>>From a WS-* perspective, the way to think of Telegon is that it's one
> specific Web service.  Implementing one, particular service is a very
> different kind of thing from implementing a library that can deal with
> arbitrary services.  For example, the client can just print the
> appropriate XML directly.  The WSDL implementation could consist of just
> printing a fixed WSDL file (perhaps substituting a few variables).
> Implementing one fixed service from scratch in Python is not at all the
> same kind of effort as rewriting the current C stuff in Python.

I don't disagree.

> Another important point to bear in mind is the productivity/expressivity
> gain that you get with Python over C (provided you're not too worried
> about performance).  In my experience, the gain with Python over Java is
> at least as much as Java over C. (Ruby would give the same benefits as
> Python here.)

OK.

> Overall doing a Python implementation of enough of SOAP Core,
> WS-Security and MTOM to support just Telegon is not in my view a big
> deal. I think the main difficulty is in the nitty-gritty interop
> details: that's where what we've done so far would help a lot.

Again, I'm not disagreeing that it may not be complex to implement in Python.

> Your 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
> paper on qmail's architecture:

I'm familiar with MTAs. I'm unclear why you think the current library 
cannot be used to implement such an architecture though.

> The 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?

> On 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.

> In fact, I believe the sender-side daemon would end up being the same
> program as the receiver-side daemon (and probably as the intermediary as
> well).

Yes agreed.

> But perhaps the most important point is a non-technical one. At the
> moment I would say that the majority of the mainstream (non-Java,
> non-enterprise) technical open source community thinks that WS-* is, to
> put it bluntly, crap. They see it as far too complex, too RPC-oriented.
> They'll use it if they're forced to, or if they have to interop with
> something else that's already using it, but they wouldn't use it by
> choice.  This represents a huge lost opportunity for us an open-source
> company that is building on WS-*, because it dramatically reduces the
> pool of potential contributors, which is the main competitive advantage
> that we get by going the open source route.  Perhaps the main reason I
> find Telegon exciting is that I believe it that it has the potential to
> positively impact this perception.

Right. But it does that the same way Cardspace does it: it provides a 
function that people find useful without having to be concerned about all 
the WS-* gorp. If we implement Telegon as a command then there's no reason 
using Axis2/C exposes WS-* any more than a Python implementation does!

> However, there is no way, in my view, that is potential will be achieved
> if the only implementations are based on a full WS-* stack, whether it's
> Axis2/C, Axis2/Java or WCF.  A full WS-* stack (even without any modules
> -- just the core architecture) of necessity brings along too much
> complexity and baggage.  A WS-* sceptic will take one look at the
> hundreds of thousands of lines of code in the complete WS-* stack and
> say "This is waaaay to complex; there's no way I can trust this". If
> instead you could provide an implementation that was say 5,000 lines of
> Python without any dependencies on a WS-* stack, such that they could
> easily read and understand the code, then I think there's a chance of
> convincing people that WS-* is actually rather better than they think.

Sorry, I don't agree. If what we're providing is a useful tool to move 
messages from one machine to another, why do you think its internal 
implementation matters like this? I could say an XML skeptic could say the 
same thing about using a generic XML parser .. because its always worse 
than a special one crafted for a special grammar (which BTW is what 
Salesforce have done .. parser and WS-* stuff all special cased).

People 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!

> Another 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. Axis2 does not suck in XSD at all! It does bring policy but if you 
use WS-Sec you do need policy (SecPolicy) too realistically. You can of 
course hide all of it but its there if its real.

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.

> To summarize, I'm all in favor of one of our implementations of Telegon
> being on top of WSF/C (particularly the sender side, and particularly if
> we can find a way to use just Axiom and parts of Rampart without
> bringing in everything else): I think having multiple, independent
> implementations interoperate significantly enhances the credibility of
> the project, especially from the protocol perspective. However, I think
> the project has a hugely better chance of achieving widespread
> popularity in the open-source community if there's an implementation
> that
> 
> - does not depend on a WS-* stack, and
> 
> - is written mostly in a high-level scripting language (Python or Ruby)
> with C only where necessary for performance.

I agree it'll be easier to get developers to contribute if its written in 
Python. However, whether people will use the Telegon product or not is a 
function of its usefulness and its stability. If we can achieve that with 
Axis2/C *and* if that helps get this done faster/cheaper why wouldn't we?

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."