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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Use of CONOPS in Sharable Service Contracts (WAS RE: [xml-dev] MS thinks

[ Lists Home | Date Index | Thread Index ]

BTW, a CONOPS isn't provided to fix REST vs RPC like 
problems.  One assumes those decisions are made or that 
the CONOPS absolves that by specing the format of the 
message.  

CONOPS can solve the problems of having multiple events 
or transmissions that must aggregate into some kind 
of whole based on the history.  For example, multiple 
transactions to assemble the history of a given 
person such as a background check.   There are multiple 
sources, multiple requests, multiple receipts, response 
latency, and no particular order, but the assembly 
must be chronological.  You can need contracts for:

o  Specified receipt format regardless of origin OR 
   method of request
o  Specification of who/where assembles the aggregate
o  Contract for who delivers the aggregate and in 
   what format if multiple formats are acceptable, 
   and the destination of the receipt

Parties who sign up for this have a concept of 
operations for a sharable service.  Beyond the above, 
there will be privacy contracts as well.  This isn't 
operational per se, but part of the contracting 
required to use the service.  One flaw in the 
descriptions of web services as I've noted before 
is the idea that they are available to anyone 
anytime anywhere.  That won't work. 

1.  Some services and kinds of information can 
only be used by qualified and authenticated users. 
Note "qualified".  You have to be an approved member.

2.  Some services for the same types of information 
do not share the same CONOPS.   Again, if you live 
in the UK, you may not want a Chinese service for 
using your checking account.  Different governments 
have different regulations.  Same for elections.  
Some countries don't have them or if they do, won't 
sign up to services that audit them.

This is why the name "Web services" may be inappropriate. 
If "the Web" is defined by the principles of that application's 
designers, then many of these services are Internet services 
and inappropriate for services that would run according 
to those principles.  Openness, ubiquity, and anyone/anywhere/anytime 
are not qualities that can be sustained in some business transaction 
types.  It sells well but isn't reality.  

Balmer needs to pay attention to that.

len




 

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

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