Mercury Instant Messaging Project Document
Mike Dacey [email protected]
Student#: 100102153
Directed Studies
Supervisor: Tony White
December 1 2004
Table Of Contents
Mercury Instant Messaging Project Document................................................................... 1
Introduction......................................................................................................................... 4
Glossary .............................................................................................................................. 6
Section 1 – Design .............................................................................................................. 7
1.1
– Requirements ....................................................................................................... 7
Functional Requirements ................................................................................................ 7
Non-Functional Requirements ........................................................................................ 8
1.2
- Use Cases.............................................................................................................. 9
Description...................................................................................................................... 9
Assumptions.................................................................................................................... 9
Actors............................................................................................................................ 10
UC-1: Configure Eclipse Instant Messaging ................................................................ 11
UC-2: Developers Add Users ....................................................................................... 12
UC-3: Developer adds new IM recipient. ..................................................................... 13
UC-4: The Developer checks out a file......................................................................... 14
UC-5: The Developer Commits a file........................................................................... 15
1.3
- Description of Classes ........................................................................................ 16
Design Decisions .......................................................................................................... 16
Eclipse Plug-in - Getting started ............................................................................... 16
Enhancing resource views......................................................................................... 16
Handling user editing and changes to resources ....................................................... 17
Streamlining repository-related tasks ....................................................................... 17
Enhancing platform integration ................................................................................ 17
Components and Classes............................................................................................... 18
Project Management Component.............................................................................. 18
Networking/Messaging Component ......................................................................... 18
User Interface Component ........................................................................................ 19
Users Component...................................................................................................... 19
1.4
- Message Sequence Charts .................................................................................. 20
Message Sequence Chart – Share Project..................................................................... 20
Message Sequence Chart – IM Session Construction................................................... 21
Message Sequence Chart – IM Message Construction................................................. 22
1.5
- Class Diagrams ................................................................................................... 23
Class Listing.................................................................................................................. 23
1.6 - Message Specification .............................................................................................. 24
Section 2 – Implementation and Observations ................................................................. 26
2.1
- Implementation Notes......................................................................................... 26
2.2 JabberD ....................................................................................................................... 27
Introduction............................................................................................................... 27
Background ............................................................................................................... 27
Core Functionality .................................................................................................... 27
2.3 Exodus Client.............................................................................................................. 29
2.4 Muse API .................................................................................................................... 30
2.5 Eclipse......................................................................................................................... 31
2
2.5 Future Considerations / Conclusions .......................................................................... 33
2.6 Installation and Usage................................................................................................. 34
Installation Instructions................................................................................................. 34
Sample Usage Script ..................................................................................................... 35
3
Introduction
The Mercury Instant Messaging Project represents a variation of the original Concord
Project. The original Concord was a “configuration management system for the Eclipse
software development environment which uses email as the transport mechanism. The
purpose of the system is to allow multiple developers to work on a common code base,
and as additions and changes are made to the code, they are propagated to the other
developers by email.”1
The Mercury Instant Messaging Project represents an almost totally new code base and
replaces the previous email transport with Instant Messaging. Due to their similar
problem space this project shares some of the original requirements and use cases that
were part of the original Concord.
Instant Messaging is now widely used and represents a quick and efficient means of
communication between individuals and groups. The intent of the Mercury Instant
Messaging Project is not to reinvent an Instant Messaging server or client but to enable
Eclipse to participate with other developers in an existing Instant Messaging
configuration regardless of the Instant Messaging server or client. (i.e. Jabber, Yahoo
Messenger, ICQ, Napster, AIM, Gnutella and XML Remote Procedure Call(XML-RPC))
In order to narrow the scope of this project I have decided to utilize the following:
• Instant Messaging Server – Jabber Server
• Instant Messaging Client – Exodus
• Instant Messaging Java API – Muse open source Jabber APIs
• Configuration Management – Mercury used the original Concord Project as an
example for creating a wrapper to a real repository like CVS or Clearcase.
Concord and Mercury’s Configuration Management was provided by sub classing
the RepositoryProvider class. All actions on CM related menu items result in
sending out an Instant Messages to everyone in the Development Group. The
project could be further extended in the future by implementing command line
calls to a selected CM application such as ClearCase, CVS, etc….
There are benefits from a security point of view to using a private Open Source IM server
and client. The server and client can be run from within a secure work environment
within an Intranet providing security for proprietary code and information. There are a
number of companies and Government Departments where this kind of security would be
essential
The Muse API is described on its WEB site as follows: “The Muse API is a Java API
with the goal of integrating all network-collaboration services into one. The API will give
an easy-to-use interface that allows you to log on to multiple services (i.e. ICQ, AIM,
MSN, Yahoo Messenger, IRC, Napster, Gnutella, Jabber, XMLRPC). There will be a
client GUI Framework to combine the use of all these services under one easy-to-access
API so that you can write GUI clients with much less effort.”
4
The goal is to setup a private Instant Messaging environment using the Jabber server and
Exodus client. Once established the Muse API will be used by Eclipse to send Instant
Messages to those registered within a Development Group informing them of any CM
related activities.
The software itself will be written in Java and will include a suitable user interface for
adding, editing and removing users from the Development Group. While this group will
mainly consist of developers it could also include anyone in management interested in the
ongoing activities that are taking place.
In keeping with the previous project I will begin with the formal requirements of the
system. From these requirements the functionality of the system is captured in Use Cases.
Each formal requirement will be addressed in at least one use case. For further
information see “Concord Project Document Patrick Dubroy <[email protected]> Student
#: 100281158 Directed Studies Supervisor: Prof. Tony White Monday, December 22,
2003”
Message Sequence Charts will be utilized to visualize the flow of messages that are sent
between classes in the system. To conclude the design Class Diagrams will be used to
show the class structure and their relationships.
The second section of the document will discuss the details of the implementation. This
section includes a postmortem of the various design decisions made and areas within the
code that either succeeded or failed. In conclusion suggestions are made on what future
additions could be attempted.
5
Glossary
Workspace
The set of all projects managed by Eclipse, including all of the contents of
the projects
Project
A top-level folder in the workspace. Individual projects can be associated
with Mercury in the Eclipse workspace, and their contents shared with
other developers.
Development Group
The list of people who are participating in collaborative development on a
Mercury project. Each Mercury project has exactly one development
group associated with it
Resource
Any component of the Eclipse workspace, including a project. A resource
usually corresponds directly to a file or folder on the file system.
Local Repository
The configuration management system local to the developer. Each
Mercury user has a local repository, which is accessible to him when
other developers are not online. Mercury will provide a simple
implementation of a local repository, but the interface is intended to
support other systems, such as CVS.
Release
To communicate the contents of a resource or set of resources to the
other members of the development group.
Commit
To put the current revision of a resource into the repository. Committing
to the local repository is analogous to releasing to the development
group.
Revision
A snapshot of a resource at a specific point in time. Each revision has an
identifier unique to the resource, i.e., the name of the resource and the
revision identifier unambiguously determine the contents of the revision.
Version
A symbolic name associated with a specific revision of a resource. A
resource may have more than one version, and the same version may be
associated with more than one resource. Also: To version a resource is
to associate a version with a resource in the repository.
6
Section 1 – Design
1.1 – Requirements
Functional Requirements
FR-1. The system should be a plug-in for Eclipse 3.0
FR-2. The system must have an installed version of a Jabber Server running and
accessible.
FR-3. The users must have access to the Exodus Client application.
FR-4. The users must have accounts setup via Exodus on the Jabber Server.
FR-5. The system is bounded by the nature of the Instant Messaging environment. Users
who are not currently on-line will not receive Instant Messages and Instant Messages will
not be resent.
FR-6. The system should allow multiple developers to work on a local copy/stream of a
project, propagating Instant Messages as actions take place against the repository.
FR-7. The format of the Instant Message (e.g. XML) is dependent on the MUSE API
implementation.
FR-8. Using the same Instant Messaging account a developer should be able to subscribe
to more than one project using this system, where the subscriber list for each project may
be different.
The system uses the Mercury Repository and should send Instant Messages for the
following actions.
FR-9. Share Project – begin collaborative development on a local project, i.e. adds at
least one other developer to the list of collaborators. A resource added to source control
sends an Added to Source Control Instant Message.
FR-10. The system should provide a user interface for adding and deleting developers in
the list of collaborators, and modifying the information for a developer, e.g. changing his
Instant Messaging address.
FR-11. Checkout – The system sends a Checkout Instant messages.
FR-12. Commit – The system sends a Commit Instant Message.
7
Non-Functional Requirements
NFR-1. The network must support Instant Messaging and allow outgoing Instant
Messages.
NFR-2. The system must use an Instant Messaging account that the user has set up on the
Jabber Server.
8
1.2 - Use Cases
Description
The following use cases describe the functionality of the Mercury Instant Messaging
project. Each use case maps to one or more functional requirements. The main actor in
these use cases will be a single Mercury user.
Assumptions
Software projects are usually set up directly with the projects repository such as CVS,
Clearcase, etc… The repository administrator grants developers access to those
repositories.
We can therefore make the following assumption:
1. There is no need for developers to accept invitations to be members of a group
since membership takes place while setting up the users repository permissions.
2. When a user shares his project he is simply putting that project under CM control.
Those who are members of that group will have access after updating their view
of the code.
9
Actors
There are four actors who take part in the Mercury Instant Messaging project. A
Developer is a Mercury Instant Messaging user. Developer is then generalized into a
Project Owner. A Project Owner is a Developer who shares a project with a development
group. In addition the Mercury Instant Messaging project interacts with two external
systems, the Jabber Server and Exodus Client.
10
UC-1: Configure Eclipse Instant Messaging
To setup Eclipse Instant Messaging each team member must select the Mercury
Repository and enter into the Development Group those IM users that they wish to
communicate with.
Actors:
Project Owner
Triggering Event:
TE-1.1 – Project Owner selects “Share Project” in Eclipse and selects Mercury as the
repository provider.
Pre-Condition:
None
Sequence
Use Case ID
UC-1.1
UC-1.2
UC-1.3
Description
The Project Owner selects
the project to share and
selects the Mercury
repository.
The Project Owner enters
the Instant Messaging
Addresses of the
collaborators on his Team
A new Project Instant
Messaging Group
containing the collaborators
entered is added to the
Eclipse workspace.
Tractability
FR-1, FR-9
FR-6, FR-10
FR-1, FR-10, Fr-8
11
UC-2: Developers Add Users
Developers setup the Instant Messaging environment after loading the Project.
Actors:
Developers
Triggering Event:
TE-1.1 – Developers receive notification of a resource placed under source control.
Pre-Condition:
None
Sequence
Use Case ID
UC-1.1
UC-1.2
UC-1.3
UC-1.4
Description
The project is associated
with Mercury in the Eclipse
workspace as an existing
project.
Tractability
FR-6, FR-10
All Developers enter the
Instant Messaging
Addresses of the
collaborators on his Team
A new Project Instant
Messaging Group
containing the collaborators
entered is added to the local
Eclipse workspace.
An Instant Message is sent
to each online collaborator
whose Instant Messaging
Address was entered,
whenever a resource is
added to source control.
FR-1
FR-1, FR-10, FR-8
FR-2, FR-3, FR-4, FR-5,
Fr-7
12
UC-3: Developer adds new IM recipient.
Developer adds a new IM recipient.
Actors:
Developers
Triggering Event:
TE-1.1 – User request IM notification.
Pre-Condition:
None
Sequence
Use Case ID
UC-1.1
Description
Tractability
The Developer adds a new
FR-10
Instant Messaging Recipient
to the Development Group.
13
UC-4: The Developer checks out a file.
Developer checks out a file.
Actors:
Developers
Triggering Event:
TE-1.1 – Developer requires to change a file.
Pre-Condition:
None
Sequence
Use Case ID
UC-1.1
Description
The Developer checks out a
file. This triggers an Instant
Message to be sent to
everyone in the
Development Group.
Tractability
FR-11
14
UC-5: The Developer Commits a file.
Developer commits their changes to a file.
Actors:
Developers
Triggering Event:
TE-1.1 – Developer decides to commit changes to a file.
Pre-Condition:
None
Sequence
Use Case ID
UC-1.1
Description
The Developer decides to
commit their changes to a
file. This triggers an Instant
to be sent to everyone in the
Development Group.
Tractability
FR-12
15
1.3 - Description of Classes
Design Decisions
As with the Concord project, Mercury is designed as a plug-in for the Eclipse
environment. The Eclipse Plug-in architecture is well defined and requires that the
programmer follow patterns that have been established by the Eclipse community.
Following these well-publicized procedures ensures that your plug-ins maintain good
behaviour both with Eclipse and other plug-ins.
The Eclipse Platform Plug-in Developer Guide
(http://help.eclipse.org/help21/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/team_
howto.htm) has been used for this project and provides step-by-step instructions on
Building An Integrated Team Provider.
Mercury consists of one Eclipse plug-in contained in the packages com.mdacey.mercury
and was developed using the following guide from the Eclipse Platform Plug-in
Developers Guide.
Eclipse Plug-in - Getting started
Define a
RepositoryProvider
that represents your
implementation.
Provide a
configuration wizard
so that users can
associate your
provider with their
projects.
Add your actions to
the Team menu.
•
•
Define your provider using
org.eclipse.team.core.repository.
Subclass RepositoryProvider and
implement the necessary methods.
•
Contribute a wizard using
org.eclipse.team.ui.configurationWiz
ards.
•
•
Add your actions to the Team menu.
Use the popupMenus extension to
define the menu items.
Enhancing resource views
Add provider-specific
properties to the
properties page for a
resource.
Implement specialized
decorators to show
team-related
attributes
Reduce clutter by
filtering out any
•
Use the propertyPages extension to
show team-specific properties for your
resource.
•
Contribute decorators to resource
views.
•
Use team-private resources to hide
implementation files and folders.
16
resources that are
used in implementing
team support.
Handling user editing and changes to resources
Intervene in the
saving of resources
so you can check
permissions before a
user changes a file.
Intervene before a
user edits a file to see
if it's allowed.
Track changes to
resources in the
workspace so you can
allow associated
changes in the
repository.
Enable the use of
linked resources
•
•
•
•
•
•
•
Implement the fileModificationValidator
hook.
Use validateSave to prevent or
intervene in saving of files.
Implement the fileModificationValidator
hook.
Use validateEdit to prevent or
intervene in saving of files.
Use the move/Delete hooks to prevent
or enhance moving and deleting of
resources.
See IMoveDeleteHook for more detail
about what you can do.
See Team and linked resources
Streamlining repository-related tasks
Provide an easy way
to export a description
of your projects.
Reduce clutter in the
repository by ignoring
files that can be
regenerated.
•
Use project sets to export your projects
without exporting the content so that
users can rebuild projects from the
repository.
•
Honor the ignore extension when
handling files and use ignore for your
plug-ins derived files.
Enhancing platform integration
Add provider-specific
preferences to the
preferences page.
Implement custom
views to show
detailed information
about repositories or
their resources.
Add your views or
actions to existing
workbench
perspectives if
appropriate.
Implement a
repository-specific
perspective to
streamline repository
•
•
•
•
Add your preferences to the Team
category.
Build your preference page using
workbench support.
Use the views extension to contribute a
view.
See the CVS provider's repository view
for an example.
•
Use the perspectiveExtension
extension to add your plug-ins shortcuts
or views to existing perspectives.
•
Use the perspectives extension to
define your own perspective, views,
short cuts, and page layout.
17
administration or
browsing.
The package com.mdacey.mercury contains the MercuryTeamProvider class, which is a
subclass of RepositoryProvider. The main intent of the MercuryTeamProvider is to
provide a Delegate for a real Repository such as Clearcase, CVS, etc… As in the original
Concord Project the main thrust was to show how emails and in this case Instant
Messages could be propagated to other team members when using a Repository. Both
projects provide an example of how these features can be added.
The Muse API provides an API that allows the user to communicate with a Jabber Server
and indirectly with an Exodus (Jabber) client.
Components and Classes
Project Management Component
MercuryTeamProvider
The MercuryTeamProvider will provide an interface between core Mercury classes and a
project in the Eclipse workspace. An instance of the MercuryTeamProvider will be
instantiated for each project associated with a Mercury Repository.
MercuryPlugin
The MercuryPlugin extends AbstractUIPlugin and is the core interface into the plug-in
architecture for Eclipse. The MercuryPlugin will be responsible for providing Mercury
access to the Eclipse environment and has responsibilities such as obtaining all Mercury
owned projects from the Eclipse environment.
Networking/Messaging Component
MercuryIMSessionManger – Manages an Instant Message Session and sending IM messages.
MercuryMessage The abstract superclass for all instant messages. MercuryMessage will
provide common behaviour for all Mercury IM messages.
CheckoutMessage – Instant Message sent when a file is checked out.
CheckinCommitMessage – Instant Message sent when a file is checked in.
AddToVersionControlMessage – Instant Message sent when a user places a resource
under version control.
18
User Interface Component
RepositorySharingWizard Part of the requirements stated in the Eclipse Platform Plugin Developer Guide - Getting Started Table, is the implementation of a SharingWizard.
The SharingWizard is used to associate a project with a specific repository, in this case
the Mercury Repository. The SharingWizard extends the org.eclipse.team.ui.
configurationWizards extension point with a class, which implements
IConfigurationWizard. For convenience, SharingWizard extends the abstract class
org.eclipse.jface.wizard.Wizard.
Checkout Action – This action will trigger sending a CheckoutMessage.
Commit Action – This action will trigger sending a CheckinCommitMessage.
AddToVersionControl Action – This action will trigger sending an
AddToVersionControlMessage.
ModifyDevelopmentGroupAction This action triggers the IMDevelopmentGroupDialog to
be displayed allowing the user to modify the Projects Development Group.
Users Component
Developer – An instance of a Mercury Developer
DevelopmentGroup – An instance of a group of developers working on a specific Project
19
1.4 - Message Sequence Charts
Message Sequence Chart – Share Project
20
Message Sequence Chart – IM Session
Construction
21
Message Sequence Chart – IM Message
Construction
22
1.5 - Class Diagrams
Class Listing
23
1.6 - Message Specification
The Muse API provides Java libraries allowing the programmer to concentrate on
developing Instant Messaging applications instead of low-level connections and transport
issues. Muse uses XML to encode all of its communications but hides all the details from
the end user! While the actual structure and creation of the XML is out of the
programmer’s hands it is still worthwhile to review the structure of this protocol for
exchanging messages.
The following was extracted from “Jabber away with instant messaging” written by
Jason Kitchen.
“Let's review the take a look at the XML exchanges that occur when we connect to the
server, log in, and send the message as described in the code above. In the following
XML exchange, the messages received by the client (our example code) are prefixed with
RECV, and messages sent to the server are prefixed with SEND:
SEND: <?xml version="1.0" encoding="UTF-8" ?>
<stream:stream to="localhost"
xmlns="jabber:client"
xmlns:stream="http://etherx.jabber.org/streams">
RECV: <stream:stream from="localhost" id="3D160545">
All Jabber exchanges occur in the context of an XML stream. During the lifetime of the
connection between our client code and the Jabber server, two complete XML documents
transfer a fragment at a time. The initial exchange shown above allows the client to start
sending the XML-streamed document to the server and the server to start sending the
XML-streamed document to the client. You can find the full details of XML streaming in
various reference texts and, of course, the Jabber specification (see Resources).
Next, a request for authorization information is sent to the server:
SEND: <iq xmlns="jabber:client" type='get' id='id_10028'>
<query xmlns="jabber:iq:auth">
<username>user</username>
</query>
</iq>
RECV: <iq xmlns="jabber:client" type='result' id='id_10028'>
<query xmlns="jabber:iq:auth">
<username>user</username>
<password />
24
<digest/>
<sequence>482</sequence>
<token>3D15E63A</token>
<resource />
</query>
</iq>
The preceding fragment shows the first exchange in the user authentication process. To
begin, the client asks the server what authentication methods are available for the given
user. The server fragment answers with the following authentication methods:
•
•
•
Plain text: <password /> tag
Zero-knowledge authentication: Uses the <sequence> and <token> tags
<digest/>: Like plain text, but the password is SHA-1 (Secure Hash Algorithm)encoded with the user's plain text password
We actually use <digest/>, as illustrated in the following fragment:
SEND: <iq xmlns="jabber:client" type='set' id='id_10030'>
<query xmlns="jabber:iq:auth">
<username>user</username>
<hash>425c73373237061edcc5f23ba239c6cc69556f5c</hash>
<resource>Home</resource>
</query>
</iq>
RECV: <iq xmlns="jabber:client" type='result' id='id_10030'></iq>
At this point, the user is logged in to the server and can begin sending or receiving
messages:
SEND: <message xmlns="jabber:client" type='headline'
id='id_10032' to='user2@localhost'>
<thread xmlns="jabber:client">id_10033</thread>
<subject xmlns="jabber:client">Hello world</subject>
<body xmlns="jabber:client">Hello world</body>
</message>
The above fragment shows the test headline message we send to the receiver
user2@localhost.
You might have noticed one recurring element in the preceding protocol fragments: the
ID tag. Because the session can consist of multiple asynchronous conversations, the ID
tag matches queries to responses. “
25
Section 2 – Implementation and Observations
2.1 - Implementation Notes
The goal of this project was to send Instant Messages to a specific group of developers
participating on a project triggered by a Configuration Management event. The project
succeeded in achieving this goal and was an interesting example of software integration
and coding. The Mercury project utilized the following:
•
•
•
•
JabberD Server
Exodus Client
Muse API
Eclipse 3.0
The project was a combination of software integration and development. The JabberD
Server, Exodus client, and Eclipse Plugin Architecture were integrated together to
provide a new type of service for the target developer. If more time were available the
Repository wrapper could have forwarded its calls to a real repository such as CVS.
The Muse API and Eclipse Plugin Architecture required both coding and configuration to
achieve the required functionality. Of the two I found the Eclipse Plugin Architecture the
trickiest to master since configuration errors were only found at runtime. Since the
compiler could not help, the normal result was either “nothing”, ( the plugin was not
loaded ) or a generic error stating that the event thread had caught an Exception.
Particularly baffling was the inability of Eclipse to find external jar files, even when you
told it where to look! Little is given in the way of explaining how this should be done,
only a good Google (search engine) finally found an answer. However, by the number of
similar developers on the Internet who seemed confused I was not alone. Fortunately
once you realize the trick it’s very clear what Eclipse wants!!
My initial mistake was to use a Java application to experiment with the Muse API. All
worked flawlessly. Then, as I finished the Eclipse Plugin development I thought I could
just copy my Muse code in and have it work. But no… Eclipse didn’t want to find my
muse jar file. This was definitely painful till I figured it out!!
The following is a quick review of the major components used in this project. I will give
a small introduction and follow it by excerpts from the various component user manuals
to give a feel for the various components.
26
2.2 JabberD
JabberD is the origional Jabber server implementation. It is open source, and was easy to
install, stable and was available for a variety of platforms such as UNIX, Linux,
Windows and Mac OS X. I found that all that was necessary to get going was to install
the application and run the server. It seemed to just work, what a delight!!
The following is from the JabberD admin guide and serves as a quick introduction to the
product.
Introduction
This document describes how to install, configure, and administer jabberd 1.4.x. The
jabberd server is the original open-source server implementation of the Jabber protocol,
and is the most popular software for deploying Jabber either inside a company or as a
public IM service. However, there exist numerous other Jabber server implementations,
including a number of open-source projects as well as commercial offerings (see the
server software list). As the organization that manages the Jabber protocol, the Jabber
Software Foundation (JSF) does not discriminate between Jabber implementations. At the
same time, the JSF recognizes that most Jabber deployments start out by using the
jabberd server, and thus has attempted to encourage the spread of Jabber technology by
documenting how to install, configure, and administer the jabberd server.
For support related to jabberd, server administrators are encouraged to subscribe to the
JADMIN mailing list (archive). For further information about Jabber, refer to the website
of the Jabber Software Foundation.
Background
The Jabber project was started by Jeremie Miller in 1998 as a free and open alternative to
the proprietary IM services offered by AIM, ICQ, MSN, and Yahoo. The first public
notice of the project occurred on Slashdot in January 1999. The core of the Jabber project
has always been the jabberd server, a modular server that is written in C and that uses the
GNU pth threading library. After over a year of development, jabberd 1.0 was released in
May 2000. The interim 1.2 version was released in October 2000, followed by version
1.4 in January 2001, version 1.4.1 in April 2001, version 1.4.2 in February 2002, and
version 1.4.3 in November 2003.
Concurrently to jabberd 1.4.x, jabberd 2 is developed, with its first stable release in
December 2003. jabberd 2 is practically rewritten from scratch and for example features
SQL support.
The jabberd 1.4.x server aims to be fully compliant with the XMPP protocol managed by
the Jabber Software Foundation. However, as the XMPP protocol is a recent standard,
jabberd 1.4.3 does not provide some XMPP features. Nevertheless, it is able to connect
with both XMPP compliant servers and clients.
Core Functionality
In essence, a Jabber server does the following:
27
•
accepts TCP socket connections from compatible clients and server-side
components
• manages XML streams to and from those clients and components
• delivers the core Jabber data types (<message/>, <presence/>, and <iq/>) to
authorized clients and components
• maintains session information for connected clients (usually IM users)
• if necessary, opens connections to and validates connections from other Jabber
servers, then routes data to them
• stores information on behalf of components and especially IM users, including
each user's contact list and some client preferences
Additional features -- such as multi-user chat, user directories, and interoperability with
legacy IM systems (AIM, ICQ, MSN, and Yahoo) -- are not part of the core messaging
and presence functionality of a Jabber server and therefore are not addressed in this
guide. Please see the Jabber Component Guide for further information about adding these
features to your Jabber server.
28
2.3 Exodus Client
Exodus is a Jabber compliant client that is easy to use and has a nice look and feel.
Exodus is fairly easy to learn and has proven to be very stable. The following is from the
Exodus web site http://exodus.jabberstudio.org/.
Exodus is a new Jabber ™ client being developed to be a "successor" to the very popular client
Winjab. It's smaller, faster, easier to use, and looks better.
Get Exodus
• Download Exodus
• You can visit the Jabberstudio Project page to file bug
reports, and make feature requests. This page also has
news announcements and releases available.
• Daily builds are here.
Mailing Lists
• Exodus Discussion & Announcements is a list for
general discussion and announcements.
• Exodus-Dev Mailing list is devoted to discussing
compilation issues, feature requests, design issues, etc.
Get Involved
If you're interested in working on the development of Exodus,
please feel free to checkout the source code. Make sure to the
read the readme.txt located in the main exodus directory before
emailing me about compilation issues.
29
2.4 Muse API
I was introduced to the Muse APIs by an article named “Jabber away with instant
messaging” by Jason Kitchen. This article formed the basis for the instant messaging in
Mercury. I found that Muse was very easy to use and understand and has proven to be
quite stable.
The following is an excerpt from the read me file included with muse, you can find their
web site at http://www.echomine.org/.
Echomine Muse API
Echomine Muse API gives you one easy-to-use set of APIs and frameworks for you to
connect with other communication services such as Gnutella, ICQ, MSN, Yahoo, AIM,
IRC, FTP, etc. It implements the protocols and then adds an extra layer on top of the
protocols so that access to all the services go through one unified API (similar to how
JDBC works).
License
Echomine Muse API is distributed under the Apache Software License. See the enclosed
license file for more information regarding legal issues on using this API.
Installation
Just add the required libraries in the lib/ directory into your classpath and you're ready to
go. Muse API is meant to be a low-level developer API so it does not contain any
application that can be run. Well, there are some example codes under the examples/
directory. Take a look and then you're ready to create your own application!
30
2.5 Eclipse
Eclipse 3.0 is a popular development environment that seems to be everywhere in today’s
software community. A number of private and government departments are using Eclipse
because of its stable, feature rich offering and due to its free access. In fact IBM feels
strongly enough about Eclipse that it has based its main development tool WebSphere on
the Eclipse platform. WebSphere is in fact a selection of plugins developed for Eclipse
and released under the IBM brand.
The following is from the Eclipse web site:
Eclipse.org is the website of the Eclipse Foundation.
Eclipse is an open platform for tool integration built by an open community of tool
providers. Operating under an open source paradigm, with a common public license that
provides royalty free source code and world wide redistribution rights, the eclipse
platform provides tool developers with ultimate flexibility and control over their software
technology.
Eclipse has formed an independent open eco-system around royalty-free technology and
a universal platform for tools integration. Eclipse based tools give developers freedom of
choice in a multi-language, multi-platform, multi-vendor environment. Eclipse provides a
plug-in based framework that makes it easier to create, integrate and utilize software
tools, saving time and money. By collaborating and exploiting core integration
technology, tool producers can leverage platform reuse and concentrate on core
competencies to create new development technology. The Eclipse Platform is written in
the Java language and comes with extensive plug-in construction toolkits and examples.
It has already been deployed on a range of development workstations including Linux,
QNX, OSx and Windows based systems. A full description of the Eclipse community and
white papers documenting the design and use of the Eclipse Platform are available at
http://www.eclipse.org.
Industry leaders Borland, IBM, MERANT, QNX Software Systems, Rational Software3,
Red Hat, SuSE, TogetherSoft3 and Webgain2 formed the initial eclipse.org Board of
Stewards in November 2001. In March of 2002, the board unanimously voted to add new
members, Serena, Sybase and Fujitsu. At the June 2002 meeting of the Board of
Stewards, Hitachi, Instantiations, MontaVista, Scapa Technologies and Telelogic were
added to the board membership. In September 2002, ETRI, HP, MKS and SlickEdit were
unanimously elected to the Board of Stewards. Also at the September board meeting,
Oracle's membership was approved. Catalyst Systems, Flashline, Parasoft, SAP,
teamstudio and TimeSys became members in December 2002. The board of stewards was
very pleased to welcome the Object Management Group (OMG) as an associate member.
In March 2003 the board welcomed associate member the Fraunhofer Institute, and
31
stewards representing Ericsson, LogicLibrary, M7 Corpororation, QA Systems and
SilverMark, Inc. We are now pleased to include stewards from Advanced Systems
Concepts, Genuitec and INNOOPRACT Informationssysteme GmbH. In May of 2003
the board welcomed new members CanyonBlue, Ensemble Systems, Intel, Micro Focus,
Tensilica and Wasabi.
On Feb 2, 2004 the Eclipse Board of Stewards announced Eclipse's reorganization into a
not-for-profit corporation. Originally a consortium that formed when IBM released the
Eclipse Platform into Open Source, Eclipse became an independent body that will drive
the platform’s evolution to benefit the providers of software development offerings and
end-users. All technology and source code provided to this fast-growing ecosystem will
remain openly available and royalty-free.
32
2.5 Future Considerations / Conclusions
The Mercury project is a good blueprint of integrating Instant Messaging within an
existing application. In this case the application is Eclipse and therefore WebSphere.
There are a number other areas where the addition of Instant Messaging into an
application would be a considerable asset. Specifically Instant Messages that are
autonomously generated within a secure environment.
This project has given me the chance to experiment with both Instant Messaging and
Eclipse Plug-in development. Instant Messaging and Muse provide an effective solution
to those software projects where quick notifications between applications are part of the
software specifications. Professionally, the Eclipse Plugin development experience has
been a definite asset as I have already been able to apply its benefits in my work
environment.
In conclusion I think that this was an excellent choice for an Honours Project. It has
provided me with a marketable set of skills and leaves behind a prototype that future
Carleton students can use for further studies in this area.
33
2.6 Installation and Usage
Installation Instructions
1. Download JabberD from http://jabberd.jabberstudio.org/1.4/ and save it onto the
designated server for your network. Then follow the installation procedures
published with JabberD.
2. Download Exodus from http://exodus.jabberstudio.org/ and save it onto all
participating workstations on your network. Again follow the installation
procedures published with Exodus.
3. Now setup a normal Instant Messaging environment. Each member will request
that an Instant Messaging relationship be established with every other member.
Test your setup; you must be able to send Instant Messages to everyone that will
be participating.
4. Download Eclipse 3.0 from http://www.eclipse.org/ and save it onto each
workstation, again follow the installation instructions that came with the
download.
5. Now unzip the Mercury distribution into the Eclipse installation directory, i.e. the
directory which contains the Eclipse executable and the plugins subdirectory.
6. Now download the org.apache.xerces_4.0.13 plugin from Apache and install this
in the plugin directory of Eclipse 3.0, it is required by Mercury. A copy is
included on the CD that accompanies this project.
7. Download the Muse API at http://open.echomine.org/cowiki/1.html and copy the
following jar files into the ./plugins/com.mdacey.mercury_1.-.0/lib directory.
• commons-logging.jar
• crimson-1.1.3.jar
• jakarta-oro.jar
• jdom.jar
• jsse.jar
• log4j.jar
• muse-0.8a4.jar
• xml-apis.jar
34
Sample Usage Script
1. Start the JabberD Server.
2. Start the Exodus Client. Your Instant Messaging environment must already be
setup.
3. Start Eclipse.
4. From the Window menu, select "Preferences".
5. On the "Mercury" preference page, select a repository directory. This should be
an empty, existing directory.
6. On the "Instant Messaging" preference page (under Mercury), enter your Instant
Messaging settings.
7. Now create a new project in the Eclipse workspace.
8. Now add a class to the project.
9. Right-click on the selected project, and select "Team->Share Project...".
10. Select "Mercury" as the repository type.
11. Add at least one other developer to the development group.
12. Click "Finish".
13. If you wish you can repeat steps 1-4 on a new copy of Eclipse in a fresh
workspace. This is not necessary to test the Instant Messaging functionality
however.
14. Now select the file that you created earlier and select Notice that only the “Add to
Source Control” menu item is enabled. Select “Add to Source Control”.
15. You should see Instant Messages sent to everyone in the Development Group.
The message indicates that the file was put under source control.
16. Right click on the file, now the menu item “Checkout” is highlighted. Select the
“Checkout” menu item. An Instant Message is sent to everyone in the
Development Group stating that the file has been checked out.
17. Now select the file again and right click on it. Notice that the “Checkin” menu
item is enabled but not the “Checkout” and “Add to Version Control” menu items.
Select “Checkin”. An Instant Message is sent to everyone in the Development
Group.
18. Now select the file again and right click. Select the “Edit Development Group”
menu item. Add or remove a developer from the Development Group. Experiment
to discover that the changes have worked.
35