[
Lists Home |
Date Index |
Thread Index
]
Michael,
That sounds like a heavy weight you've been carrying on
your shoulders.... better lose some of the load or you might
start getting a hunchback.. :-)
but Roll-your-owns usually have a bit more flavour than the
packet variety.
and being street legal while sounding nice, can often come
with restrictions that some enthusiasts are just happy living
with... isn't the smell of burnt avgas something special?
and as for these standards bodies, they still haven't produced anything that
is anywhere near as good as commercial products from Sterling and others.
So the rest of us just sit back saying "ok, produce what you say you are going
to produce - come back when you are ready".
And we just sit around and wait..
cancel that.. I'm going out for a swim.. the water is nice and warm this time
of year round here...
On Fri, 1 Apr 2005 10:15 pm, Michael Champion wrote:
> On Fri, 01 Apr 2005 16:17:56 -0800, Tim Bray <Tim.Bray@sun.com> wrote:
> > On Mar 30, 2005, at 12:32 PM, Michael Champion wrote:
> > > If on the other hand you are building systems that
> > > handle confidential information, mission-critical services, and have a
> > > bunch of legacy systems and protocols to integrate, I'd say the burden
> > > of proof is on anyone suggesting something other than WS at this
> > > point.
> >
> > When you say "WS" I assume you mean "SOAP+WSDL", given that more or
> > less everything else in WS-* is either not yet implemented, or not yet
> > standardized, or exists in multiple competing versions from different
> > vendor factions.
>
> Definitely SOAP, if you are bridging a bunch of legacy systems it's
> going to be desirable to have its protocol neutral headers to carry
> around information that you might have gotten with one
> protocol-specific field and need to get to the destination.
>
> WSDL is not anybody's favorite spec, but it's handy for ordinary
> mortals who just want their tool to generate that XML stuff so they
> don't to get their hands dirty with it. For better or worse there are
> a lot of those people lurking around, and the chances are you will
> have to deal with them at some point in your integration project. So,
> with some personal reluctance, I'd have to say that WSDL is part of
> the mix.
>
> WS-Security is an OASIS standard, and leverages XML Encryption which
> is a W3C Recommendation. I don't know for sure how field proven it
> is, but I'm comfortable saying that it makes sense to leverage all the
> thought and experience that went into it unless you KNOW that you can
> roll it yourself better than OASIS did. All those picky little
> details that it specifies are XML Encryption interop problems waiting
> to happen if you roll your own, AFAIK.
>
> WS-Addressing has been on the fast track at W3C after some pretty
> heavy-duty discussions and prototyping carried out by the major WS
> vendors. Again, if you have the pain that it addresses, does it make
> more sense to roll your own or go with the flow? I'm confortable
> suggesting that the burden of proof is on someone who thinks they can
> do it better, and still support the functionality it offers.
>
> OK, there's multiple versions of the WS specs for message reliability
> with different vendor factions on one side or the other. I guess you
> go with whatever your enterprise vendor supports; if you have to
> integrate across incompatible vendors, I guess you roll your own
> solution for this particular bit. ... or consult with an "integration
> tool integrator", sigh.
>
> As for everything else in WS-KitchenSink, I really don't know -- I
> haven't followed this stuff closely for more than a year. A lot of
> them may address problems that most people don't have yet, so the
> chaos there is irrelevant. A few general observations: Sure, they
> aren't "standardized", but neither are all sorts of specs that the
> XML world runs on: SAX, RSS, RDDL (increasingly in the MS world), and
> SOAP/WSDL 1.1 for that matter. The question is whether they have
> enough real world functionality and interoperability to make it more
> sensible to leverage them, roll your own, or wait for a Real Standard.
> That's a decision everyone just has to make for themselves. Also, I
> guess I really do think that anyone getting into an swamp such as,
> for example, the one which WS-Coordination / WS-AtomicTransaction /
> WS-BusinessActivity tries to drain, owes it to themselves to make VERY
> sure that they understand where the alligators are lurking better than
> the very smart and experienced people who have been working on the
> problem for some years now. Maybe your better answer is to build a
> bridge over the swamp rather than drain it, I wouldn't have any reason
> to disagree ... but that will offer you a whole new set of bleeding
> edge problems to answer, and a lot fewer resources to draw on to help
> you.
>
> I have no particular personal or Day Job stake in WS-*, but after this
> little thought experiment I do still think that anyone using XML and
> "building systems that handle confidential information,
> mission-critical services, and have a bunch of legacy systems and
> protocols to integrate" ought to be taking an extremely close look at
> that stuff. What's the practical alternative? It's not "rewrite
> everything with all key components conceived of as abstract resources
> that exchange XML representations, driven by hypermedia as the engine
> of application state" or whatever. Lotsa luck getting THAT by the
> executives :-) There might be some pragmatic way to leverage Plain ol
> XML and the Web more effectively than most organizations do now, but
> AFAIK the major success stories for this involve public information,
> non-mission critical services, and tend to be built from scratch for
> the Web. As Rich Salz has explained very lucidly earlier in this
> thread, you do NOT get industrial-strength security, reliability, etc.
> for free with your HTTP infrastructure. I'm pretty sure that the most
> currently viable alternative to WS-* is More Of The Same -- MQ/COM
> /CORBA/J2EE / armies of consultants / barrels of red ink that
> enterprises are trying to get away from. That provably kindof works,
> but is provably expensive. I don't know how that balances out vs WS-*
> on the burden of proof scale.
>
> I (personally) suspect that the long term answer to this will draw a
> lot from both the simpler, more evolutionarily stable ideas that REST
> tries to pin down and the complicated realities that WS-* attempts to
> wrap up in somewhat tidier bundle. The ideas that excite me involve
> (surprise, surprise) XML-capable DBMS to do the heavy lifting for
> transactions, reliability, authentication/access control, and
> interfacing to the legacy infrastucture. Patrick Thompson (then of
> Rogue Wave) and I (then of Software AG) were trying to interest people
> in a Ruple [XML Tuple Space prototype] / Tamino combination to do this
> a few years ago. In the very near future, <plug> the SQL Server 2005
> Service Broker
> (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsql90/h
>tml/sqlsvcbroker.asp?frame=true) might hit a very similar sweet spot for
> "messaging in the database" while presenting a somewhat REST-like minimal
> and uniform interface to the client. </plug> .
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
--
Computergrid : The ones with the most connections win.
|
