jUDDI
  1. jUDDI
  2. JUDDI-591

Add support for email alerts for Subscription API

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.1.5
    • Component/s: None
    • Labels:
      None

      Description

      Referencing 5.5.8 save_subscription of the subscription API, (pist... Kurt said this part wasn't written)

      bindingKey: This optional argument of type anyURI specifies the bindingTemplate which the node is to use to deliver notifications to subscription listeners. It is only required when asynchronous notifications are used. This bindingTemplate MUST define either a Web service that implements notify_subscriptionListener (see below), or an email address to receive the notifications. If a notify_subscriptionListener Web service is identified, the node invokes it to deliver notifications. If an email address is identified, the node delivers notifications via email to the address supplied. When notifications are delivered via email, the body of the email contains the body of the SOAP message, which would have been sent to the notify_subscriptionListener service if that option had been chosen. The publisher making the subscription request MUST own the bindingTemplate. If this argument is not supplied, no notifications are sent, although subscribers may still use the get_subscriptionResults API to obtain subscription results. See Section 5.5.11 get_subscriptionResults for details. If email delivery to the specified address fails, nodes MAY attempt re-delivery, but are not obligated to do so. Depending upon node policy, excessive delivery failures MAY result in cancellation of the corresponding subscription.

      Service side changes, standard java mail api properties, plus delivery retry counts, reply email, maybe a pointer to a templated html stylized email

        Issue Links

          Activity

          Alex O'Ree made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Gavin made changes -
          Link This issue is related to JUDDI-602 [ JUDDI-602 ]
          Gavin made changes -
          Link This issue is related to JUDDI-602 [ JUDDI-602 ]
          Alex O'Ree made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Kurt T Stam made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Kurt T Stam made changes -
          Link This issue is related too JUDDI-602 [ JUDDI-602 ]
          Alex O'Ree made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Kurt T Stam made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Kurt T Stam made changes -
          Link This issue is blocked by JUDDI-496 [ JUDDI-496 ]
          Alex O'Ree made changes -
          Field Original Value New Value
          Description Referencing 5.5.8 save_subscription of the subscription API, (pist... Kurt said this part wasn't written)

           bindingKey: This optional argument of type anyURI specifies the bindingTemplate which the node is to use to deliver notifications to subscription listeners. It is only required when asynchronous notifications are used. This bindingTemplate MUST define either a Web service that implements notify_subscriptionListener (see below), or an email address to receive the notifications. If a notify_subscriptionListener Web service is identified, the node invokes it to deliver notifications. If an email address is identified, the node delivers notifications via email to the address supplied. When notifications are delivered via email, the body of the email contains the body of the SOAP message, which would have been sent to the notify_subscriptionListener service if that option had been chosen. The publisher making the subscription request MUST own the bindingTemplate. If this argument is not supplied, no notifications are sent, although subscribers may still use the get_subscriptionResults API to obtain subscription results. See Section 5.5.11 get_subscriptionResults for details. If email delivery to the specified address fails, nodes MAY attempt re-delivery, but are not obligated to do so. Depending upon node policy, excessive delivery failures MAY result in cancellation of the corresponding subscription.

          Service side changes, standard java mail api properties, plus delivery retry counts, reply email
          Referencing 5.5.8 save_subscription of the subscription API, (pist... Kurt said this part wasn't written)

           bindingKey: This optional argument of type anyURI specifies the bindingTemplate which the node is to use to deliver notifications to subscription listeners. It is only required when asynchronous notifications are used. This bindingTemplate MUST define either a Web service that implements notify_subscriptionListener (see below), or an email address to receive the notifications. If a notify_subscriptionListener Web service is identified, the node invokes it to deliver notifications. If an email address is identified, the node delivers notifications via email to the address supplied. When notifications are delivered via email, the body of the email contains the body of the SOAP message, which would have been sent to the notify_subscriptionListener service if that option had been chosen. The publisher making the subscription request MUST own the bindingTemplate. If this argument is not supplied, no notifications are sent, although subscribers may still use the get_subscriptionResults API to obtain subscription results. See Section 5.5.11 get_subscriptionResults for details. If email delivery to the specified address fails, nodes MAY attempt re-delivery, but are not obligated to do so. Depending upon node policy, excessive delivery failures MAY result in cancellation of the corresponding subscription.

          Service side changes, standard java mail api properties, plus delivery retry counts, reply email, maybe a pointer to a templated html stylized email
          Alex O'Ree created issue -

            People

            • Assignee:
              Kurt T Stam
              Reporter:
              Alex O'Ree
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development