3 Replies Latest reply on Jan 24, 2006 9:36 AM by hbraun

    Event source deployment


      Regarding the eventing specs, one will find two kinds of event sources: logical and physical ones. Logical event sources get registered with the subscription manager, which then will be accepting subscriptions and notifications for this source. It's basically a namespace. Physical event sources actually are emitting events. They can vary from SLSB's, EJB timer events, JMS message listener, etc.

      This thread relates to the deployment of logical event sources.

      For the complete deployment of a logical event source, there needs to be a soap binding deployed and the event source registered with the subscriptions manager.
      According to the specs, a WSDL porttype can be attributed with 'EventSource=true', which then identifies it as an event source.

      In order to deploy an event source, i suggest that the web service deployer should be able to identify event sources by the means described above, and prior to the deployment of the actual binding, it should register the event source with the subscription manager.

      Does this seem to be a reasonable solution to you guys?

        • 1. Re: Event source deployment
          Thomas Diesler Master

          Yes, the unified meta data model (UMDM) should have this property at the endpoint level, which the deployers should act upon

          • 3. Re: Event source deployment

            The scenario described above makes it really painful and error-prone to deploy event sources:

            A developer would have to create a custom WSDL that includes the standard eventing wsdl and schema. Add a standard jaxrpc-mapping, chose the default jboss SEI implementation wrap it up and deploy everything.

            This would mean 99% redundancy between all event sources deployed on a server. The only difference would be the event source names and the notification schemas.

            Opposed to that i decided to implement it the other way around:
            A developer configures an event source name and notification schema. The actual endpoints are setup by the eventing implementation and the corresponding WSDL is generated dynamically.

            Take a look at the example configuration:

             A subscription manager for WS-Eventing
             <mbean code="org.jboss.ws.eventing.mgmt.SubscriptionManager"
             <attribute name="EventSourceConfig" serialDataType="jbxb">
             xs:schemaLocation="urn:jboss:eventsource-config:1.0 resource:eventsource-config_1_0.xsd">
             <jbwse:eventsource name="WindReport">
             xmlns:xs='http://www.w3.org/2001/XMLSchema' >
             <xs:element name="WindReport">
             <xs:element name="Date" type="xs:string"/>
             <xs:element name="Time" type="xs:string"/>
             <xs:element name="Speed" type="xs:string"/>
             <xs:element name="Location" type="xs:string"/>
             <xs:element name="County" type="xs:string"/>
             <xs:element name="State" type="xs:string"/>
             <xs:element name="Lat" type="xs:string"/>
             <xs:element name="Long" type="xs:string"/>
             <xs:element name="Comments" type="xs:string"/>

            That's all that needs to done.
            When the subscription manager starts up it registers an event source called 'WindReport' and does setup the endpoints.

            Further explanations can be found here: