##### Apache Savan/C

- Apache Savan/C Home
- Download Savan/C
  - Releases
- Documentation
  - Installation Guide
  - Savan/C manual
- Get Involved
  - Mailing Lists & Issue Tracking
  - Checkout Source Code
- Developer Guidelines
  - Coding Convention
  - Versionning
- Project Information
  - Project Team
  - Source Code

## Apache Savan/C Manual

This document guide you through the architecture of Savan/C

Please send your feedback to the developer mailing list: axis-c-dev@ws.apache.org (Subscription details are available on the Savan site.) Please remember to prefix the subject with [Savan/C].

## Contents

- What is web services eventing.
- Savan/C components
  - Subscription Manager
  - Sqlite based
  - Service based
  - WSO2 registry based
  - Publisher
  - Filters
- How it work together
- Understanding the internal dependancies

## What is eventing

For a long time web services lacked a standerd for event notification. On 20 January 2004, Akamai, The Globus Alliance, Hewlett-Packard, IBM, Sonic Software and TIBCO Software proposed two new Web services specifications. The first, WS-Notification, seeks to provide a standards-based means of publish-and-subscribe message delivery. On 7 January 2004, BEA Systems, Microsoft and TIBCO also published a specification for a Web services publish-and-subscribe standard, known as WS-Eventing.

Web Services Eventing is about using the Web services framework for implementing a Subscriber-Publisher model. A client will send a request message for a subscription to an Event Publishing Service (EPS), with information as to who it is and from where it can receive notifications from the server . The Publishing Service publishes its data, as and when available, to all client endpoints given by respective subscribers when making subscription requests. These endpoints can be an application running on the same machine as the client application (subscriber) or, it can be an application running on a different machine.

Savan/C is an implementation of the WS-Eventing specification. It started developement at the beginning of 2007 by some developers at WSO2 Inc. From the beginning the code was donated to Apache foundation. The company was in the process of implementating a complete web services stack for C which will be then used in C++ and most of the scripting languages like PHP, Pearl and Ruby.

By now the complete C stack called Axis2/C is very matured and C++, PHP stacks based on it also has gained wide popularity. Savan/C team first released it's 0.90 version in 05 November 2007. Since then lot of improvements were done to the code base leading to it's first major release on May 2009.

## Savan/C components

Savan/C code is designed with scalability and performance in mind. As an eventing implementation the main components should invariably be the subscription manager and publisher. Then we need filter implementations. Since these threee components are the most important components for the Savan/C user special care has been taken in designing these components. These three components are written as pluggable components. User has the options of using the implementations provided by the Savan/C for these components or write his own component implementing the corresponding API. The API's are savan_subs_mgr.h, savan_publisher.h and savan_filter_mod.h respectively. I'll explain these three components separately in following sections.

Apart from these three important components there is a client component which implement the client API whic is used by Savan/C subscribers to subscribe, renew, query status of the subscription and unsubscribe.

Rest of the components are just implementation specific and bear no interest for the Savan/C user. They are core component which is the main Savan/C module for Axis2/C, util component which provide common utility functions and msgreceivers which is Savan/C specific message receiver for Axis2/C and subscribers which is the internal representation of a subscriber.

Savan/C specific message receiver plays an important role within the Savan/C as you understand in next paragraph. Basically it handles the subscription related requests from the subscribers and handle the reqeusts for event brokering.

### Subscription Manager

Subscription manager basically support CRUD operations on subscribers. When a subcriber related operation hit the Savan/C message receiver it call on one of the CRUD operation defined in the subscription manager api with the retrieved information from the message. The subscription manager implementation is pluggable meaning that the usr can implement his own storage manager and configure Savan/C to accept his subscription manager instead of the default. Savan/C ships with three subscription managers. They ar sqlite based subscription manager and service based subscription manager. By default sqlite based subscription manager is activated which result in storing the subscriber infomation in a embedded sqlite database.

Sqlite based:

Sqlite based subscription manager uses an embedded sqlite database to store the subscriptions. This option is enabled by default when configuring Savan/C. The savan_resource parameter in module.xml should be supplied with the path where the sqlite database should be created as in

    <parameter name="savan_resource" locked="false">/tmp/savan_db</parameter>

where you have to replace /tmp with your own path.

Service based:

Service based subscription manager connect to a remote web services through a Savan specific soap API to store subscribers. The remote web service is implemented as a Axis2/c web service. It provides CRUD operations to store subscribers perhaps using a embedded sqlite subscription manager internally deployed. In otherwords this subscription storage service internally use Savan/C subscription manager api's to store it's data. So in the server where this subscription storage service running Axis2/C should be running with the storage service deployed and Savan/C should be engaged to the service. Also an subscription manager should be configured for that service.

WSO2 registry based:

WSO2 registry is an enterprise-ready opensource product governing SOA deployments. With WSO2 registry, you can store, catalog, index and manage enterprise metada in a simple and scalable model. Savan/C can be configured to use a registry based subscription manager. This subscription manager depends on WSO2 regisry client to access the registry remotely through an ATOM API. For this subscription manager the savan_resource parameter in module.xml should be supplied with the registry access arguments as in

    <parameter name="savan_resource" locked="false">http://localhost:9763/registry</parameter>
    <parameter name="username" locked="false">admin</parameter>
    <parameter name="password" locked="false">admin</parameter>

where you have to replace the registry url with your own registry url.

### Publisher

xxx

### Filters

xxx

## How it work together

## Understanding the internal dependancies

It is useful to understand the dependancies between the Savan/C components.

libmod_savan.so depends on

- handlers
- util
- savan_storage

libsavan_msgreceivers.so depends on

- publisher
- storage
- util

libsavan_util.so depends on

- subscribers

libsavan_client.so depends on

- util
- storage
- filter

registry storage depends on

- common_storage
- registry_client

sqlite storage depends on

- common_storage
- sqlite

esb publisher depends on

- util
- common_publisher

default publisher depends on

- util
- filter
- common_publisher

xpath filter depends on

- common_filter
- libxml2

### Notes

1. Note1
2. Note2