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


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: ProcessingOptions example and discussion

Hi all !

Despite Nick's critics I would vote for approach '1'. Atomic operations are easy to develop, easy to test and easy to understand ! 

Combined with a server side execution language ( e.g. BPEL, designed for composing web services in a transactional manner ) we could take advantage of perfect separation of concerns : Defining only the atomic operations in detail, using BPEL for the composite services. 

Like Trevor I can't instantly name all compound operations, but if I remember the f2f correctly, there are some more than just two ! And when it comes to encryption, the permutation bomb may explode ...

Anyway I agree to the last part of '3'. We should only define some 'useful' operations. I guess implementors will have easier job if they just have to combine some atomic operations than building operations completely from scratch.



> Without giving it too much thought, it seems to me that there are at least
> four possible approaches ...
> 1. All operations are atomic.  Compound operations are built by clients
> making multiple calls to different services.  Some technique for linking the
> output of one operation to the input of the next would have to be defined.
> 2. Request messages can be concatenated, with an option to indicate that the
> input token in one request is to be the output token from the previous
> request.
> 3. All operations (including compound ones) are identified by their own
> request type identifier.  We would define a few useful ones.  Others could
> define their own in profiles.  Each compound-operation message should be
> derived from the general message syntax defined in the core document.
> 4. Compound operations are variants of our existing sign, timestamp and
> verify request types.  All variations in syntax would have to be captured in
> the basic syntax.

Mit der Grupppen-SMS von WEB.DE FreeMail können Sie eine SMS an alle 
Freunde gleichzeitig schicken: http://freemail.web.de/features/?mc=021179

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]