openspp-project — Participants in the OpenSPP Project, including Development Team,Owner, etc.

[OpenSPP-project] OpenSPP Test/Dev Server Inactive

[Dean W. <dea...@so...>]

Since nobody has been using the test/dev server, I've put it down for naptime (it's about 2 cents an hours to run, which adds up to a cheap six-pack every month).

I can easily bring it back up if/when we need access; it's an Amazon EC2 instance.

--
Dean

Re: [OpenSPP-project] What is the correct behavior of DelDestGrpRqst when the targeted group does not exist or has been previously deleted?

[Dean W. <dea...@so...>]

Ok, if it's according to the spec, it's not a bug in OpenSPP.

We just have to make sure we keep the same "happy" response even for an 
authorization failure on an object delete.

Thanks!

--
Dean


On 8/24/11 8:29 AM, Cartwright, Ken wrote:
> The behavior you are describing is correct per the current wording in
> the spec.   But I do not see it as a noteworthy item, so I could
> actually go either way on it.  Both approaches have advantages and
> neither of the two approaches necessitate a change to the XSD or the
> WSDL or the response codes.
>
> Ken ________________________________________ From: Dean Willis
> [dea...@so...] Sent: Tuesday, August 23, 2011 7:45 PM
> To: ope...@li... Subject: [OpenSPP-project]
> What is the correct behavior of DelDestGrpRqst when the targeted
> group does not exist or has been previously deleted?
>
> Right now, I can run repeated delete group requests, specifying the
> same group, and always get the same code 1000 Overall Success
> response.
>
> This doesn't seem right. WHat should it do?
>
>
> But it raises a question about a threat model.
>
> Suppose I attempt to delete a DestGrp that I should not be authorized
> to delete, or even see. If the respose returns as "unauthorized", as
> opposed to "not found", do I now know about the existence of a
> DestGrp that I was only guessing existed?
>
> Is this a problem?
>
> Always returning a "happy" response precludes the information leak,
> but it could cause other problems.

Re: [OpenSPP-project] What is the correct behavior of DelDestGrpRqst when the targeted group does not exist or has been previously deleted?

[Cartwright, K. <kca...@tn...>]

The behavior you are describing is correct per the current wording in the spec.   But I do not see it as a noteworthy item, so I could actually go either way on it.  Both approaches have advantages and neither of the two approaches necessitate a change to the XSD or the WSDL or the response codes.

Ken
________________________________________
From: Dean Willis [dea...@so...]
Sent: Tuesday, August 23, 2011 7:45 PM
To: ope...@li...
Subject: [OpenSPP-project] What is the correct behavior of DelDestGrpRqst when the targeted group does not exist or has been previously deleted?

Right now, I can run repeated delete group requests, specifying the same
group, and always get the same code 1000 Overall Success response.

This doesn't seem right. WHat should it do?


But it raises a question about a threat model.

Suppose I attempt to delete a DestGrp that I should not be authorized to
delete, or even see. If the respose returns as "unauthorized", as
opposed to "not found", do I now know about the existence of a DestGrp
that I was only guessing existed?

Is this a problem?

Always returning a "happy" response precludes the information leak, but
it could cause other problems.


--
Dean

------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
OpenSPP-project mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openspp-project

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.

[OpenSPP-project] What is the correct behavior of DelDestGrpRqst when the targeted group does not exist or has been previously deleted?

[Dean W. <dea...@so...>]

Right now, I can run repeated delete group requests, specifying the same 
group, and always get the same code 1000 Overall Success response.

This doesn't seem right. WHat should it do?


But it raises a question about a threat model.

Suppose I attempt to delete a DestGrp that I should not be authorized to 
delete, or even see. If the respose returns as "unauthorized", as 
opposed to "not found", do I now know about the existence of a DestGrp 
that I was only guessing existed?

Is this a problem?

Always returning a "happy" response precludes the information leak, but 
it could cause other problems.


--
Dean

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Dean W. <dea...@so...>]

On 8/23/11 10:34 AM, Cartwright, Ken wrote:
> Hi Dean,
>
> Thanks for the examples.  I have used the Add Dest Group and the Get
> Dest Group request examples you've provided within the examples
> section of the SPPP SOAP "Transport" document.  Can the team also
> provide the corresponding _response_ SOAP messages for the Add Dest
> Group and the Get Dest Group examples?  I'd like to include the
> example requests and the corresponding example responses in the
> document.

Sure. Or you can use the free SoapUI tool to send your example requests 
to our test/dev server at:

http://openspp.softarmor.com:8080/OpenSPPService/services/spppPort


SoapUI will let you copy-and-paste the response string directly into 
something else.

I'll paste some samples, which will probably get linewrapped oddly.


AddDestGrpRqst Request

<soapenv:Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppp:base:1">
    <soapenv:Header/>
    <soapenv:Body>
       <urn:spppUpdateRequest 
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 
xmlns="urn:ietf:params:xml:ns:sppp:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <!--Optional:-->
          <urn:clientTransId>888</urn:clientTransId>
          <!--Optional:-->
          <urn:minorVer>4</urn:minorVer>
          <!--1 or more repetitions:-->
          <urn:rqst xsi:type="ns1:AddDestGrpRqstType" 
xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1">
  	<destGrp>
		<ns1:rant>rant2</ns1:rant>
		<dgName>DEST_GRP_SPPP_5</dgName>
	</destGrp>
	  </urn:rqst>
       </urn:spppUpdateRequest>
    </soapenv:Body>
</soapenv:Envelope>

AddDestGrpRqst Response

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
       <spppUpdateResponse xmlns="urn:ietf:params:xml:ns:sppp:base:1">
          <clientTransId>888</clientTransId>
 
<serverTransId>84d1bbb6-ec8e-4381-b936-1ba2d235aee3</serverTransId>
          <overallResult>
             <code>1000</code>
             <msg>Overall Success</msg>
          </overallResult>
          <rqstObjResult>
             <code>1000</code>
             <msg>Succeeded</msg>
             <rqstObj xsi:type="AddDestGrpRqstType" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <destGrp>
                   <rant>rant2</rant>
                   <dgName>DEST_GRP_SPPP_5</dgName>
                </destGrp>
             </rqstObj>
          </rqstObjResult>
       </spppUpdateResponse>
    </soap:Body>
</soap:Envelope>


GetDestGrpsRqst Request (for non-existent group)

<soapenv:Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppp:base:1">
    <soapenv:Header/>
    <soapenv:Body>
       <urn:spppQueryRequest 
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 
xmlns="urn:ietf:params:xml:ns:sppp:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <urn:rqst xsi:type="ns1:GetDestGrpsRqstType" 
xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1">
             <urn:objKey>
                <urn:rant>rant2</urn:rant>
                <urn:name>DEST_GRP_SSP3_2</urn:name>
             </urn:objKey>
          </urn:rqst>
         </urn:spppQueryRequest>
    </soapenv:Body>
</soapenv:Envelope>



GetDestGrpsRqst Response (for non-existent group)

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
       <spppQueryResponse xmlns="urn:ietf:params:xml:ns:sppp:base:1">
          <overallResult>
             <code>2105</code>
             <msg>Object Does Not Exist</msg>
          </overallResult>
       </spppQueryResponse>
    </soap:Body>
</soap:Envelope>


GetDestGrps Request (for existing group, created by above Add request)

<soapenv:Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppp:base:1">
    <soapenv:Header/>
    <soapenv:Body>
       <urn:spppQueryRequest 
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 
xmlns="urn:ietf:params:xml:ns:sppp:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
           <urn:rqst xsi:type="ns1:GetDestGrpsRqstType" 
xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1">
             <urn:objKey>
                <urn:rant>rant2</urn:rant>
                <urn:name>DEST_GRP_SPPP_5</urn:name>
             </urn:objKey>
          </urn:rqst>
         </urn:spppQueryRequest>
    </soapenv:Body>
</soapenv:Envelope>

GetDestGrpsRqst Response (for existing group)

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
       <spppQueryResponse xmlns="urn:ietf:params:xml:ns:sppp:base:1">
          <overallResult>
             <code>1000</code>
             <msg>Succeeded</msg>
          </overallResult>
          <resultSet xsi:type="DestGrpType" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
             <cDate>2011-08-23T00:00:00.000Z</cDate>
             <mDate>2011-08-23T00:00:00.000Z</mDate>
             <dgName>DEST_GRP_SPPP_5</dgName>
          </resultSet>
       </spppQueryResponse>
    </soap:Body>
</soap:Envelope>


DelDestGrpRqst Request (for existing group_

<soapenv:Envelope 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:urn="urn:ietf:params:xml:ns:sppp:base:1">
    <soapenv:Header/>
    <soapenv:Body>
       <urn:spppUpdateRequest 
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd" 
xmlns="urn:ietf:params:xml:ns:sppp:base:1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <!--Optional:-->
          <urn:clientTransId>777</urn:clientTransId>
          <!--Optional:-->
          <urn:minorVer>4</urn:minorVer>
          <!--1 or more repetitions:-->
          <urn:rqst xsi:type="ns1:DelDestGrpRqstType" 
xmlns:ns1="urn:ietf:params:xml:ns:sppp:base:1">
              <urn:objKey>
                <urn:rant>rant2</urn:rant>
                <urn:name>DEST_GRP_SPPP_5</urn:name>
             </urn:objKey>
	  </urn:rqst>
       </urn:spppUpdateRequest>
    </soapenv:Body>
</soapenv:Envelope>

DelDestGrpRqst response (for existing group):

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
       <spppUpdateResponse xmlns="urn:ietf:params:xml:ns:sppp:base:1">
          <clientTransId>777</clientTransId>
 
<serverTransId>40234fa0-7e4f-43a4-9884-35e0e3fb0da1</serverTransId>
          <overallResult>
             <code>1000</code>
             <msg>Overall Success</msg>
          </overallResult>
          <rqstObjResult>
             <code>1000</code>
             <msg>Succeeded</msg>
             <rqstObj xsi:type="DelDestGrpRqstType" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
                <objKey>
                   <rant>rant2</rant>
                   <name>DEST_GRP_SPPP_5</name>
                </objKey>
             </rqstObj>
          </rqstObjResult>
       </spppUpdateResponse>
    </soap:Body>
</soap:Envelope>

Oddly enough, DelDestGrpRqst keeps returning happy response for deletion 
of groups that don't exist. Not sure that's right.

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Cartwright, K. <kca...@tn...>]

Hi Dean,

Thanks for the examples.  I have used the Add Dest Group and the Get Dest Group request examples you've provided within the examples section of the SPPP SOAP "Transport" document.  Can the team also provide the corresponding _response_ SOAP messages for the Add Dest Group and the Get Dest Group examples?  I'd like to include the example requests and the corresponding example responses in the document.

Thank You.

-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Friday, August 12, 2011 2:48 PM
To: Cartwright, Ken
Cc: ope...@li...
Subject: Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server


On Aug 12, 2011, at 8:32 AM, Cartwright, Ken wrote:

> Btw,
>
> Dean, can you or one of the developers please send me 5 or 6 examples of the stringified SOAP messages that you are sending to the server.  We need them to include as examples in the "transport" document.


We're accumulating test messages in our SVN tree at:

http://openspp.svn.sourceforge.net/viewvc/openspp/OpenSPP-SOAPUI/trunk/SOAP%20UI/


We should be adding several additional transaction types over the next week or so. I think the developers have a few messages they haven't checked in yet.

Oddly enough, one of the requests I had recently from developers was "more examples!" ....


--
Dean

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.

Re: [OpenSPP-project] Can we have a technical feedback session this week?

[Dean W. <dea...@so...>]

On Aug 17, 2011, at 8:27 AM, Cartwright, Ken wrote:

> I think doing it during the normal team call Thursday morning would be best, 10am eastern time.

That sounds good to me. I didn't actually know the design team was meeting at the same time as the coding team on a regular basis.

--
Dean

Re: [OpenSPP-project] Can we have a technical feedback session this week?

[Cartwright, K. <kca...@tn...>]

I think doing it during the normal team call Thursday morning would be best, 10am eastern time.

-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Tuesday, August 16, 2011 8:39 PM
To: ope...@li...
Subject: [OpenSPP-project] Can we have a technical feedback session this week?


I'm thinking Vijay is still out of circulation in India, but it would still be good to get Jeremy together with the protocol authors, esp. Ken and Syed.

What do our schedules look like?

Can we make Thursday morning US Mountain time work? Pehaps 0700 MDT, 0800 CDT, 0900 EDT, and 1300 UST?

Or perhaps an hour later?

--
Dean

------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
OpenSPP-project mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openspp-project

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.

[OpenSPP-project] Can we have a technical feedback session this week?

[Dean W. <dea...@so...>]

I'm thinking Vijay is still out of circulation in India, but it would still be good to get Jeremy together with the protocol authors, esp. Ken and Syed.

What do our schedules look like?

Can we make Thursday morning US Mountain time work? Pehaps 0700 MDT, 0800 CDT, 0900 EDT, and 1300 UST? 

Or perhaps an hour later?

--
Dean

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Dean W. <dea...@so...>]

On Aug 12, 2011, at 8:32 AM, Cartwright, Ken wrote:

> Btw,
> 
> Dean, can you or one of the developers please send me 5 or 6 examples of the stringified SOAP messages that you are sending to the server.  We need them to include as examples in the "transport" document.


We're accumulating test messages in our SVN tree at:

http://openspp.svn.sourceforge.net/viewvc/openspp/OpenSPP-SOAPUI/trunk/SOAP%20UI/


We should be adding several additional transaction types over the next week or so. I think the developers have a few messages they haven't checked in yet.

Oddly enough, one of the requests I had recently from developers was "more examples!" ....


--
Dean

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Dean W. <dea...@so...>]

On Aug 12, 2011, at 10:17 AM, Cartwright, Ken wrote:

> Hi Dean,
> 
> As you allude to in your comments below, the XSD relies on extension of based types (inheritance), which then also results in polymorphism (you will see in the XSD the abstract base types are tagged with "abstract="true").  For a few brief write-ups on what this really means from an XML/XSD perspective please google this "Inheritance Polymorphism Abstract XSD" and follow some of the links (like "Inheritance & Polymorphism", "Web services tip:  Use Polym...", etc.

It just makes for tricky coding in gSOAP. Might make for tricky coding in java, too, but that's not my place to comment on.

There is a certain lack of orthogonality on names in the current schema that may be related to the inheritance.

For example, with a DestGrp transaction: an Add request puts the dest group name in a "name" element, and the response puts it in a "dgName" element.


Personally, I'd like to see the same objects going in on an Add that come back  out on a Get. 

--
Dean

Re: [OpenSPP-project] Report on OpenSPP Demo Session, August 12, 2011

[Cartwright, K. <kca...@tn...>]

Hi Dean,

I got pulled into another meeting.  Sorry I could not attend.  And yes, I will attend next week.

Ken

-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Friday, August 12, 2011 11:04 AM
To: ope...@li...
Subject: [OpenSPP-project] Report on OpenSPP Demo Session, August 12, 2011

We had a scheduled demo of the OpenSPP server today. Several persons received priority interrupts, leaving us without "stakeholders" for the demo.

Consequently, Jeremy and I turned the demo session a bit sideways, and explored some forced error conditions (like what happens at the server level when the database has gone missing).  This turned up a couple of interesting bugs, which I'm in the process of adding to our tracker.

We also noted several drop-outs in the "join.me" screen sharing service.  An alternative is required.

All in all it was a useful session, but arguably didn't achieve the key process-management checkpoint of "demo to stakeholders".


Should we reschedule next week? Or change our process?

--
Dean
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
OpenSPP-project mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openspp-project

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.

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Cartwright, K. <kca...@tn...>]

Hi Dean,

As you allude to in your comments below, the XSD relies on extension of based types (inheritance), which then also results in polymorphism (you will see in the XSD the abstract base types are tagged with "abstract="true").  For a few brief write-ups on what this really means from an XML/XSD perspective please google this "Inheritance Polymorphism Abstract XSD" and follow some of the links (like "Inheritance & Polymorphism", "Web services tip:  Use Polym...", etc.

Ken



-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Thursday, August 11, 2011 11:08 PM
To: ope...@li...
Subject: [OpenSPP-project] First pass at gSOAP client for OpenSPP server


In the interest of experimentation, I tried whacking together a very
minimal client to do a GetDestGrps transaction, in C++ using gSOAP.

I had no difficulties using the gSOAP tools with the WSDL and XSD  files
to generate stubs.

I'll confess I'm not a great C++ coder. I think I last wrote commercial
code in C++ in 1995, and that was before STL. It might have even been
before templates ... so my code is a "brute force" experiment. Even the
target string and URI are hard-coded for now.

I am able to use the code to query for an existing destination group and
retrieve cTime and mTime along with appropriate status codes. I haven't
been able to retrieve the rant from the API.

This may well be just weak C++ theory on my part.

But the problem I'm having seems to be related to inheritance in the
schema.

It looks like our schema was designed to be able to return multiple
record types in the same response. Each response record has a SoapType
field that tells us what it really is. That, however, causes problems in
gSOAP, as different records types have different sizes (making vectors
work funny), and one has to jump through a couple of hoops to type-check
and recast pointers at run-time.

The spppQueryRequest produced by gSOAP returns a vector of BasicObjType.
So, iteration across it is type-safed to the BasicObjType. But the rant
is in the DestGrpType derived from BasicObjType, forcing one to cast the
iterator to get the compiler to allow assignment. What I'm doing here
compiles, but I get a null rant out of it (for a query that works with
SoapUI).

Anyhow, here's the code, if you want to play with it. The makefile
presumes the mysoap.cpp file, the wsdl, and the xsd are all in the same
directory.

--
Dean Willis

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.

[OpenSPP-project] Report on OpenSPP Demo Session, August 12, 2011

[Dean W. <dea...@so...>]

We had a scheduled demo of the OpenSPP server today. Several persons received priority interrupts, leaving us without "stakeholders" for the demo.

Consequently, Jeremy and I turned the demo session a bit sideways, and explored some forced error conditions (like what happens at the server level when the database has gone missing).  This turned up a couple of interesting bugs, which I'm in the process of adding to our tracker.

We also noted several drop-outs in the "join.me" screen sharing service.  An alternative is required.

All in all it was a useful session, but arguably didn't achieve the key process-management checkpoint of "demo to stakeholders".


Should we reschedule next week? Or change our process?

--
Dean

[OpenSPP-project] Revised bridge info for demo

[Dean W. <dea...@so...>]

Had to restart join.me after all, so the codes changed:

www.join.me

ID/access code:   286-456-836#

Bridge still +1 951 266 5900

--
Dean

[OpenSPP-project] Info for demo

[Dean W. <dea...@so...>]

http://www.join.me

Code 247-430-788

Bridge number: +1 951 266 5900

--
Dean

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Dean W. <dea...@so...>]

On Aug 12, 2011, at 8:29 AM, Cartwright, Ken wrote:

> Hi Dean,
> 
> Your C++ code looks fine.  And if that code is not receiving a value for the rant then I'd first suspect that there is a bug in the server side code such tat it is not being populated.
> 


Thanks!

However, the SoapUI tester returns a RANT on the same query .... more digging required.

--
Dean

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Cartwright, K. <kca...@tn...>]

Btw,

Dean, can you or one of the developers please send me 5 or 6 examples of the stringified SOAP messages that you are sending to the server.  We need them to include as examples in the "transport" document.

Thank You.

-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Thursday, August 11, 2011 11:08 PM
To: ope...@li...
Subject: [OpenSPP-project] First pass at gSOAP client for OpenSPP server


In the interest of experimentation, I tried whacking together a very
minimal client to do a GetDestGrps transaction, in C++ using gSOAP.

I had no difficulties using the gSOAP tools with the WSDL and XSD  files
to generate stubs.

I'll confess I'm not a great C++ coder. I think I last wrote commercial
code in C++ in 1995, and that was before STL. It might have even been
before templates ... so my code is a "brute force" experiment. Even the
target string and URI are hard-coded for now.

I am able to use the code to query for an existing destination group and
retrieve cTime and mTime along with appropriate status codes. I haven't
been able to retrieve the rant from the API.

This may well be just weak C++ theory on my part.

But the problem I'm having seems to be related to inheritance in the
schema.

It looks like our schema was designed to be able to return multiple
record types in the same response. Each response record has a SoapType
field that tells us what it really is. That, however, causes problems in
gSOAP, as different records types have different sizes (making vectors
work funny), and one has to jump through a couple of hoops to type-check
and recast pointers at run-time.

The spppQueryRequest produced by gSOAP returns a vector of BasicObjType.
So, iteration across it is type-safed to the BasicObjType. But the rant
is in the DestGrpType derived from BasicObjType, forcing one to cast the
iterator to get the compiler to allow assignment. What I'm doing here
compiles, but I get a null rant out of it (for a query that works with
SoapUI).

Anyhow, here's the code, if you want to play with it. The makefile
presumes the mysoap.cpp file, the wsdl, and the xsd are all in the same
directory.

--
Dean Willis

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.

Re: [OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Cartwright, K. <kca...@tn...>]

Hi Dean,

Your C++ code looks fine.  And if that code is not receiving a value for the rant then I'd first suspect that there is a bug in the server side code such tat it is not being populated.

Ken

-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Thursday, August 11, 2011 11:08 PM
To: ope...@li...
Subject: [OpenSPP-project] First pass at gSOAP client for OpenSPP server


In the interest of experimentation, I tried whacking together a very
minimal client to do a GetDestGrps transaction, in C++ using gSOAP.

I had no difficulties using the gSOAP tools with the WSDL and XSD  files
to generate stubs.

I'll confess I'm not a great C++ coder. I think I last wrote commercial
code in C++ in 1995, and that was before STL. It might have even been
before templates ... so my code is a "brute force" experiment. Even the
target string and URI are hard-coded for now.

I am able to use the code to query for an existing destination group and
retrieve cTime and mTime along with appropriate status codes. I haven't
been able to retrieve the rant from the API.

This may well be just weak C++ theory on my part.

But the problem I'm having seems to be related to inheritance in the
schema.

It looks like our schema was designed to be able to return multiple
record types in the same response. Each response record has a SoapType
field that tells us what it really is. That, however, causes problems in
gSOAP, as different records types have different sizes (making vectors
work funny), and one has to jump through a couple of hoops to type-check
and recast pointers at run-time.

The spppQueryRequest produced by gSOAP returns a vector of BasicObjType.
So, iteration across it is type-safed to the BasicObjType. But the rant
is in the DestGrpType derived from BasicObjType, forcing one to cast the
iterator to get the compiler to allow assignment. What I'm doing here
compiles, but I get a null rant out of it (for a query that works with
SoapUI).

Anyhow, here's the code, if you want to play with it. The makefile
presumes the mysoap.cpp file, the wsdl, and the xsd are all in the same
directory.

--
Dean Willis

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.

[OpenSPP-project] First pass at gSOAP client for OpenSPP server

[Dean W. <dea...@so...>]

In the interest of experimentation, I tried whacking together a very
minimal client to do a GetDestGrps transaction, in C++ using gSOAP.

I had no difficulties using the gSOAP tools with the WSDL and XSD  files
to generate stubs.

I'll confess I'm not a great C++ coder. I think I last wrote commercial
code in C++ in 1995, and that was before STL. It might have even been
before templates ... so my code is a "brute force" experiment. Even the
target string and URI are hard-coded for now.

I am able to use the code to query for an existing destination group and
retrieve cTime and mTime along with appropriate status codes. I haven't
been able to retrieve the rant from the API.

This may well be just weak C++ theory on my part.

But the problem I'm having seems to be related to inheritance in the
schema.

It looks like our schema was designed to be able to return multiple
record types in the same response. Each response record has a SoapType
field that tells us what it really is. That, however, causes problems in
gSOAP, as different records types have different sizes (making vectors
work funny), and one has to jump through a couple of hoops to type-check
and recast pointers at run-time.

The spppQueryRequest produced by gSOAP returns a vector of BasicObjType.
So, iteration across it is type-safed to the BasicObjType. But the rant
is in the DestGrpType derived from BasicObjType, forcing one to cast the
iterator to get the compiler to allow assignment. What I'm doing here
compiles, but I get a null rant out of it (for a query that works with
SoapUI).

Anyhow, here's the code, if you want to play with it. The makefile
presumes the mysoap.cpp file, the wsdl, and the xsd are all in the same
directory.

-- 
Dean Willis

[OpenSPP-project] Call info for Demo on Friday, August 12, 2011

[Dean W. <dea...@so...>]

We plan to do our Sprint 2 wrapup demo to stakeholders on August 12, 2011 at 0800 MDT, 0900 CDT, 10:00 EDT, 1300 UST.

To demo:

1) Create mySQL schema on a Linux server
2) Check out Java code from Subversion and compile to WAR file
3) Deploy WAR file on Tomcat6, running on a Linux server
4) Use SoapUI to add, verify, and delete destination groups

I plan to use the screen sharing service "join.me" for the demo, and to use a join.me telephone conference bridge for the audio portion.


I'll send out a join.me 9-digit sharing code and US bridge number shortly before the demo.

To access:

1) Browse to www.join.me
2) Enter the 9-digit code dome the email into the "join" box on the right-hand-side of the screen, and click the big green arrow.
3) Dial into the given bridge number and use the 9-digit code as the conference ID.



If Something Bad happens and my Mac crashes during the demo (which hasn't happened lately...), I'll unfortunately have to get a new 9-digit number and phone number, and I'll email that out to the OpenSPPP-project list so you can reconnect. Perils of a free service.

Note that join.me has iPhone and android apps for watching the screen from your phone. I haven't tried them yet, but I'm guessing that this might be a little "squinty" on a little screen.

--
Dean

[OpenSPP-project] Canceled: Proposed OpenSPP technical review talk for today

[Dean W. <dea...@so...>]

I'm afraid we won't have critical mass for the planned technical review call today. Vijay's "day job" advanced his training schedule, Jeremy seems to have lost prep time with a trip to the hospital, and I haven't been able to pull their feedback together sufficiently myself to be able to do it justice.

--
Dean 

Re: [OpenSPP-project] Proposal for Sprint 2 wrapup and demo to stakeholders: Aug 12, technical meeting, August 11

[Cartwright, K. <kca...@tn...>]

Those times are good for me.

Ken

-----Original Message-----
From: Dean Willis [mailto:dea...@so...]
Sent: Friday, August 05, 2011 3:53 PM
To: ope...@li...
Subject: [OpenSPP-project] Proposal for Sprint 2 wrapup and demo to stakeholders: Aug 12, technical meeting, August 11


The OpenSPP development team extended the Sprint 2 cycle to compensate for illness, travel, and a few other delaying factors. But we're now successfully drawing it to a close. Consistent with our development model, that means it's "demo time". We'll use a screen-sharing system to enable remote viewing of the demo.

I'd like to propose Friday, August 12, 0800 MDT for a demo session. (That's  0700 PDT, 0900 CDT,  1300 UST). The demo should take less than 1/2 hour. Then again, I might have lost track of people's time zones.


We also need to have technical conversation to bring in lessons-learned by the developers to the protocol design.  This could be conjoint with the demo, but we might be well served to have it separately. This probably needs to be a two hour call, and it need to be no later than August 12 as one of our developers is off to India for a while on his day job and might be hard to reach.

Would the (US) morning of Thursday, August 11 work for a technical call?

--
Dean




------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
OpenSPP-project mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openspp-project

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.

[OpenSPP-project] Proposal for Sprint 2 wrapup and demo to stakeholders: Aug 12, technical meeting, August 11

[Dean W. <dea...@so...>]

	
The OpenSPP development team extended the Sprint 2 cycle to compensate for illness, travel, and a few other delaying factors. But we're now successfully drawing it to a close. Consistent with our development model, that means it's "demo time". We'll use a screen-sharing system to enable remote viewing of the demo.

I'd like to propose Friday, August 12, 0800 MDT for a demo session. (That's  0700 PDT, 0900 CDT,  1300 UST). The demo should take less than 1/2 hour. Then again, I might have lost track of people's time zones.


We also need to have technical conversation to bring in lessons-learned by the developers to the protocol design.  This could be conjoint with the demo, but we might be well served to have it separately. This probably needs to be a two hour call, and it need to be no later than August 12 as one of our developers is off to India for a while on his day job and might be hard to reach.

Would the (US) morning of Thursday, August 11 work for a technical call?

--
Dean

[OpenSPP-project] OpenSPP Project Status

[Dean W. <dea...@so...>]

The OpenSPP team is wrapping up Sprint 2. Some things are going well, and some things are a bit behind schedule.

Early on, the design team elected to apply a fairly elegant architecture. There's a "web service" layer that runs under Tomcat to bring in SOAP requests and return responses. This layer implements the SOAP protocol layer, parses out the data then passes the various SPPP commands on to a "command processor" layer. The command processor implements all the business logic of the protocol, and uses a "data object" layer to persist the data into or retrieve data from a MySQL relational database. Each layer contains independently testable (using JUnit) classes.


The web service layer is fairly straightforward, as is the data object layer. The command processor is fairly gnarly. The design team elected to use a "command factory" pattern that relies on the inheritance model of Java to allow us to build out one set of commands (we started with Destination Group), then replicate and extend function through inheritance for other commands. The basic idea is that while this makes the first command set harder to build, it should make the follow-on work easier to do. The risk is that this sort of elegant software architecture is much easier to maintain for someone who understands it, but possibly more difficulty to maintain in a distributed-and-voolunteer team model than a "brute force" approach might be.

In practice, it's proven harder than we expected to get the first set of commands fully functional. Team members Jeremy and Mickael are today working with a fully integrated but hand-assembled code base to track down exceptions occurring in the Destination Group operations. We had hoped to have this demonstrable at the end of Sprint 1, and are just now getting close to making it happen.

The next step is to polish up the system assembly process so that it doesn't have to be knitted together by hand into a running system but has a mostly automated build process that can spit out the application image (a web-service archive or WAR file for use with Apache Tomcat) and the base configuration files that will need to be customized by the installer. Once automated build/deployments can happen, it should be a lot easier to start snapping in the code for additional SPPP operations.

A related piece of complexity is managing the third-party components that the code is dependent on. The Java tool chain we're using requires lots of Java archives ( JAR files) for things like database connectivity, logging, testing, formatting SOAP messages, and so on. A minimalist approach would provide our users with a manifest of those JAR files and instructions for where to get them and how to install them before building the OpenSPP package itself. ANother possible model is that we include copies of the required JAR files in our own source tree, such that the WAR file produced from our build process includes the needed JAR files. This has pros and cons -- critically, we'd have to verify that we're compliant with the licensing terms of those components in doing so, AND that we're compliant with applicable export law relating to application cryptography. For example, we have developers in Israel, and even if the crypto library is copied by an Israel-located developer onto our US-based server, checking that code back out again is considered an export and there are legal procedures that must be observed.  We're currently engaged in developing a component manifest and in evaluation of the alternatives.

--
Dean