OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] WSIO vs. Semantic Web - Setting the Record Straight

[ Lists Home | Date Index | Thread Index ]

We are just starting to look into what the new version 
of Fox offers and we are not going to do anything 
quickly.   But the initial building of the service 
is slam dunk easy.  The details, as you suggest, 
will be harder and for that reason, we are unlikely 
to do much fast.  We will work from the edges. That 
is where this tech gets the most bang for the buck.

From: Paul Prescod [mailto:paul@prescod.net] 

All good questions. In short form:  It's In The Way 
That You Use It.

>Is that really a Web Service? 

Yes, based on support of WSDL and SOAP.  It is 
fast and easy to build.  I know it gets harder, 
but it does hide the wires.

>How will you handle extensibility and interface management? 

One, don't go too deep.  I'm not sure what you mean by two.  If you 
mean, keeping everyone updated on the interfaces, that 
isn't a problem yet.  It will be.  I have to believe 
right now that is an issue of keeping the documents updated 
just as it is when one builds across a group using a 
framework.  Web-accessible documents.  I'm not as worried 
about this as someone who builds a fine-grained system.

>How well does the performance scale? 

I don't know.  Ain't that grand.  But I don't expect it 
to be any worse than normal web performance.  I don't 
plan to use this for high frequency access and will 
stick to coarse transactions.  Anyone who really believes 
we will use web services for high frequency critical 
transactions is smoking dope.  Not yet if ever. "The 
web" isn't up to that kind of "network is the computer" 
thinking, IMO.

>Will your security team let it work across the firewall? 


>How will it integrate with other web services? 


>How will they integrate with it? 


>What business processes does it fit into? 

I can't comment.  But, again, if one stays coarse and stays 
away from fine grained transactions, one can stay above 
the insanities of being too close to the desks of individuals 
and that is key as we have known for years for loosely coupling 
enterprise processes.  Don't go too deep into the nestings. 
It screws up the game.

>What are the legalities of the business documents you are processing.

Well, that is a big issue. It gets worked out case by case.  That 
is what Dissemination Management is all about.  Remember, our 
customer already solves this problem without the net.  They know 
the rules.  We just have to avoid "gladness" that inspires one 
to put pictures of key personnel and their desk phone numbers 
up where competitors can find them.  The first time someone 
showed me the web, she showed me pictures of Naval officers and 
said it was a career enhancer.  I told her it was a good way 
to get them killed.  It is now 2002 and I think I was right.  A lot 
of NRC drawings are coming off the web as fast as they can turn 
off the servers these days.

>If you're looking for a new wire syntax for COM then SOAP is just fine.

We're looking for an easier way to integrate edge systems that we 
don't control, and to be a polite edge system when necessary. "Polite" 
at macro scales is easy.  At micro scales, it is a dull slow 
and boring party.

Our strategies won't be much different than yours.  We understand 
what a business document is.  Also, one might consider that a 
system exposed to the net doesn't have to be the same 
system as the one used for internal mission critical operations. 
In fact, it is both easier and more cost-effective to use an 
architecture that segregates a warehouse server.

The trick is to stay away from near real-time 
processes and time-sensitive data.  That was what the 
old enterprise and hytime work taught me.  When I first 
went to the Hytime meetings, I was in search of a 
synchronization engine for hypermedia having seen that 
time was the critical problem for complete micro scale 
integration.  As things progressed, I began 
to realize that was a dumb way to do this work because 
real-time management is inherently unstable and 
the closer one gets to the 'real', the more unstable the 
process gets.  The more corrective processes one 
builds in (eg, rollback), the more costs go vertical or 
a strange attractor opens up like a black hole and the event 
system collapses.  So, one does as the IDEF guys 
advise and only uses the very large distributed 
process entry points at levels that stay well 
above the thresholds of collapse.  

Again, you may be right about REST over RPC, 
but look at the scale of the processes and tell 
me that other than ubiquity, it makes a difference.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS