FWD » Core Development » Base Language

Priority features:

Statements:

CREATE-SOAP-HEADER
CREATE-SOAP-HEADER-ENTRYREF

ATTRIBUTES:

SOAP-FAULT-STRING
ERROR-STATUS:ERROR-OBJECT-DETAIL

METHODS:

add-header-entry()
set-must-understand()
set-node()

The full set of related features:

SOAP Header Object:

STATEMENTS: CREATE-SOAP-HEADER
ATTRIBUTES: NUM-HEADER-ENTRIES, INSTANTIATING-PROCEDURE, UNIQUE-ID
METHODS: add-header-entry(), get-header-entry()

SOAP Header Entryref Object:

STATEMENTS: CREATE-SOAP-HEADER-ENTRYREF
ATTRIBUTES: ACTOR, LOCAL-NAME, INSTANTIATING-PROCEDURE, MUST-UNDERSTAND, NAMESPACE-URI, UNIQUE-ID
METHODS: delete-header-entry(), get-node(), get-serialized(), set-actor(), set-must-understand(), set-node(), set-serialized()

SOAP Fault Object:

ATTRIBUTES: INSTANTIATING-PROCEDURE, SOAP-FAULT-ACTOR, SOAP-FAULT-CODE, SOAP-FAULT-DETAIL, SOAP-FAULT-STRING
ERROR-OBJECT-DETAIL attribute on ERROR-STATUS system handle

SOAP Fault Detail Object:

ATTRIBUTES: INSTANTIATING-PROCEDURE
METHODS: get-node(), get-serialized()

Attributes/methods common to multiple resources:
- local-name: SOAP-header-entryref object handle, X-noderef object handle
- namespace-uri: Buffer object handle, ProDataSet object handle, SOAP-header-entryref object handle, Temp-table object handle, X-document object handle, X-noderef object handle
- get-node(): SOAP-fault-detail object handle, SOAP-header-entryref object handle
- get-serialized(): SOAP-fault-detail object handle, SOAP-header-entryref object handle
- INSTANTIATING-PROCEDURE: all
- UNIQUE-ID: as I recal, there is already an interface for this

SOAP Header Object (TYPE = SOAP-HEADER):
- STATEMENTS: CREATE SOAP-HEADER handle [ IN WIDGET-POOL widget-pool-name ]
- ATTRIBUTES: NUM-HEADER-ENTRIES(r/o, integer), INSTANTIATING-PROCEDURE, UNIQUE-ID
- METHODS: <logical> add-header-entry(<handle>), <logical> get-header-entry(<handle>, <index>)

SOAP Header Entryref Object (TYPE = SOAP-HEADER-ENTRYREF):
- STATEMENTS: CREATE SOAP-HEADER-ENTRYREF hshEntry [ IN WIDGET-POOL widget-pool-name ]
- ATTRIBUTES: ACTOR(r/o, character), LOCAL-NAME (r/o, character), INSTANTIATING-PROCEDURE, MUST-UNDERSTAND(r/o, logical), NAMESPACE-URI(r/w, character), UNIQUE-ID
- METHODS: <logical> delete-header-entry(), <logical> get-node(<x-node-ref>), <longchar> get-serialized(), <logical> set-actor(), <logical> set-must-understand(<logical>), <logical> set-node(<x-node-ref>), <logical> set-serialized(<longchar>)

SOAP Fault Object (TYPE = SOAP-FAULT):
- ATTRIBUTES: INSTANTIATING-PROCEDURE, SOAP-FAULT-ACTOR(r/o, character), SOAP-FAULT-CODE(r/o, character), SOAP-FAULT-DETAIL(r/o, handle), SOAP-FAULT-STRING(r/o, character)
- ERROR-OBJECT-DETAIL(r/o, handle) attribute on ERROR-STATUS system handle

SOAP Fault Detail Object (TYPE = SOAP-FAULT-DETAIL):
- ATTRIBUTES: INSTANTIATING-PROCEDURE
- METHODS: <logical> get-node(<x-node-ref>), <longchar> get-serialized()

• SOAPFactory - class with APIs for CREATE SOAP-HEADER and CREATE SOAP-HEADER-ENTRYREF statements
• SOAPEntity - interface with APIs for get-node and get-serializable methods, common for SOAP-fault-detail object handle, SOAP-header-entryref object handle
  

  - METHODS: <logical> get-node(<x-node-ref>), <longchar> get-serialized()
  

• SOAPFault - interface with APIs for SOAP Fault Object, with SOAPFaultImpl the implementation class. Defines these attrs/methods:
  

  - ATTRIBUTES: SOAP-FAULT-ACTOR(r/o, character), SOAP-FAULT-CODE(r/o, character), SOAP-FAULT-DETAIL(r/o, handle), SOAP-FAULT-STRING(r/o, character)
  

• SOAPFaultDetail - interface which defines the SOAP Fault Detail Object (although we can skip this as all methods for this object ar in SOAPEntity, and we can let the SOAPFaultDetailImpl class defining the resource)
• SOAPHeader - interface with APIs for these:
  

  - ATTRIBUTES: NUM-HEADER-ENTRIES(r/o, integer)
  - METHODS: <logical> add-header-entry(<handle>), <logical> get-header-entry(<handle>, <index>)
  

• SOAPHeaderDEtails - interface (extending SOAPEntity) with APIs for these:
  

  - ATTRIBUTES: ACTOR(r/o, character), MUST-UNDERSTAND(r/o, logical)
  - METHODS: <logical> delete-header-entry(), <logical> set-actor(), <logical> set-must-understand(<logical>), <logical> set-node(<x-node-ref>), <logical> set-serialized(<longchar>)
  

• UNIQUE-ID, INSTATING-PROCEDURE are not touched.
• local-name (for SOAP-header-entryref object handle, X-noderef object handle) - I see that our X-noderef impl doesn't define it either, so I've ignore it
• namespace-uri (Buffer object handle, ProDataSet object handle, SOAP-header-entryref object handle, Temp-table object handle, X-document object handle, X-noderef object handle) - I see that is not touched by any other implemented resource, so I've ignore it
• SOAP Header and SOAP Header EntryRef both need access to NAME and PRIVATE-DATA attributes, but these are in CommonHandleChain (together with next-/prev-sibling). These need to be moved in a separate interface (and also extract them from HandleChain in a separate superclass).

I like the plan.

In regard to the "common" attributes (UNIQUE-ID, INSTANTIATING-PROCEDURE, LOCALNAME, NAMESPACE-URI, NAME, PRIVATE-DATA), the main update can ignore these. But after that is done, go ahead and build an update that properly handles these for all of the current resource types. I understand that will require some minor refactoring and creation of new interfaces (and implementing those in the right places).

I will review it later today. Be prepared to merge it Monday morning with the pending 10174-10176 that is currently being tested.

the documentation for some methods (like GET-NODE) states that "Returns a handle to an X-noderef" but it actually returns a logical value, and I think the X-noderef instance (in this case) is set to the passed handle var

In each case where we are doing something different that the 4GL documentation, please make a statement like this:

"This method returns a logical even though the Progress 4GL documentation explicitly states otherwise. Actual working code has proven that the original documentation is incorrect. This implementation matches the actual runtime behavior of the 4GL."

SOAPEntity doesn't have its own implementation class (to allow SOAPFaultFetail and SOAPHeaderEntry to extend it), because SOAPFaultDetail doesn't have NAME attribute, while SOAPHeaderEntry has (so a compromise needs to be made).

Aren't we about to move the NAME attribute (along with some other things like PRIVATE-DATA...) to a separate set of common interfaces? Just like we have Connectable, we would have the minimum set of common interfaces that can be implemented as needed.

In each case where we are doing something different that the 4GL documentation, please make a statement like this:

OK

Aren't we about to move the NAME attribute (along with some other things like PRIVATE-DATA...) to a separate set of common interfaces? Just like we have Connectable, we would have the minimum set of common interfaces that can be implemented as needed.

I was refering to the fact that we can't put the implementation of these methods (get-node and get-serialized) in the same super class, as a class can't extend two super-classes (and SOAPHeaderEntryImpl would need in this case to extend two superclasses, one for name/private-data and one for these attributes).

OK, I understand now. Yes, this is an unfortunate side effect of our implementation. But at least the duplicate implementations are only needed in the minority of cases (most attributes are resource-specific).

Code Review Feedback:

1. The ErrorManager.WorkArea.soapFault member needs javadoc.

2. For int parameters to methods like getHeaderEntry(handle target, int idx), please switch these to double instead. I'm pretty sure that Progress would allow an index of 11.0 (or even 1.4111) to be passed to these methods. Your use of NumberType solves this for wrapper types, but by using double we can handle dec_literal and num_literal in a single signature.

3. Should we define new signatures using Text instead of character to "get ahead" of the coming work of making longchar interoperate?

1. The ErrorManager.WorkArea.soapFault member needs javadoc.

OK

2. For int parameters to methods like getHeaderEntry(handle target, int idx), please switch these to double instead. I'm pretty sure that Progress would allow an index of 11.0 (or even 1.4111) to be passed to these methods. Your use of NumberType solves this for wrapper types, but by using double we can handle dec_literal and num_literal in a single signature.

For these, 4GL allows only integer and int64 values (confirmed by testing).

3. Should we define new signatures using Text instead of character to "get ahead" of the coming work of making longchar interoperate?

Same, from testing, 4GL doesn't allow a longchar for character or character (event character constant) for longchar, in the case of these SOAP methods.

For these, 4GL allows only integer and int64 values (confirmed by testing).

OK. Please use long instead of int and add javadoc to explain that based on testing, only integer and int64 values are allowed in the 4GL.

Same, from testing, 4GL doesn't allow a longchar for character or character (event character constant) for longchar, in the case of these SOAP methods.

OK. Please add javadoc comment to explain this.

The idea of adding the javadoc is to make it clear to future readers that:
- these limitations are intentional
- that these limitations duplicate the 4GL limitations

I am OK with the update. The only thing I suggest is that the new javadoc entries have an unmatched trailing double quote character. Search on 4GL." to find these.

I don't see a reason for runtime regression testing on this one. Apply the change in staging, run conversion and confirm that there is no unexpected change. if so, then you will check in next. I've chown'd staging to cas.

I've removed the trailing quotes. The conversion has been started on staging (with previous generated sources backedup).

No changes in generated MAJIC sources, committed to bzr revision 10178.

I've started working on finishing the SOAP Fault support (part of #1645). The SOAP Header support is highly dependent on #2208 - as we need custom services to test it.

All updates and discussions for this task was moved to #1645.