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