This document details how to develop a JBI component with the help of the Petals ESB Component Development Kit (CDK).
Before reading this document, you must be familiar with the Petals ESB development rules and tools.
h1. Description
The CDK is composed of 3 MAVEN projects.
h2. JBI descriptor
The definition of the structure of the CDK configuration. It is based on XML schema and redefines the JBI original XSD, to extend the component and service unit definition with CDK parameters.
In your component, you must extends too this redefined XSD to add your component specific structure of configuration.
h2. API
The API contains the constants and the interfaces to manipulate in your component implementation. It must be refers in your POM if you define interceptor implementations.
h2. Core
The Core contains the implementation of the API. You can focus only on the abstract classes that implements the API interfaces, and that you must extend in your component implementation.
h1. How does a CDK component work ?
h2. Creation
You have to use the PEtALS maven tasks to create a component stub. You can see the Developer Guide to do this.
h2. The Provider role
When you component acts as a provider of a service, it must expose this service in the bus, to be accessible by other components. This is called exposing an endpoint.
The CDK identifies two different kind of service, that are activated in two differents ways :
* a service that can be called a business unit and which is fully described and carried in a JBI service unit.
* a service native to the component, which can be called a generic service. This kind of service is drived directly by the component itself, no need of JBI service unit.
h3. Static exposition
You can expose statically an endpoint, for a personal business, leaded by the service units.
# Install and start the component
# Create a service unit containing the server configuration (host, port, address,...for example) and the message adressing (from, to,...) into the jbi.xml, and the endpoint to expose through the ServiceUnitManager into a wsdl document
# Create the service assembly containing the service unit
# Deploy and start the service assembly under the component : the endpoint is exposed, and the JBIListener is ready to receive Exchanges
The component JBIListener will process all the Exchanges using the Service Unit Manager.
# the in NormalizedMessage Content is the payload to process (mandatory)
# the in NormalizedMessage Set of attachments contains attachments to relay
# the in NormalizedMessage Set of properties contains properties to relay
# the in NormalizedMessage SecuritySubject contains a subject to relay
# the install properties of the component are unusable
# the jbi.xml extensions file provides the configuration and the message addressing (mandatory)
h3. Dynamic exposition
You can expose a service, for a generic business, leaded directly by the component :
# Create a wsdl document named "component.wsdl" containing the endpoint to expose directly from the component. It may contain an autogenerate endpoint today.
{code:lang=xml}<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ebmwebsourcing.com/WS-BrokeredNotification/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsbrw-2="http://docs.oasis-open.org/wsn/brw-2"
xmlns:wsbw-2="http://docs.oasis-open.org/wsn/br-2"
name="WS-BrokeredNotification"
targetNamespace="http://www.ebmwebsourcing.com/WS-BrokeredNotification/">
<!-- ================== imports ======================= -->
<wsdl:import location="brw-2.wsdl" namespace="http://docs.oasis-open.org/wsn/brw-2"></wsdl:import>
<!-- ================================================== -->
<!-- binding -->
...
<!-- services -->
<wsdl:service name="PublisherRegistrationManagerService">
<wsdl:port name="autogenerate" binding="tns:PublisherRegistrationManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
{code}
# Put the wsdl document into the directory src/main/resources of the component
# Install and start the component : the endpoint is exposed, and the JBIListener is ready to receive Exchanges.
The component, at the installation, read the wsdl document and initialize its specific description (with creation of the real name of the autogenerated endpoints if needed). At the start, it registers all the endpoints of the description. At the stop it unregisters all of this. At the shutdown, it destroy its specific description.
The method isDescriptionContaining(Description, ServiceEndpoint) into WSDLUtil can help you to detect if the Exchange have to be proccessed directly by the component :
{code}if (UtilFactory.getWSDLUtil().isDescriptionContaining(component.getSpecificWsdlDescription(),
exchange.getEndpoint())) {
getLogger().fine("exchange to process internally received");
} else {
getLogger().fine("exchange to process with the SU manager received");
}
{code}
If the in NormalizedMessage Set of properties contains the message addressing, a JBI dynamic processing must be executed, else a SOA dynamic processing must be done.
h4. JBI dynamic processing
The component JBIListener will process all the Exchanges using the shared functionalities provided by Petals ESB.
# the in NormalizedMessage Content is the payload to process (mandatory)
# the in NormalizedMessage Set of attachments contains attachments to relay
# the in NormalizedMessage Set of properties contains the message addressing (mandatory)
# the in NormalizedMessage SecuritySubject contains a subject to relay
# the install properties of the component provide the configuration (mandatory)
# the jbi.xml extensions file is unusable
h4. SOA dynamic processing
The component JBIListener will process the Exchanges using the specific functionalities provided by the component. A strict xml format must be defined through a xsd file.
# the in NormalizedMessage Content is the payload to process and the message addressing (mandatory)
# the in NormalizedMessage Set of attachments contains attachments to relay
# the in NormalizedMessage Set of properties contains properties to relay
# the in NormalizedMessage SecuritySubject contains a subject to relay
# the install properties of the component provide the configuration (mandatory)
# the jbi.xml extensions file is unusable
h2. The Consumer role
h2. Fault and Exception
If the service have a technical problem, you must throw a SOAP11FaultServerException. To do this, you use directly the constructor of this exception (do a "new SOAP11FaultServerException()" ) , and put it into the Exchange.
If the services have, at a moment a functional problem, you must throw a JBI fault. This fault have to be declared into your wsdl document in any case. To do this, you have to create a fault using the Exchange provided, and put it into the same Exchange.
Unfortunately, the Message Exchange Pattern InOut doesn't allow to throw an exception. However, you can create and put into the Exchange an exception. The MessageExchangeProcessor will transform it on a Fault (of course not declared into the wsdl document). The method isPetalsException(Fault) into ExchangeUtil can help you to detect an unfunctional but technical Fault into an Exchange, and process on a special treatement :
{code}if (exchange.getFault() != null) {
if (UtilFactory.getExchangeUtil().isPetalsException(exchange.getFault())) {
getLogger().fine("exchange technical fault message content: " +
SourceHelper.convertToString(exchange.getFault().getContent()));
} else {
getLogger().fine("exchange business fault message content: " +
SourceHelper.convertToString(exchange.getFault().getContent()));
}
} else {
getLogger().fine("exchange in message content: " +
SourceHelper.convertToString(exchange.getInMessage().getContent()));
}
{code}
h2. WS-Notification
Petals ESB provide the WS-Notification mechanisms. It's EDA oriented too.
*Petals EDA*
!petals-eda.jpg.jpeg!
The consumer, the provider and the broker implements the WS-BaseNotification, WS-BrokeredNotification, WS-Topics and WS-Resources specifications.
*WS-Notification* !ws-notif.jpg.jpeg!
{note}Today, the getCurrentMessage operation of the NotificationProducer interface is not implemented.{note}
{note}Today, the renew operation of the SubscribtionManager interface is not implemented.{note}
h3. Broker
All the services are publisher or consumer of events. A broker is, at the same time, a producer and a consumer of events. On a brokered initiated publishing pattern (see the WS-BrokeredNotification specifications from OASIS for more details),
the broker requires the publisher to register (providing a topic expression) with it prior to sending the notify message. the broker requires the consumer to subscribe (providing a filter topic expression) with it prior to receiving the notify message. The broker notifies messages delivered by the producer according to the filter topic expression subscribed.
The WS-BrokeredNotification is provided by the petals-se-notification engine. It exposes the standardized Brokered services :
{code:lang=xml}<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://petals.ow2.org/petals-se-notification"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsbrw-2="http://docs.oasis-open.org/wsn/brw-2"
xmlns:wsbw-2="http://docs.oasis-open.org/wsn/br-2"
name="WS-BrokeredNotification"
targetNamespace="http://petals.ow2.org/petals-se-notification">
<!-- ================== imports ======================= -->
<wsdl:import location="brw-2.wsdl"
namespace="http://docs.oasis-open.org/wsn/brw-2"></wsdl:import>
<!-- ================================================== -->
<!-- binding -->
<!-- services -->
<wsdl:service name="NotificationBrokerService">
<wsdl:port name="autogenerate" binding="tns:NotificationBrokerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="PublisherRegistrationManagerService">
<wsdl:port name="autogenerate" binding="tns:PublisherRegistrationManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="SubscriptionManagerService">
<wsdl:port name="autogenerate" binding="tns:SubscriptionManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
{code}
h3. Producer
A component natively is Producer of notification. It can invoke the broker of notifications embedded into Petals ESB. Such like explains into the specification :
The Producer invokes the "registerPublisher" operation of the Broker when the component starts. The topic is a topic expression matching existing topic expressions into the broker today. The publisher reference is the endpoint of the NotificationProducerService. The demand is activated. The initial termination time is null. The publisher registration reference into the response is the endpoint of the PublisherRegistrationManager with a resource id associated to the created registration (as consequence of the request). The consumer reference into the response is the endpoint of the NotificationBrokerService.
The Producer invokes the "destroyRegistration" operation of the Broker when the component stops. The publisher registration reference is its saved before.
*Register-Publisher* !register-publisher.jpg.jpeg!
The Consumer invokes the "subscribe" operation of the Broker. The filter is a topic expression matching existing topic expressions into the broker today. The consumer reference is the endpoint of the NotificationConsumerService. The initial termination time is null. The subscription reference into the response is the endpoint of the SubscriptionManagerService of the broker with a resource id. The current time into the response is null. The termination date into the response is null.
The Broker invokes the "subscribe" operation of the Producer already registered with a topic expression matching the filter. The filter is the same of the previously sent. The consumer reference is the endpoint of the NotificationBrokerService. The initial termination time is null. The subscription reference into the response is the endpoint of the SubscriptionManagerService of the producer with a resource id. The current time into the response is null. The termination date into the response is null.
The Consumer invokes the "unsubscribe" operation of the Broker. The subscription reference is its from the broker saved before.
The Broker invokes the "unsubscribe" operation of the Producer. The subscription reference is its from the producer saved before.
*subscribe* !subscribe.png!
The Producer invokes the "notify" operation of the Broker. The subscription reference is its from the producer saved before. The producer reference is the endpoint of the NotificationProducerService. The topic is a valid topic expression. The message is a valid payload.
The Broker looks for subscribed consumer respect to the TopicExpression contains in the notification payload, and invokes the "notify" operation of the Consumer. The subscription reference is its from the broker saved before. The producer reference is the endpoint of the NotificationBrokerService. The topic is a valid topic expression. The message is a valid payload.
*notify* !notify.png!
The component exposes the standardized Producer services :
{code:lang=xml}<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions
xmlns:wsbw-2="http://docs.oasis-open.org/wsn/bw-2"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://petals.ow2.org/WS-BaseNotification"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
name="WS-NotificationProducer"
targetNamespace="http://petals.ow2.org/WS-BaseNotification/">
<!-- import WS-BaseNotification abstract part (types and messages) -->
<wsdl:import location="bw-2.wsdl" namespace="http://docs.oasis-open.org/wsn/bw-2"></wsdl:import>
<!-- ================================================== -->
<!-- ========== Binding part definition =============== -->
<!-- SubscritpionManager binding definition -->
....
<!-- NotificationProducer binding definition -->
...
<!-- ============================================= -->
<!-- ============ Endpoints definition =========== -->
<!-- ============================================= -->
<wsdl:service name="NotificationProducerService">
<wsdl:port name="autogenerate" binding="tns:NotificationProducerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="SubscriptionManagerService">
<wsdl:port name="autogenerate" binding="tns:SubscriptionManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
{code}
The CDK API allow you to send notifications from your specific implementation.
The CDK API can help you to expose particular Provider services, implement your own notifications, and invoke the broker of notifications embedded into Petals too.
h3. Consumer
A component isn't natively Consumer of notification.
The CDK API can help you to expose particular Consumer services, implement your own notifications, and invoke the broker of notifications embedded into Petals ESB.
Before reading this document, you must be familiar with the Petals ESB development rules and tools.
h1. Description
The CDK is composed of 3 MAVEN projects.
h2. JBI descriptor
The definition of the structure of the CDK configuration. It is based on XML schema and redefines the JBI original XSD, to extend the component and service unit definition with CDK parameters.
In your component, you must extends too this redefined XSD to add your component specific structure of configuration.
h2. API
The API contains the constants and the interfaces to manipulate in your component implementation. It must be refers in your POM if you define interceptor implementations.
h2. Core
The Core contains the implementation of the API. You can focus only on the abstract classes that implements the API interfaces, and that you must extend in your component implementation.
h1. How does a CDK component work ?
h2. Creation
You have to use the PEtALS maven tasks to create a component stub. You can see the Developer Guide to do this.
h2. The Provider role
When you component acts as a provider of a service, it must expose this service in the bus, to be accessible by other components. This is called exposing an endpoint.
The CDK identifies two different kind of service, that are activated in two differents ways :
* a service that can be called a business unit and which is fully described and carried in a JBI service unit.
* a service native to the component, which can be called a generic service. This kind of service is drived directly by the component itself, no need of JBI service unit.
h3. Static exposition
You can expose statically an endpoint, for a personal business, leaded by the service units.
# Install and start the component
# Create a service unit containing the server configuration (host, port, address,...for example) and the message adressing (from, to,...) into the jbi.xml, and the endpoint to expose through the ServiceUnitManager into a wsdl document
# Create the service assembly containing the service unit
# Deploy and start the service assembly under the component : the endpoint is exposed, and the JBIListener is ready to receive Exchanges
The component JBIListener will process all the Exchanges using the Service Unit Manager.
# the in NormalizedMessage Content is the payload to process (mandatory)
# the in NormalizedMessage Set of attachments contains attachments to relay
# the in NormalizedMessage Set of properties contains properties to relay
# the in NormalizedMessage SecuritySubject contains a subject to relay
# the install properties of the component are unusable
# the jbi.xml extensions file provides the configuration and the message addressing (mandatory)
h3. Dynamic exposition
You can expose a service, for a generic business, leaded directly by the component :
# Create a wsdl document named "component.wsdl" containing the endpoint to expose directly from the component. It may contain an autogenerate endpoint today.
{code:lang=xml}<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ebmwebsourcing.com/WS-BrokeredNotification/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsbrw-2="http://docs.oasis-open.org/wsn/brw-2"
xmlns:wsbw-2="http://docs.oasis-open.org/wsn/br-2"
name="WS-BrokeredNotification"
targetNamespace="http://www.ebmwebsourcing.com/WS-BrokeredNotification/">
<!-- ================== imports ======================= -->
<wsdl:import location="brw-2.wsdl" namespace="http://docs.oasis-open.org/wsn/brw-2"></wsdl:import>
<!-- ================================================== -->
<!-- binding -->
...
<!-- services -->
<wsdl:service name="PublisherRegistrationManagerService">
<wsdl:port name="autogenerate" binding="tns:PublisherRegistrationManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
{code}
# Put the wsdl document into the directory src/main/resources of the component
# Install and start the component : the endpoint is exposed, and the JBIListener is ready to receive Exchanges.
The component, at the installation, read the wsdl document and initialize its specific description (with creation of the real name of the autogenerated endpoints if needed). At the start, it registers all the endpoints of the description. At the stop it unregisters all of this. At the shutdown, it destroy its specific description.
The method isDescriptionContaining(Description, ServiceEndpoint) into WSDLUtil can help you to detect if the Exchange have to be proccessed directly by the component :
{code}if (UtilFactory.getWSDLUtil().isDescriptionContaining(component.getSpecificWsdlDescription(),
exchange.getEndpoint())) {
getLogger().fine("exchange to process internally received");
} else {
getLogger().fine("exchange to process with the SU manager received");
}
{code}
If the in NormalizedMessage Set of properties contains the message addressing, a JBI dynamic processing must be executed, else a SOA dynamic processing must be done.
h4. JBI dynamic processing
The component JBIListener will process all the Exchanges using the shared functionalities provided by Petals ESB.
# the in NormalizedMessage Content is the payload to process (mandatory)
# the in NormalizedMessage Set of attachments contains attachments to relay
# the in NormalizedMessage Set of properties contains the message addressing (mandatory)
# the in NormalizedMessage SecuritySubject contains a subject to relay
# the install properties of the component provide the configuration (mandatory)
# the jbi.xml extensions file is unusable
h4. SOA dynamic processing
The component JBIListener will process the Exchanges using the specific functionalities provided by the component. A strict xml format must be defined through a xsd file.
# the in NormalizedMessage Content is the payload to process and the message addressing (mandatory)
# the in NormalizedMessage Set of attachments contains attachments to relay
# the in NormalizedMessage Set of properties contains properties to relay
# the in NormalizedMessage SecuritySubject contains a subject to relay
# the install properties of the component provide the configuration (mandatory)
# the jbi.xml extensions file is unusable
h2. The Consumer role
h2. Fault and Exception
If the service have a technical problem, you must throw a SOAP11FaultServerException. To do this, you use directly the constructor of this exception (do a "new SOAP11FaultServerException()" ) , and put it into the Exchange.
If the services have, at a moment a functional problem, you must throw a JBI fault. This fault have to be declared into your wsdl document in any case. To do this, you have to create a fault using the Exchange provided, and put it into the same Exchange.
Unfortunately, the Message Exchange Pattern InOut doesn't allow to throw an exception. However, you can create and put into the Exchange an exception. The MessageExchangeProcessor will transform it on a Fault (of course not declared into the wsdl document). The method isPetalsException(Fault) into ExchangeUtil can help you to detect an unfunctional but technical Fault into an Exchange, and process on a special treatement :
{code}if (exchange.getFault() != null) {
if (UtilFactory.getExchangeUtil().isPetalsException(exchange.getFault())) {
getLogger().fine("exchange technical fault message content: " +
SourceHelper.convertToString(exchange.getFault().getContent()));
} else {
getLogger().fine("exchange business fault message content: " +
SourceHelper.convertToString(exchange.getFault().getContent()));
}
} else {
getLogger().fine("exchange in message content: " +
SourceHelper.convertToString(exchange.getInMessage().getContent()));
}
{code}
h2. WS-Notification
Petals ESB provide the WS-Notification mechanisms. It's EDA oriented too.
*Petals EDA*
!petals-eda.jpg.jpeg!
The consumer, the provider and the broker implements the WS-BaseNotification, WS-BrokeredNotification, WS-Topics and WS-Resources specifications.
*WS-Notification* !ws-notif.jpg.jpeg!
{note}Today, the getCurrentMessage operation of the NotificationProducer interface is not implemented.{note}
{note}Today, the renew operation of the SubscribtionManager interface is not implemented.{note}
h3. Broker
All the services are publisher or consumer of events. A broker is, at the same time, a producer and a consumer of events. On a brokered initiated publishing pattern (see the WS-BrokeredNotification specifications from OASIS for more details),
the broker requires the publisher to register (providing a topic expression) with it prior to sending the notify message. the broker requires the consumer to subscribe (providing a filter topic expression) with it prior to receiving the notify message. The broker notifies messages delivered by the producer according to the filter topic expression subscribed.
The WS-BrokeredNotification is provided by the petals-se-notification engine. It exposes the standardized Brokered services :
{code:lang=xml}<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://petals.ow2.org/petals-se-notification"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsbrw-2="http://docs.oasis-open.org/wsn/brw-2"
xmlns:wsbw-2="http://docs.oasis-open.org/wsn/br-2"
name="WS-BrokeredNotification"
targetNamespace="http://petals.ow2.org/petals-se-notification">
<!-- ================== imports ======================= -->
<wsdl:import location="brw-2.wsdl"
namespace="http://docs.oasis-open.org/wsn/brw-2"></wsdl:import>
<!-- ================================================== -->
<!-- binding -->
<!-- services -->
<wsdl:service name="NotificationBrokerService">
<wsdl:port name="autogenerate" binding="tns:NotificationBrokerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="PublisherRegistrationManagerService">
<wsdl:port name="autogenerate" binding="tns:PublisherRegistrationManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="SubscriptionManagerService">
<wsdl:port name="autogenerate" binding="tns:SubscriptionManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
{code}
h3. Producer
A component natively is Producer of notification. It can invoke the broker of notifications embedded into Petals ESB. Such like explains into the specification :
The Producer invokes the "registerPublisher" operation of the Broker when the component starts. The topic is a topic expression matching existing topic expressions into the broker today. The publisher reference is the endpoint of the NotificationProducerService. The demand is activated. The initial termination time is null. The publisher registration reference into the response is the endpoint of the PublisherRegistrationManager with a resource id associated to the created registration (as consequence of the request). The consumer reference into the response is the endpoint of the NotificationBrokerService.
The Producer invokes the "destroyRegistration" operation of the Broker when the component stops. The publisher registration reference is its saved before.
*Register-Publisher* !register-publisher.jpg.jpeg!
The Consumer invokes the "subscribe" operation of the Broker. The filter is a topic expression matching existing topic expressions into the broker today. The consumer reference is the endpoint of the NotificationConsumerService. The initial termination time is null. The subscription reference into the response is the endpoint of the SubscriptionManagerService of the broker with a resource id. The current time into the response is null. The termination date into the response is null.
The Broker invokes the "subscribe" operation of the Producer already registered with a topic expression matching the filter. The filter is the same of the previously sent. The consumer reference is the endpoint of the NotificationBrokerService. The initial termination time is null. The subscription reference into the response is the endpoint of the SubscriptionManagerService of the producer with a resource id. The current time into the response is null. The termination date into the response is null.
The Consumer invokes the "unsubscribe" operation of the Broker. The subscription reference is its from the broker saved before.
The Broker invokes the "unsubscribe" operation of the Producer. The subscription reference is its from the producer saved before.
*subscribe* !subscribe.png!
The Producer invokes the "notify" operation of the Broker. The subscription reference is its from the producer saved before. The producer reference is the endpoint of the NotificationProducerService. The topic is a valid topic expression. The message is a valid payload.
The Broker looks for subscribed consumer respect to the TopicExpression contains in the notification payload, and invokes the "notify" operation of the Consumer. The subscription reference is its from the broker saved before. The producer reference is the endpoint of the NotificationBrokerService. The topic is a valid topic expression. The message is a valid payload.
*notify* !notify.png!
The component exposes the standardized Producer services :
{code:lang=xml}<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<wsdl:definitions
xmlns:wsbw-2="http://docs.oasis-open.org/wsn/bw-2"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://petals.ow2.org/WS-BaseNotification"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
name="WS-NotificationProducer"
targetNamespace="http://petals.ow2.org/WS-BaseNotification/">
<!-- import WS-BaseNotification abstract part (types and messages) -->
<wsdl:import location="bw-2.wsdl" namespace="http://docs.oasis-open.org/wsn/bw-2"></wsdl:import>
<!-- ================================================== -->
<!-- ========== Binding part definition =============== -->
<!-- SubscritpionManager binding definition -->
....
<!-- NotificationProducer binding definition -->
...
<!-- ============================================= -->
<!-- ============ Endpoints definition =========== -->
<!-- ============================================= -->
<wsdl:service name="NotificationProducerService">
<wsdl:port name="autogenerate" binding="tns:NotificationProducerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
<wsdl:service name="SubscriptionManagerService">
<wsdl:port name="autogenerate" binding="tns:SubscriptionManagerBinding">
<soap:address location="petals:autogenerate" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
{code}
The CDK API allow you to send notifications from your specific implementation.
The CDK API can help you to expose particular Provider services, implement your own notifications, and invoke the broker of notifications embedded into Petals too.
h3. Consumer
A component isn't natively Consumer of notification.
The CDK API can help you to expose particular Consumer services, implement your own notifications, and invoke the broker of notifications embedded into Petals ESB.