Note: This page is a work in progress and is not currently an official STAR requirement. It is provided for informational purposes only.
A STAR Level 1 conformant transport is the most basic of requirements that need to be implemented. These requirements are here to guarantee that STAR Web Service clients/servers can communicate with each other regardless of the platform they were implemented.
Last rule number used: 1019.
- 1. General
- 1.1 WS-I Compliance
- 1.2 Attachments
- 2. Error Handling
- 2.1 HTTP
- 2.2 SOAP Faults
- 2.3 Application
- 3. WS-Security
- 3.1 General
- 3.2 User Name and Password
1. General
This section covers Chapters 1 - 5 of the STAR Web Services specification. The current rules cover chapters 1 - 3.
1.1 WS-I Compliance
All web services must be compliant to the rules and specifications outlined by the WS-I Basic Profile.
| Rule | Description | |
| STAR1001 | : | All web services must be compliant to the rules and specifications outlined by the WS-I Basic Profile. |
| STAR1002 | : | Appropriate compliance markers are required as specified by the WS-I Conformance Claim Attachment Mechanisms document. |
| STAR1015 | : | STAR BOD Specific and Generic Transports must be message level interoperable as specified in section 1.4. |
| STAR1016 | : | Application level error messages MUST NOT be returned with a SOAP Fault, and must be returned using the appropriate BOD. Section 2.5.1. section needs to be updated so that it refers to Chapter 17 instead of Chapter 3. Paragraph 2 of 2.5.1. |
| STAR1017. | : | Section 2.5.3 - Duplicate handling wording in the STAR Web Services specification needs to be reviewed. And Clarified as to intent. |
| STAR1018 | : | A SOAP Header MUST contain one manifest element for each content element in the SOAP body. Section 2.6 |
| STAR1019 | : | A manifest is REQUIRED to have namespaceURI, element, contentID, and version attributes. Even though version is listed as optional it is REQUIRED for STAR BOD and DTS transports. Section 2.6 |
1.2 Attachments
STAR should review the recommendations on attachements and consider adopting one of the approved specifications. i.e MTOM. Need to review which frameworks support MTOM and how interoperable these implementations are. Possible Level 2 requirement.
2. Error Handling
These rules are covered by Chapter 7 of the STAR Web Services Specification.
2.1 HTTP
The W3C contains a list of standard HTTP error codes and their meaning.
Follow the requirements specified by the WS-I.org Basic Profile in regards to HTTP status codes and soap messages.
2.2 SOAP Faults
| Rule | Description | |
| STAR1009 | : | All STAR Web Services are REQUIRED to understand and handle the STAR Specific SOAP Faults. |
| STAR1010 | : | All STAR soap fault error codes are REQUIRED to be be prefixed with STAR: and the appropriate STAR error code. i.e. STAR:Invalid Structure. |
| STAR1011 | : | All STAR soap fault error codes are REQUIRED to appear in the standard SOAP:Fault block. |
| STAR1012 | : | SOAP Faults are for Critical Processing errors only. Informational or warning errors should not be sent as a SOAP Fault. |
| STAR1014 | : | WS-Security errors must send the appropriate WS-Security SOAP Fault for the authorization being used. (i.e. Username and Password at a STAR Level 1 requirement level). |
Note: When sending a SOAP Fault the HTTP Status code needs to be set to 500, according to the WS-I Basic Profile.
| Code | Description |
| Duplicate Document | This code refers to a document that already exists. This may happen for a BOD such as ProcessPartsOrder where the document identifiers to another existing parts order from the same dealer. Note: Should this be moved to Level 2 for WS-ReliableMessaging. |
| Not Authorized | This code occurs when the client attempts to perform an operation that is not authorized for the given action. This is not to be used for Authentication errors, those should use the appropriate WS-Security SOAP Fault. |
| Server Error | An error (e.g. database server is down) on the server prevented the execution of the BOD. The client will have to resend the BOD at a later time. Note: Need better description for when this occurs at the ConfirmBOD level. |
| BOD Not Supported | The received BOD or BOD version is not supported b the receiver. |
| Invalid Structure | The structure of the BOD is not valid. For example, the BOD failed schema validation. |
| Invalid BODID | A BODID was missing or is Invalid. |
| Time Exceeded | The processing time will exceed the real time transaction allowed time. Must resend with a Put for batch processing, and pull to receive the message. |
2.3 Application
ConfirmBOD Message Codes (STAR 4) / ReasonCode (STAR 5)
The following messages may occur at a ConfirmBOD or SOAP Fault level. This depends on how the implementation is architected on the back end system. While the ConfirmBOD can send back Warnings, SOAP Faults are restricted to errors that stop processing of the message. Warnings are not included in the list for this reason. There are also some concerns about warnings on how these should be handled from an interoperability standpoint.
Note: STAR1013 - ConfirmBOD reason codes that are sent at the Warning or Informational status, should not trigger a resending of the BOD.
| Code | Description | Category |
| Duplicate Document | This code refers to a document that already exists. This may happen for a BOD such as ProcessPartsOrder where the document identifiers to another existing parts order from the same dealer. | Error |
| Invalid Required Value | One or more required data elements have invalid values. | Error. |
| Already Performed | This code refers to an operation that has already been performed on a document. This may happen for a BOD such as CancelPartsOrder where the document identifier refer to a parts order that has already been cancelled. | Error. |
| Cannot Perform | This code refers to an operation that cannot be performed such as Change or Cancel based on the receiver's business rules and the condition of the document. For example, the part order has already been shipped therefore the order cannot be cancelled. | Error. |
| Required Field Missing | This occurs when one or more required fields are missing. | Error. |
| Not Permitted | This code occurs when the client attempts to perform an operation that is not permitted. An example of when this may occur is if the dealer attempts to order a part when their account is placed on hold. This is to be used for authorization errors. | Error. |
| Server Error | An error (e.g. database server is down) on the server prevented the execution of the BOD. The client will have to resend the BOD at a later time. | Error. |
| BOD Not Supported | The received BOD or BOD version is not supported b the receiver. | Error. |
| Invalid Structure | The structure of the BOD is not valid. For example, the BOD failed schema validation. | Error. |
Other suggestions from STAR Members:
| Invalid BODID | A BODID was missing or is Invalid. |
Rules are pending for this section.
| Rule | Description |
3. WS-Security
Rules cover Chapter 8 of the STAR Web Services Specification.
3.1 General
| Rule | Description | |
| STAR1004 | : | All implementations are REQUIRED to send information over HTTPS. |
| STAR1008 | : | All services and clients must be compliant to the general Security requirements outlined by the WS-I Basic Security Profile 1.0. |
3.2 User Name and Password
| Rule | Description | |
| STAR1003 | : | All implementations are required to support Username/Password for authentication. |
| STAR1005 | : | All passwords are required to be sent as plain text. |
| STAR1006 | : | Passwords must expire after a certain time. (Need process to change password). - Editors Note: Does this really need to be a rule??? |
| STAR1007 | : | Must implement the User Name and Password WS-Security Profile. |