Services Directory Avatar
  1. OMG Specification

Services Directory — All Issues

  • Acronym: ServD
  • Issues Count: 21
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
SERVD-22 Notation for String (collection) should be explained ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-21 Scope of CTS2 implementation required ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-20 Profile Binding ELS Note context unclear ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-19 Profile Binding Diagram not in Model (EA file) ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-18 Interaction Diagrams missing instance indicator ":" ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-17 The context of the ELS in the Terms and Definitions is unclear ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-16 Component Capability Discovery. It is unclear why this sub-clause is present ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-15 Scope of ServD not clearly defined ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-14 The PagesSearchResult is missing PageSize ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-13 Availability objects CurrentLocalSystemTime is meaningless ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-12 Search Parameter objects for Provider and ServiceSite missing ID fields ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-11 Unable to identify location of RetrieveDetailsURL for newly added records ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-10 Unable to identify location of RetrieveDetailsURL for pending changes ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-9 Vendor names in wsdls need to be removed ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-8 Site, ServiceSite, ServiceSiteProvider Parent Ids missing/not mandatory ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-7 GetReferenceListDetails cannot define which type of interface ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-6 RegisterSearchEndpointForCoverageArea operation does not indicate if a reset is required ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-5 The SearchInputParameters object does not have a CoverageArea property ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-4 There is no RetrieveServiceSiteProvider operation ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-3 ServiceSiteProvider Inconsistent Operation Naming/incorrect return parameters ServD 1.0b1 ServD 1.0 Resolved closed
SERVD-2 RecordRequiringApproval does not have RecordStatus ServD 1.0b1 ServD 1.0 Resolved closed

Issues Descriptions

Notation for String (collection) should be explained

  • Key: SERVD-22
  • Legacy Issue Number: 18674
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    8.5.2.1 Method LocateSearchEndpointsForCoverageArea. Return value specified as "String (collection)", It should be explained that this is a convention to show a Return Result which is an array.
    8.5.2.2 Method GetReferenceListDetails. The signature has a return value of ReferenceListDetail (collection). Is this supposed to be multi-valued (i.e, array). This notation should be explained somewhere. It shows with a [] in the UML diagram in section 8.5.1

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The convention used to explain this was included and diagrams updated to be more clear with respect to cardinality and associations.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Scope of CTS2 implementation required

  • Key: SERVD-21
  • Legacy Issue Number: 18673
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    8.4.1 ServD Locator configuration. States "All of the required TCS2 reference lists must be configured. Is use of CTS2 required for conformance to this specification, and if so, How much of CTS2 is required.

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Additional text is added to better define what components of CTS2 are required.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Profile Binding ELS Note context unclear

  • Key: SERVD-20
  • Legacy Issue Number: 18672
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    8.3 Profile binding. It is unclear why the note regarding ELS under the first diagram is required. ELS does not appear in the figure.

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The ELS is an optional component of the Federation and has its own profile, outside of the ServD Federation

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Profile Binding Diagram not in Model (EA file)

  • Key: SERVD-19
  • Legacy Issue Number: 18671
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    8.3 Profile binding. Are the class diagrams in this subclause included in the EA file? I cannot find them. Where is the source file for these diagrams?

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The EA model file has the profile binding diagram added into it.
    Also the Federation and Coverage areas diagram was not in the EA model file, now it is.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Interaction Diagrams missing instance indicator ":"

  • Key: SERVD-18
  • Legacy Issue Number: 18670
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    .2 Interaction diagrams.
    Each of these diagrams has an invoking component. It is unclear why this is not shown as a type, i.e. why is there not a ":" before the component name?
    Also many of the interface lifelines do not have a ":" before the interface type in the lifeline header.
    The ":" prefix use appears to be inconsistent in its application throughout the Sequence Diagrams in 8.2.
    8.2.1 Provider Search Sequence diagram. the locator lifeline should be labelled ":Locator" rather than "Locator".

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Update the diagrams to be consistent with the use of instance classifiers

  • Updated: Sat, 7 Mar 2015 00:17 GMT

The context of the ELS in the Terms and Definitions is unclear

  • Key: SERVD-17
  • Legacy Issue Number: 18669
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    4. Terms and Definitions. ELS is listed as a term. Is its function limited to computer interface service endpoints?
    Is ServD restricted to physical locations of services provided by people and organizations, or can ServD be used to find Endpoints for machine interfaces offering computerized services?

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Revise the text to more clearly describe the ELS functionality

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Component Capability Discovery. It is unclear why this sub-clause is present

  • Key: SERVD-16
  • Legacy Issue Number: 18668
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    ELS does not seem to be included in any of the specified components. Why is this text not just included in Annex A?
    Also, i.e. ELS related to other web services and Open distributed processing interface directory functions, such as ODP/CORBA Trader and UDDI?

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The text was extended to better describe the context.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Scope of ServD not clearly defined

  • Key: SERVD-15
  • Legacy Issue Number: 18667
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    1. Scope - first sentence implies that ServD only supports location information. What about service characteristics?

    Doesn't ServD support all information about the providers, organizations, sites and their services and relevant characteristics. Both for consumption by both People and computers.
    Need to reword to be clearer.

  • Reported: ServD 1.0b1 — Mon, 15 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Reword the text to more clearly articulate the scope of the directory standard

  • Updated: Sat, 7 Mar 2015 00:17 GMT

The PagesSearchResult is missing PageSize

  • Key: SERVD-14
  • Legacy Issue Number: 18665
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    If the Service decides that the requested page-size was not acceptable and uses a different page size to the one requested (I.e. the caller put in millions to try and "dump" the database, and service decides that it wants to only accept 100 as highest number) then the caller has no idea what the actual page size used was.
    (Except maybe to see that there are more pages of data, and that the number of items is different to what was expected)

  • Reported: ServD 1.0b1 — Sun, 14 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The addition of a PageSize property on the PagesSearchResult object resovles this issue.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Availability objects CurrentLocalSystemTime is meaningless

  • Key: SERVD-13
  • Legacy Issue Number: 18664
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    The Availability Object has a CurrentLocalSystemTime property which is not usefull for handling timezones.
    The specification need to ensure that timezone information is correctly handled on the AvailableAt property.

    This could be handled by ensuring that all callers only interact with the ServD system using UTC, and all dates in the system are assumed to be UTC (or converted to UTC) for processing/storage/return values

  • Reported: ServD 1.0b1 — Sun, 14 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Remove the CurrentLocalSystemTime property from the Availability object as specified in Section 8.8.3 on Page 79. All the date-time properties must have the timezone specified and handled accordingly. The Directory must process all date-times in UTC, converting where required.
    The description for the AvailableAt property in this object is also unclear, need to reword it.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Search Parameter objects for Provider and ServiceSite missing ID fields

  • Key: SERVD-12
  • Legacy Issue Number: 18663
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    The Search Parameter Object ProviderSearchParameter is missing the Provider ID field to permit the direct locating of a specific record.
    Also missing is the ServiceSiteID on the ServiceSiteSearchParameter object.
    These fields are required to permit the location of a specific record to then be able to locate the appropriate RetrieveDetails URL to get the complete picture.
    Issue is observed in the overview diagram on page 78 and also the object definitions on pages 83 and 87

  • Reported: ServD 1.0b1 — Sat, 13 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    In order to be able to specify a search for an item exactly as requested the ProviderSearchParameter and ServiceSiteSearchParameter objects have add the appropriate Ids added to them, and the parameters diagram updated.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Unable to identify location of RetrieveDetailsURL for newly added records

  • Key: SERVD-11
  • Legacy Issue Number: 18662
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    When you add a new organisation (or other record) the return object does not contain the location of a retrieve details service that can provide the complete object as added.

  • Reported: ServD 1.0b1 — Sat, 13 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    In order to satisfy this requirement the generic RecordResult object that is the base class for both the Update and Delete result is extended to include the URL.
    Brian: I believe this is on the correct object as the delete may require moderation and thus the object will still exist, and hence the retrieve details URL is valid.

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Unable to identify location of RetrieveDetailsURL for pending changes

  • Key: SERVD-10
  • Legacy Issue Number: 18654
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    When retrieving the list of changes that are available the results do not indicate the location of a retrieve details service that can provide the complete object, and also missing is the "parent" object which can be used to locate the entity pending the change (specifically where there is no Retrieve method for the entity, such as an address or contact point, as they are in the context of a provider, or organization)

  • Reported: ServD 1.0b1 — Fri, 12 Apr 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The RecordRequiringApproval Data structure is to be extended to include 2 new properties, one for the RetrieveDetailsURL, and another for the Parent Records index.
    To make this change more apparent the diagram in section 8.2.6 on page 29 on the Reject Change Workflow is modified to separate the MaintainableServD Core into the 2 interfaces to show which interface is required to be called

  • Updated: Sat, 7 Mar 2015 00:17 GMT

Vendor names in wsdls need to be removed

  • Key: SERVD-9
  • Legacy Issue Number: 18780
  • Status: closed  
  • Source: Thematix Partners LLC ( Doug Tolbert)
  • Summary:

    Machine readable documents dtc/13-05-06 thru dtc/13-05-09, inclusive, have XML namespace definitions containing vendor names. Please remove them.

  • Reported: ServD 1.0b1 — Mon, 17 Jun 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The namespaces in question were from Microsoft and introduced as a result of the way in which the Visual Studio toolset creates the wsdl files for the following datatypes:
    string[]
    (an array of strings) This is output as an ArrayOfString type in the Microsoft namespace.
    This was changed to be a local datatype and not one from the Microsoft namespace (although it is exactly the same definition)
    enum where the numeric values assigned to the values were not sequential from 0 some Microsoft WSDL extensions were included to capture these values in the WSDL.
    All enumerated types were modified to remove the specific numeric values and therefore no longer have the Microsoft extensions required.

  • Updated: Fri, 6 Mar 2015 23:39 GMT

Site, ServiceSite, ServiceSiteProvider Parent Ids missing/not mandatory

  • Key: SERVD-8
  • Legacy Issue Number: 18720
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    The objects Site and ServiceSite do not have their parent’s ID included in the object structure. Hence when calling retrieve details the object does not have the information as to what Id it’s parent has (unless it already knew via the search call or previous history ­ it is not explicitly included).

    The ServiceSiteProvider record’s ServiceSiteId field is not marked as mandatory and the ProviderId is marked as mandatory. This is inconsistent.

  • Reported: ServD 1.0b1 — Thu, 16 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Add the OrganizationId property to the Site record, add the SiteId property to the ServiceSite record.
    The ServiceSiteId field on the ServiceSiteProvider record will no longer be marked as mandatory to be consistent with the others.

    As a result of this change, the Id for the context of the Add is no redundant in the AddSite and AddServiceSite Maintenance Operations.

  • Updated: Fri, 6 Mar 2015 23:37 GMT

GetReferenceListDetails cannot define which type of interface

  • Key: SERVD-7
  • Legacy Issue Number: 18713
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    When calling the GetReferenceListDetails interface, there is no way to determine if the caller wants to know about REST or WSDL style interfaces.
    This needs to be passed in as a parameter to the call.

    probably of type ImplementationProfile from the CTS2 CoreService

  • Reported: ServD 1.0b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    A new parameter is added to the GetReferenceListDetails operation to permit the caller to indicate what type of interface is desired, and some supportive text in the Locator Profile Binding (section 8.4.1) to describe how this is to used.

    It was decided to use a string instead of the enumeration from CTS2 as it will be more flexible to support other types of reference list implementations other than those provided by the current version of CTS2.

  • Updated: Fri, 6 Mar 2015 23:37 GMT

RegisterSearchEndpointForCoverageArea operation does not indicate if a reset is required

  • Key: SERVD-6
  • Legacy Issue Number: 18712
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    When calling the RegisterSearchEndpointForCoverageArea operation there is no definition in the specification for what the implementation should do with any coverage areas not included in the call (delete them, or leave them alone).
    The return code includes a summary of items added, updated, and deleted.
    So the implication is that it should delete them, but it isn't defined.

    Suggest that an additional parameter be added to make that decision explicit.

  • Reported: ServD 1.0b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Add the new parameter to the RegisterSearchEndpointForCoverageArea operation as described. This then provides the caller of the operation a way to indicate what behavior the Locator should have.

  • Updated: Fri, 6 Mar 2015 23:37 GMT

The SearchInputParameters object does not have a CoverageArea property

  • Key: SERVD-5
  • Legacy Issue Number: 18711
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    Without the CoverageArea property being in the search parameters the federated search is not possible as shown in the diagram in section 8.2.2 Provider Search (Federated).
    The implementation does not have a coverage area to interrogate the federation as to which directories to issue the search to.

    As this is the primary search field it should be in the main search parameter object: SearchInputParameters

  • Reported: ServD 1.0b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Include a new property “CoverageAreaCode” of type string on the SearchInputParameters as described.

  • Updated: Fri, 6 Mar 2015 23:37 GMT

There is no RetrieveServiceSiteProvider operation

  • Key: SERVD-4
  • Legacy Issue Number: 18710
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    To be more consistent with the other RetrieveDetails and Maintenance interfaces there should be a routine that directly reads the ServiceSiteProvider record from its ID.
    This enables callers to verify the status of a link in a more direct way.

  • Reported: ServD 1.0b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Include the RetreiveServiceSiteProvider Operation

  • Updated: Fri, 6 Mar 2015 23:37 GMT

ServiceSiteProvider Inconsistent Operation Naming/incorrect return parameters

  • Key: SERVD-3
  • Legacy Issue Number: 18700
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    The ServiceSiteProvider Maintenance functions for Add and Update do not return an array of results where they should, and they the name is not in the same format as for all other operations.

    Should be renamed to:
    ServiceSiteProviderAdd
    and
    ServiceSiteProviderUpdate

    (existing implementations could continue with the old name and return parameters for compatibility)

  • Reported: ServD 1.0b1 — Wed, 8 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    Make the function name and return parameter changes as recommended.

  • Updated: Fri, 6 Mar 2015 23:37 GMT

RecordRequiringApproval does not have RecordStatus

  • Key: SERVD-2
  • Legacy Issue Number: 18694
  • Status: closed  
  • Source: HealthConnex ( Brian Postlethwaite)
  • Summary:

    You cannot tell the status of a record that requires approval apart from in the description or summary fields, hence a caller is not able to elegantly present the information to a user for actioning

  • Reported: ServD 1.0b1 — Thu, 2 May 2013 04:00 GMT
  • Disposition: Resolved — ServD 1.0
  • Disposition Summary:

    The RecordRequiringApproval entity was extended to have the Record Status Property

  • Updated: Fri, 6 Mar 2015 23:37 GMT