[
Lists Home |
Date Index |
Thread Index
]
Concept of Operations (CONOPS). Interesting you
should mention that. That is exactly what we
see for large network SOAP-enabled interagency
applications. Without it, there are too many
surprises. It still requires that long meeting(s)
of name/node heads standing in a room arguming
over a schema. Once that is done, the CONOPS
is easier.
It is helpful if there is a pre-existing network
application that does moreorless what one needs.
Then it is just a SOAP/XML enabling project. That
is tough enough given the "who bells the cat" problems,
but a lot easier than starting from scratch if one
can overcome "ownership of the problem" politics.
Otherwise, pick an edge system, pick a vendor,
negotiate the schema, design the conops for a
customer, and hope it "impresses" the rest
of your industry enough that they would rather
cooperate and co-opt than piss in your tag soup.
len
-----Original Message-----
From: Thomas B. Passin [mailto:tpassin@comcast.net]
This fits the RFC conops, the REST architecture, and yet is not message
queueing and is a lot simpler than message queueing. Of course, for this to
work, both parties must be able to know what to expect and how to designate,
for example, the max allowable time. These are a few of the "contract"
issues that Len has been emphasizing.
|
