A Web service process may fail to complete due to faulty Web services.
As these Web services belong to different organization and their
internal behaviour is unknown to external world, diagnosing the causes
of the failure is difficult. But if we can, we can charge a penalty to
the faulty Web services and design automatic fault recover actions.
Current software technique offers the try-catch mechanism for fault
handling. The software developer associates an exception with a fault
at the design time. When an exception which causes the halt of the
process is caught, we deduce that the associated faults have ever
occurred. This method relies on the expertise of the software
developer. The assumed cause of the exception may not be true. In this
case, it is a false diagnosis. Or there are more causes of the
exception, that the developer is not aware of. In this case, it is an
incomplete diagnosis.
Our moel-based diagnosis approach automatically diagnose the causes of
the exceptions in a Web service process. An automaton model is built
for a Web service process described in an xml language called BPEL
(Business Process execution Language). When an exception is received at
the run time, the diagnosis function can give all real causes of the
exception, i.e. giving a list of all possibly faulty Web services. This
work collaborates with IRISA (France) and University of Paris (France).
The novelty of this approach
1) Avoid modeling the fault behaviour, i.e. you do not need to know how
the process can be faulty. What you need is a process definition that
describes what the right behaviour the process should be.
2) Give complete and sound diagnosis, i.e. a complete list of faulty
Web services, and the list is guaranteed to be correct, in the sense of
model-based reasoning.
3) Practically it can be used as a generic fault handling mechanism. It
is especially useful when you have too many alarms or exceptions to
enumerate in your process description and when you cannot write a
specific fault handler to each of the caught exceptions. It is the case
in network communication networks.
Implementation:
The monitoring and diagnosing functions have been intersted into an
open source BPEL engine. We have put our demo on YouTube. This video
clip shows: (1) ActiveBPEL interface and functions; (2) Addiing a
monitoring listner and monitoring the Web service statues; (3)
Diagnosis function is triggered after an exception induced from
ActiveBPEL interface.
(Last update Aril, 2007)
Authors: Yong Lian and Xinge Du (Master's in UNB), Abhijeet Roy (Undergraduate in UNB)
OISEE stands for Online Interactive Science and Engineering Experiment
System. Online experimentation allows students from anywhere to operate
remote instruments at any time. We use SOA for the architecture of the
online experiment system.
We have developed a generic methodology to wrap commercial instruments
using IVI and VISA standard as Web services. We have developed Web 2.0
based techniques to display the virtual instrument panel and real time
signals with just a standard Web browser. You can operate the remote
instruments and observe the output use a standard Web browser. The
technique developed in this paper can be widely used for different real
laboratories, such as microelectronics, chemical engineering, polymer
crystallization, structural engineering, and signal processing.
The courseware management functions are based on open source Moodle.
Currently it has the functions to manage an online course, such as
content management, student management, collaborative functions etc.
(This one has been taken offline)
Author: Matthias Klein (Master's in UNB)
This e-learning site uses multimedia materials and rich links between
them for music learning. Learning objects are music score, background
knowledge and performances organized around pieces of music,
instruments and musicians.
Instead of using existing Learning Management systems, this project
uses portal platform as its architecture. The advantage of this
architecture is that the e-learning system can share modules, such as
user management and collaboration tools, and use information, such as
database and file system, available in the enterprise portal for
learning functions. The e-learning portlet can be deployed into any
standard compliant portal platform (compliant to JSR-168) without any
code changes.
