Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 [expletive deleted] in your tag soup. len -----Original Message----- From: Thomas B. Passin [mailto:tpassin@c...] 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.
|
