unknown
1970-01-01 00:00:00 UTC
I don't disagree.
cannot be used to implement such an architecture though.
to a queue. No RM or anything involved .. "sending" amounts to saving the
message in the send queue and returning.
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!
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!
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.
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.
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.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.)
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.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.
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
I'm familiar with MTAs. I'm unclear why you think the current libraryreasonable architecture for this application. The right architecture in
my view would be similar to an MTA (qmail or postfix). Here's a good
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?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.
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 messagethink 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.
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.program as the receiver-side daemon (and probably as the intermediary as
well).
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 amoment 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.
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 moveif 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.
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 asthat 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.
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 inbeing 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.
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: ***@wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000
"Oxygenating the Web Service Platform."
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: ***@wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000
"Oxygenating the Web Service Platform."