Subject: Re: [drinks] Refactored SPPP protocol schema and WSDL

From: "Ali, Syed Wasim" <[email-masked]>
Date: Thu, 10 Nov 2011 09:49:20 -0500

Vikas/Ken,

Thanks for making the updates. There are a couple things that are not clear in my mind and I could be missing a thing or two that you can help with.

What is the motivation of making the ObjKeyType and RteGrpOfferKeyType abstract? I guess what I am trying to understand is the impact of putting the definition of what constitutes the object-key in the WSDL. In the worst case, this can have interoperability impact where two known transport/binding of sppp interpret the object-key differently. My understanding of the best use of "type" in WSDL is for a control object that doesn't take away key piece of information from the base schema.

Also, since the data model is described in the main document, perhaps it will help to list the type of errors that may arise in the base document as well. This way, the implementation of the spec will enumerate these error conditions as well, in addition to any other error conditions that are transport specific. I think this will effect interoperability as well. How the error condition is played back will certainly be transport specific.

Let me know what you think.

Thanks,

-Syed

From: "Bhatia, Vikas" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 27 Oct 2011 08:07:30 -0400
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [drinks] Refactored SPPP protocol schema and WSDL

Attached is the revised protocol base schema document (spppbase.xsd) and transport WSDL (sppp.wsdl). For reference, I am also attaching the “old” base protocol schema and wsdl (spppbase_beforechange.xsd and sppp_beforechange.wsdl).

These changes primarily address items A), C) an D) in Ken’s email below along with reintroduction of the “rar” element (identifying the Registrar).

The list of changes are:

1.     Made ObjKeyType abstract in the Protocol and extended it in the types definition in the WSDL.

2.     Made RteGrpOfferKeyType abstract in the Protocol and extended it in the types definition in the WSDL.

3.     Moved all schema types related to verbs/operations from the Protocol to the Transport. In essence, the base schema (spppbase.xsd) now has the definition of objects (nouns) in sppp but no verbs/operations. All operation (verb) definitions are in the WSDL types.  All types annotated (in spppbase_beforechange.xsd) with “Generic Request and Response Definitions“ and “Operation Request and Response Object Type Definitions” have been moved as part of this restructuring to the “types” section of the transport WSDL.

4.     #3 above includes “ResultCodeType” and “RqstObjResultCodeType” moving to the transport WSDL. This was for completeness of the change around this. (to some extent this relates to item B)

5.      Reintroduced the element “rar” back in to the “BasicObjType” (spppbase,xsd).

We can discuss in detail around these in the design call.

Thanks,
Vikas

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Cartwright, Ken
Sent: Thursday, September 15, 2011 1:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [drinks] Rafactoring SPPP to make it ReST Friendly

Today we jumped the gun a bit and tried to have a meaningful discussion on item D below, even though not a lot of meaningful thought had been put into it.  But I believe the “solution” to Item D below, which I also hint at in the description of item D, is to just not have those XSD data structures (the ones that currently enable any set of verb/noun pairs to be passed in and processed as a single request/transaction) be part of the “protocol” document’s XSD.  How (and if) that feature will be provided will just not be specified in the “protocol” document.  If an author wants to write a ReST specification they can just decide if they even want to provide that feature, and if so, how they want to do it. And for SOAP, the SOAP “transport” document will contribute those data structures (probably in a form somewhat modified from what we have now) via a separate XSD to provide that feature.

Ken

________________________________
From: Cartwright, Ken
Sent: Tuesday, September 13, 2011 3:47 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Rafactoring SPPP to make it ReST Friendly

Syed and I meet for about 90 minutes today to talk through the details of the impacts that result from making the protocol document ReST friendly.  I’ve summarized these impacts below in fairly good detail, so please review it if you wish.  To kick off this effort I’m going to take on how to make the changes described below under “A) Object Identity”, and Syed is going to take on the changes below under “B) Response Codes and Response Data Structures”.  After A and B are done, which, along with D, are the more involved tasks, we will tackle C, D, E, and F.

Ken

A) Object Identity
================
SPPP uses composite business keys to identity object instances.  There are SPPP XSD data structures like ObjKeyType that serve this purpose.  Object keys are used to house relationships between objects and to query for (get) a specific object instance.  ReST controls how object identity (object keys) must be encoded/structured, using URIs.  So the SPPP XSD will need to be changed to support the use of either URIs or more traditional approaches such as that currently used by SPPP.  And this will have to work for both the non-composite object relationship case and for the query/get case.  And these changes will impact the current structure of the SPPP “nouns”.  So, more specifically, the following XSD data structures will need to change:

1) RteRecType  (because it identifies the DestGroups that is relates to)
2) PubIdType (because it identifies the DestGroup that it belongs to)
3) ObjKeyType (because it is not a ReST friendly structure for object identity)
4) The Data Structures that contain or depend on an ObjKeyType
   4.1) RteGrpOfferKeyType
   4.2) RteGrpOfferType
   4.3) EgressRteType
   4.4) RteRecRefType

B) Response Codes and Response Data Structures
========================================
ReST controls what response codes and the corresponding response messages that are available to the application, the HTTP response codes.  So SPPP’s response codes will have to be removed since ReST dictates that it is the HTTP protocol’s response codes that are allowed.  The response codes will have to be moved to the “Transport” document.
SPPP’s parameterized error response code message structures that define what data element of what object was found to be erroneous will have to be removed/changed since the HTTP response codes do not give you that level of detail about what failed.  We will either have to punt on this capability or create a hybrid approach that can be hacked into ReST, such that response objects contain additional sub-response codes and data structures.
SPPP’s response data structure, that incorporates an overall response code and, if there is an error, the data structure of the object that failed validation will have to be watereddown/removed/changed.

So, more specifically, in addition to the response code definitions being changed and the parameterization of the response code messages being removed and replaced with some other scheme, the XSD items that are likely to need to be changes are:

1) ResultCodeType
2) RqstObjResultCodeType
3) spppUpdateResponse

C) Actions/Verbs/Operations
===========================
The SPPP XSD currently defines the operations/verbs that can be performed on each of the SPPP data model objects/nouns, and the required inputs and outputs of each.  But ReST controls what verbs are available to the application (Put, Post, Get, Del), and provides no way of enforcing the allowable input and output data structures for each.  So we will need to remove all operations/verbs and remove the specification of the required inputs and outputs for each operation/verb from the XSD.  These will now need to be documented just in textual form in the document.

D) Base Protocol Data Structures and Housekeeping Features
===============================================
SPPP currently defines common request and response data structures that are used for any type of operation/verb and any type of noun, and in-fact allows different verb and noun pairs to be passed into a single request.  This was done to allow any set of verb/noun pairs to be passed in and processed as a single transaction, all or nothing, giving the client optional control over their transaction boundaries.  But because ReST uses the pre-determined verbs from HTTP (Post, Put, Get, Del), which is embedded inside the HTTP envelope, this type of feature cannot be cleanly provided.  Furthermore, house-keeping features such as clientTransId, serverTransId, minorVer are housed within these base data structures.

So we will either say that a ReST implementation will just not support some of these features, or restructure the following XSD data structures in some way to allow some of them:

1) spppUpdateRequest
2) spppUpdateResponse
3) spppQueryRequest
4) spppQueryResponse
5) spppServerStatusRequest
6) spppServerStatusResponse

E) SPP “Protocol” Documentation Changes

And of course all of the above will require notable changes to the document content itself.

F) SPP “Transport” Document Changes

And of course all of the above will require notable changes to the document content itself because they push mofer of the specification out of the “Protocol” document and up into the “Transport” document.

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

________________________________
This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.