Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: WSIO vs. Semantic Web - Setting the Record Straight
 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@p...] 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? Yes. >How will it integrate with other web services? Loosely. >How will they integrate with it? Loosely. >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. len 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
