Showing posts with label LEAD. Show all posts
Showing posts with label LEAD. Show all posts

Tuesday, December 7, 2010

Mooshabaya and the Detailed Story..

Abstract
Visual composition of workflows enables end user to visually depict the workflow as a graph of activities in a process. Tools that support visual composition translate those visual models to traditional workflow languages such as BPEL and execute them thus freeing the end user of the need of knowing workflow languages. Mashups on the other hand, provide a lightweight mechanism for ordinary user centric service composition and creation, hence considered to have an active role in the web 2.0 paradigm. In this paper, we extend a visual workflow composition tool to support mashups, thus providing a comprehensive tooling platform for mashup development backed up by workflow style modeling capabilities, while expanding the reach of the workflow domain into web 2.0 resources with the potential of the mashups. Furthermore, our work opens up a new possibility of converging the mashup domain and workflow domain, thus capturing beneficial aspects from each domain.

Full Text




Before going into the Mooshabaya research, it is worth to have a look at the roots of Mooshabaya. JavaScript based Mashups - A content aggregation technology, that is used to compose services by remixing two or more sources [sample mashup site]. And the workflows - We prefer to represent real world processes as a sequence of operations, and here comes workflows. In practice both the mashups and the workflows have their own domain of applications. Workflows have gained their major use cases from the research communities as scientific workflows and the business communities as the business workflows. Mashups mostly target the end users and empower the user-oriented web.


What if a merge of the domains is possible? Can the domains use each other? This became the core research of  Mooshabaya.

Mooshabaya composes workflows graphically, and exports them as mashups. The mashups can then be executed and monitored at run time.
What motivates us into Mooshabaya? We have two major views. 1) As a Mashup Composer - Mashups can be created graphically by dragging and dropping components. 2) Extending the reach of the workflow domain. This includes web based APIs and web contents such as feeds. Mashup also becomes an alternative lightweight medium for workflow execution.

Before going further into Mooshabaya, we look at the related works. Yahoo Pipes, JackBe Presto, and Serena are some of the Mashup composers, that allow visual mashup composition through their graphical user interface. XBaya, Taverna, Triana, CAT (Composition Analysis Tool), Kepler, and Pegasus are some of the graphical workflow composers. Each of these tools has its own set of features and target use cases.

So what is special about Mooshabaya? Visual Mashup Composers mostly restrict themselves to Web 2.0 APIs. So far mashups are seen mostly as a content aggregation technology. Existing mashup composers do not support the monitoring of the execution of the mashups at run time. When considering the workflow composers, the traditional workflow languages have a high learning curves. Content aggregation is minimally supported in the existing tools. Mooshabaya is expected to fill these gaps in both the domains.

Let's have a look at the implementation of Mooshabaya. Registry Integration, Mashup Generation, Deployment, Monitoring, Security and the user interface are the major components.
Here we have the major use case of Mooshabaya. 

First the user wants to compose workflows - He integrates a web service registry into the system. Then he discovers and fetches the services metadata from the registry. By dragging and dropping the metadata files and other service components into the Mooshabaya canvas, he composes the workflows. 

Then he exports the workflow as a mashup. After that he can deploy the mashups into a mashup server. Here mashups are deployed into a mashup server and the relevant workflow files and the service metadata are stored into a registry. After the deployment, he can execute the mashups deployed in the mashup server and monitor them at the execution time. Secured services found in an Identity Server too can be used in the workflow composition.

As we discussed, Mooshabaya provides a solution for the complete mashup life cycle, where the existing  products are not providing at the moment. For example the monitoring phase of the mashups.

Our reasearch was mostly focused on the two domains. The integration of a WS-Eventing based notification system for remote monitoring of the mashups. Next we have the mashup security, based on username password based authentication.

Mooshabaya has used XBaya as the core workflow composer. Rather we can consider it a mashup generator for XBaya. WSO2 Mashup Server is used as the mashup server for Mooshabaya, and WSO2 Governance Registry as the web services registry. For the performance analysis, we benchmarked its performance against the XBaya's existing options. The performance graphs compare the file sizes and the generation times. The mashup file size was considerably smaller than the respective BPEL file, thus reducing the time to deploy the file to a remote server. The mashup generation time and BPEL generation time too were close to each other, without much difference. 

Scientific researches such as the LEAD system, business processes, and educational researches are the major target users of Mooshabaya. As a point for future works, we can mention that, Mooshabaya still can be extended with further research, specifically a web based interface, and the support for the delegated authentication scenarios.

Saturday, June 27, 2009

Quick installation : WS-Messenger

1. Download Messenger here and extract to a location, which will later be pointed as WSNT_HOME.
2. create a mysql database, use db/mysqlCreationScript.txt to create the tables in the database
3. update the config/db.config to point to the data base (sample here).
4. run ant war to create war file. messenger.war will be created inside WSNT_HOME/distribution folder.
5. Download and install a web container (we use apache tomcat), deploy the war file by dropping it into the tomcat webapps folder, and start tomcat.
6. run ./startMessenger.sh at WSNT_HOME to start the messenger. [In Windows, it is the *.bat file]. If the downloaded version's startMessenger has any trouble, try this.

Starting the message broker includes two processes.
The war file deployed in the web container, can be reached at http://localhost:8080/messenger/ after starting the web container. It is called the broker.
Delivery thread of WS-Messenger can be reached at http://localhost:12347/ by running the startMessenger.


Testing - Running a sample
Download nowTest.java and put it into the folder WSNT_HOME/test/org/indiana/extreme/queue.
Create a project using WSNT_HOME/test as the source root.
Add the WSNT_HOME/lib jar files, and WSNT_HOME/build/lib/wsmg.jar to the path.
After running the messenger as mentioned above, run the nowTest.java.

This will depict the case, where 10 subscribers subscribing to one of the 3 available publishers.

Tuesday, March 24, 2009

Event Notifier Service for LEAD System

EventNotifierServce is a notification system developed for LEAD [Linked Environments for Atmospheric Discovery] System developed at the extreme labs of Indiana University.
When a scientist runs a workflow, he can provide his interested events to the EventNotifierService with a notificationAddress. The service will listen to the workflows invoked by the scientists and notify them when an interested event occurs. Hence the Scientist can leave the system as he adds a request to listen to a particular workflow in the LEAD System, and hence his time will be saved.


Requirements
The program is tested to be run in Windows XP and Linux environments.


Setting up the event Notifier Service [More updated information can be found here.]

1. Download the Event Notifier Service from the SVN Tree:
https://svn.wso2.com/projects/lead/repo/event-notifier/
You will need the authentication password to access this SVN tree.
Alternately, you can download the files as archives from here.
This includes the messagebox code as well.

2. Download and set up the WS-MESSENGER, a messenger service built at Extreme! Labs using XSUL.

3. Configure the parameters included:
You will need to configure these files, which are inside the resources folder.
db.config : This config files contains the details needed to connect to the relevant database
epr.config : This config file mentions the end point reference
MailSender.properties : This properties file mentions the properties of the mail server. Currently the properties file has gmail as the mail server. When chosing the other mail servers or when you create your own mail server, you have to replace this properties file with that specific to your server.

4. Include puretls.jar and notification-types.jar included inside the lib directory into the axis2/lib.

5. Create a database 'EventNotify' and create tables using the db-creation.sql file included inside the resources folder.

6. Manually install the jars included inside the lib directory, and build using mvn. Alternatively you may prefer to use ant to build the project.
wsmg-1.76.1_a5.jar can also be downloaded from the original location:
notification-types.jar is an XMLBeans generated jar file for the given events schema.


You also need to manually download and install three jar files from the sun java web site due to the licensing requirements.


7. Deploy the generated zip file into the axis2 server.



Running Event Notifier Service
1. Starting the Messenger Service
Start Tomcat
Start Messenger

2. Starting the EventNotifierService
Start Simple Axis2 Server

Now the EventNotifierService is ready to be used.


Architecture

EventGenerator
This program includes a simple LEAD simulator which generates LEAD event notifications by reading the log file, leadevents.log included inside the resources directory.
In case of unavailability of the real LEAD system, you may use this program to simulate the system.

For this you have to run the EventGenerator.java included inside the edu.indiana.extreme.www.xgws.eventGenerator package.


Client
Client program included inside the syncClient package can be used to test the service. It will get the WorkflowID, eventsInterested, notificationMedium, and notificationAddress as String input. Here you may give multiple addresses and the eventsInterested as a String with the elements separated by a comma.


Limitation
The default notification medium is assumed to be email, and in case of email, the notifications will be sent as the events are received. In case of the other media, the events will be saved into an events table. If the notification medium is set to email, our program will handle the notification part, that is, it will notify the users as well. But as we haven't implemented the code for the other media, like SMS and IM, the program will save the relevant notification to the events table, and the notification part should be handled separately.

It should also be noted, in case of unavailability of the database the program will run in inMemory mode, where concurrentHashmaps are used to represent the tables, clients, events, and interests.