WSO2Con 2013 CFP Banner

Web Services Eventing Solution with Apache Savan/C - Part2

Discuss this article on Stack Overflow
By damitha nanda mangala kumarage
  • 11 Feb, 2008
  • Level:  Intermediate
  • Reads: 4641
The Axis2/C Web services platform is a great platform for developing Web services. One of the modules that is a part of this platform is Apache Savan/C, a WS-Eventing implementation module.
damitha nanda mangala kumarage
senior tech lead
The purpose of this article is to discuss how this platform was used in one of my client projects, which required an eventing solution as a component. This article by Damitha Kumarage, he discusses this eventing solution in addition to providing valuable information for those planning on hosting their services with Apache Axis2/C. Part I of this tutorial that discusses the same concepts can be found here.   Applies To Apache Axis2/C 1.1.0 - 1.2.0 WSF/C 1.1.0 - 1.2.0 Apache Savan/C 0.90 Environment Linux - Debian Etch/Lenny, Ubuntu, Fedora   Table of Contents The Project Syslog Adaptor Monitor Adaptor Stream Handlers Deployment End to End Flow Summary Resources   The Project Here's the background of the project.. I had several adaptors for data sources that produced an array of specialized output data, with multiple users who were interested in that data and subscribing to to sources providing a JMS Queue as the data sink. Adaptors that I have implemented are specialized for individual data sources. They all implement the service API provided by Apache Axis2/C. Some of my adaptors publish the data it receives, periodically,  in accordance to a real time clock. Some of these adaptor services starts functioning, as soon as they are loaded for service, while Some start functioning from the first request being initiated for the service. One such data source is the syslogd daemon. My Syslog Adaptor, when loading, opens a socket for listening to syslogd logging messages. When message lines are received, the adaptor parses it and builds an XML entry of it, which it then sends to the corresponding Stream Handler. Other data sources include messages from a chat room, configured in a XMPP server. My Monitor Adaptor receives such messages and transmits them to the corresponding Stream Handler.   End to End Flow Now let's take a look at some of the implementation details:   Syslog Adaptor Following is the syslog adaptor's configuration file: <service name="syslog"> <module ref="savan"/> <description> This is the syslog event source adaptor. This isused for processing syslog messages receive from syslogd. </description> <parameter name="ServiceClass" locked="xsd:false">syslog</parameter> <parameter name="loadServiceAtStartup" locked="xsd:false">true</parameter> <parameter name="syslog_port" locked="xsd:false">55001</parameter> <parameter name="TopicURL" locked="xsd:false">http://syslog@localhost/axis2/services/syslog</parameter> <operation name="entry"> <parameter name="wsamapping"></parameter> </operation> </service> - ServiceClass is the Axis2c service name. This is also taken as the WS eventing topic name of the syslog event source. - loadServiceAtStartup says that this adaptor should load and start functioning at Axis2/C service load up time. - SyslogPort is the port at which syslog adaptor listens in for syslogd daemon messages. - TopicURL is the URL of the syslog topic adaptor.   Monitor Adaptor Following is the xmpp adaptor's configuration file: <service name="monitor"> <description> This is the xmpp event source adaptor. This is used for monitoring xmpp chat room presence events. </description> <parameter name="ServiceClass" locked="xsd:false">monitor</parameter> <parameter name="xmpp_id" locked="xsd:false">monitor@localhost</parameter> <parameter name="xmpp_password" locked="xsd:false">g</parameter> <operation name="notify"> <parameter name="wsamapping">xmpp://</parameter> <parameter name="xmpp_subscribe_to">test4@localhost</parameter> <parameter name="xmpp_subscribe_type">user</parameter> </operation> </service> -xmpp_id is the registered id with the xmpp server. Here, the Axis2/C service monitor acts as an xmpp client. Hence, it requires, to acquire an xmpp id which is registered with the xmpp server. -xmpp-password is the password corresponding to the registered xmpp id. To learn more about Axis2/C xmpp transport please refer the tutorial titled How to Use WSO2 WSF/C, XMPP Transport. -notify is the operation that will be invoked, when an xmpp presence event is received from the xmpp server chat room. -xmpp_subscribe_to is the chat room id of the xmpp service to which the monitor adaptor will subscribe, for the purpose of receiving chat room presence events. -xmpp_subscribe_type is the subscriber type. We use the type user. Our xmpp server requires kerberos authenticaton to connect with. The following script was installed into /etc/init.d of the monitor adaptor during deployment for the job. # /etc/init.d/monitor ### BEGIN INIT INFO # Provides: monitor # Required-Start: $network # Should-Start: $named ### END INIT INFO . /etc/rc.status rc_reset case "$1" in start) echo -n "Kiniting for monitor." kinit -k -t /etc/opt/wsfes-ml/monitor.keytab monitor/monitor@VSS.MLRND.COM -c /tmp/monitor rc_status -v ;; stop) echo -n "removing monitor ticket" rc_status -v ;; reload) ;; restart|force-reload) $0 stop $0 start rc_status ;; *) echo "Usage: $0 {start}" >&2 exit 1 ;; esac exit 0   Stream Handlers For each service adaptor, I have a corresponding stream handler, specializing in that data source. The purpose of such stream handlers, is to publish data to corresponding topics in the JMS broker. A typical stream handler has the following configuration file: <service name="sh_syslog"> <description> Syslog Stream Handler is to publish messages to syslog topic in the JMS broker. </description> <parameter name="ServiceClass" locked="xsd:false">stream_handler_syslog</parameter> <parameter name="loadServiceAtStartup" locked="xsd:false">true</parameter> <parameter name="STOMP_HOST" locked="xsd:false">localhost</parameter> <parameter name="STOMP_PORT" locked="xsd:false">61613</parameter> <parameter name="STOMP_USERNAME" locked="xsd:false">dinesh</parameter> <parameter name="STOMP_PASSWORD" locked="xsd:false">123</parameter> <parameter name="STOMP_DESTINATION" locked="xsd:false">/queue/syslog</parameter> <operation name="entry"> <parameter name="wsamapping" ></parameter> </operation> </service> - STOMP_HOST is the host name where the JMS Server is hosted. - STOMP_PORT is the port where stomp is listening to incoming data. - STOMP_USERNAME is the registered username - STOMP_PASSWORD is the password for that user - STOMP_DESTINATION is the JMS topic name Each stream handler uses stomp protocol to communicate with the JMS Queue.   Deployment All my data source adaptors and stream handlers are implemented as Apache Axis2/C services, and therefore sits on an Axis2 engine deployed as an Apache Module. Subscription Manager is deployed in a simple Axis2 server and listens on a TCP port. Actually, at a latter phase of the project, subscription manager was moved to the same server as adaptors and stream handlers. However, whether they are on the same server, or otherwise, adaptors and subscription Manager had to communicate using SOAP protocol. It would have been nice if Axis2/C had an internal protocol to communicate, for communications within the same server. (i.e. from the transport layer, the engine need to be able to determine if communication is within the same server or not. If it is within the same server, then the engine should be able to transparently communicate within the server, instead of SOAP as it helps alleviating the overhead inherent in serialization/deserialization of SOAP messages).   JMS Client Portal A client interacts with the JMS client portal using a Web interface. It is the client portal that acts as a WS-Eventing client, subscribing to the event source adaptors hosted as Axis2/C Web services. It also provides a replyTo address pointing to a JMS topic queue. At start up, it queries through my subscription manager interface and subscribes to all of my registered event source adaptors. When this subscription request is received by the event source adaptor, it replaces the replyTo address provided by the client portal with its corresponding stream handler address, and adds an element to the message that it send to the stream handler listed as replyTo, with the client portal provided replyTo address as the value. Then the event source adaptor will register the subscriber at the subscription manager. Now, whenever data events occur at the event source adaptor, it will query the subscription manager for registered subscribers for that data event for publishing. Since our subscribers' replyTo address is now set to the stream handler, it will publish the data source event to the stream handler. Once data arrives at the stream handler, it will pass them to the stomp client listening on the configured host:port. Stomp will publish this to the configured JMS Queue and finally, our original subscriber will receive his portion of the data from the JMS Queue.   Summary The aim of this article was to explain how to work with the Apache Savan/C, using of an example. We discussed multiple different ways of deploying Axis2/C instances of Web services as event sources and accessing them. This kind of solution can be used to host any data source as an Axis2/C Web service instance, together with Apache Savan/C, through a properly configured event source service adaptor.   Resources Web Services Eventing with Apache Savan/C - Part 1 WSO2 WSF/C - WSO2 WSF/C is an Open Source framework for providing and consuming Web services Savan/C- Savan/C is an implementation of Web Services Eventing Specification C client to communicate with ActiveMQ Axis2/C XMPP Transport How to configure a JMS Topic Endpoint   Author Damitha Kumarage, Senior Software Engineer at wso2, committer Apache Software Foundation, damitha at wso2 dot com