Extending UDDI with Recommendations: An
Association Analysis Approach
Andrea Powles and Shonali Krishnaswamy
School of Computer Science and Software Engineering
900 Dandenong Road, Monash University, Caulfield
East, Victoria –3145, Australia.
Abstract. This paper presents a
novel recommendation extension to UDDI that
we term RUDDIS. Recommendations can have potential benefits to both
providers and consumers of Web Services. We adopt a unique technique to
making recommendations that applies association analysis rather than
traditional collaborative filtering approach. We present the implementation and
demonstrate the functioning of RUDDIS in an unobtrusive manner where the
user has total control over the recommendation process.
1 Introduction
Recommendations are used in a wide variety of e-commerce applications such as
Amazon.com. Recommendations are useful for both buyers and sellers. For sellers,
they provide a means to highlight additional products and for buyers they provide a
filtered list of options to consider.
A natural and intuitive extension to the use of recommender systems in e-
mmerce is the investigation of such recommendations within web services. With
the increasing recognition of the commercial potential of the service oriented
paradigm, it is conceivable that recommendations within services can be of
significant benefit and use. Providing recommendations for Web Services has the
potential to offer many benefits for accessibility and usability of Web Services for
both users and providers. It could present users with alternative or additional Web
Service selections thus improving the likelihood that a web service will be consumed
and that useful Web Services are being provided to users. Web Service providers
could see an increase in the use of the Web Services they are providing as they
would see greater exposure to possible users.
This paper presents a first investigation into incorporating a recommendation
ponent within the web services framework. We propose a plug-in component to
UDDI that extends the functionality of the UDDI from a discovery mechanism to one
that performs discovery and recommendations for web service search queries. The
focus on UDDI is evidently due its role as the standardised directory service
component within current web services framework. As the UDDI specification has
been designed with extensibility as a priority it is limited to only a few set functions.
There have been numerous models and implementations for extending the UDDI
Powles A. and Krishnaswamy S. (2005).
Extending UDDI with Recommendations: An Association Analysis Approach.
In Proceedings of the Joint Workshop on Web Services and Model-Dr iven Enterprise Information Systems, pages 67-76
DOI: 10.5220/0002561900670076
specification to address existing limitations including Rashid (2003), Lyell (2003),
Systinet (2004), and Pokraev (2003).
While there have been many extensions of UDDI, there is yet to be any
investigation into the use of recommendations for Web Services. With the expected
increase of Web Service use, it will be beneficial for the UDDI to be able to provide
recommendations of Web Services. Web Services would gain additional exposure
through a UDDI that provides recommendations and users or systems looking to
integrate or consume a particular Web Service would benefit as they are provided
with additional Web Services that could be of use to them.
In developing a recommendation framework for service oriented architectures –
we had two possible options: Automated Collaborative Filtering (ACF) (Herlocker
2000) and content-based approaches (Sarwar 2004). Automated Collaborative
Filtering (ACF) is a widely used process for recommending information, services or
physical items that are of potential use for a person based on ratings provided by
other "similar" users. In content-based approaches the focus is on usage patterns
rather than having a user focus. In ACF, similarity of users is typically based on
maintaining user profiles. ACF is used in a wide variety of applications such as e-
commerce (typically agent-based systems such as (Guttman 1998), recommendations
for books [Amazon.com], music [CDNow.com] and movies [MovieFinder.com]. The
key distinguishing feature of ACF as opposed to "content-based" approaches to
making recommendations is the incorporation of the user dimension. However, there
are several major challenges in developing ACF systems [HKR00]: the difficulty in
developing valid user profiles, the question of mapping user profiles to individual
preferences and tastes for varied items and services, the application of user ratings
that do not capture the rationale for the ratings provided, the dependence on user
ratings that tend to be subjective, and the requirement for users to provide additional
information and perform extra tasks in providing the ratings.
The entire premise of ACF rests on the notion that similarity between users can
be captured and represented. This premise is certainly valid when the objects in
question are movies, books or music - but becomes intractable when the question
pertains to web services. Consider questions such as: what makes two users invoke a
particular weather information service as opposed to another? Building such user
models for services is a worthwhile consideration – however, it requires considerable
user psychology and usage patterns to be available in order to develop such user
models. Furthermore, the dependence on users providing ratings is very obtrusive
and the uptake of this - given the very limited incentives in a service oriented
environment - is also questionable.
Therefore, this project aims to address these issues of ACF by using a content-
based approach. This project proposes the use of association analysis [WiE99] to
support recommendations in the web service environment. Association analysis or
association rule mining is widely used as a data mining technique in the retail industry
to perform tasks such as Market-Basket Analysis to search for interesting customer
habits by looking at associations (Witten 1999). The classical example is the one
where a store was reported to have discovered that people buying nappies tend also to
buy beer. It is also used in applications in marketing, store layout, customer
segmentation, medicine and finance. However, the value of using the concept of
association analysis in a wider context is slowly emerging with applications in
content-based image retrieval [MSP04]. The primary aim of association analysis is to
discover groups of items that occur together. Given a set of transactions {T}, each
containing a subset of items from an item set {i
, i
, …, i
}, the focus is on the
discovery of association relationships or correlations among a set of items. The
strength of such associations is expressed by means measures known as support (i.e.
the probability of a set of items occurring together (P(i
)) and confidence (i.e the
conditional probability of a set of items (i
) appearing given that a set of items (i
exists (P(i
| i
)) ). The support indicates the frequency, while confidence denotes the
strength of the association. In the context of service oriented environment, this
technique alleviates many of the disadvantages highlighted with ACF, while retaining
the strength that it is also like ACF derived from a user-centric basis. In association
analysis, the transaction is derived from user activity – that is the user determines how
services are invoked in conjunction with each other. This is the fundamental basis for
performing an association analysis. On the other hand, it does not presume to build or
rely on user profiles and identification of similarity between users, which is inherently
challenging in the context of service oriented environments at this stage of its
evolution. However, it may be foreseen that in future when such widespread user
models and interactions are available ACF maybe used to in conjunction with
content-based approaches (Pennock 2001)enhance results obtained through
techniques such as association analysis. Furthermore, the occurrence of objects / items
in a transaction is an easily documented event and there is no additional overhead in
getting users to rate the objects / items they use. This “preferential rating” may easily
be established through implicit means such as frequency and duration of usage by the
same user.
We also note that the use of data mining techniques for recommendations in e-
commerce (Schafer 2001) has been validated. The paper is organized as follows. In
section 2 we present the design considerations and architecture of our UDDI
extension to perform recommendations – RUDDIS. Section 3 presents the
implementation of RUDDIS. Section 4 demonstrates its functioning using both a local
and external UDDI. Finally section 5 concludes this paper.
2 Recommendations in UDDI (RUDDIS)
We are proposing the use of UDDI as a Recommender system. We term this model as
Recommender Universal Description, Discovery and Integration System (RUDDIS).
RUDDIS will consist of a UDDI registry encompassing a Recommendation
component. This section examines the considerations and issues for the RUDDIS
model. An UDDI that includes a Recommendation component should contain the
following features:
The model should conform to the UDDI specification and have minimal or no
impact on the existing Web Services stack. The specification integrity being
maintained is vital to the entire infrastructure and purpose of Web Services.
Should the integrity of the specification be violated then interoperable nature
strived for by Web Services may be foregone.
Minimal effort should be required from the user to utilise RUDDIS compared to
utilising a standard UDDI.
The model should support the provision of useful and meaningful
The key concern to be deliberated with regards to the design for the UDDI
framework that includes a recommendation component is how to keep the UDDI
compliant with the specification. The UDDI API Specification document provided
by OASIS (Bellwood 2002) describes the programming interface and expected
behaviours of all instances of the UDDI registry. When enhancing UDDI it is crucial
to keep the standards set by this specification document. The UDDI data structures in
the specification provide a framework for the description of basic service
information, and an extensible mechanism to specify detailed service access
information using any standard description language. Web Services are based on
open standards which is the key to its heterogeneity. Altering the standards could
damage the ability of others being able to use the Web Service stack. In this context,
it is essential for RUDDIS to keep the recommendation and the UDDI components
separate to ensure the compliance of the existing standards. The recommendation
component and the UDDI component will be able to plug into each other via the
calls made to and from RUDDIS. This way the UDDI will not require any internal
modification and will maintain its integrity. This will allow the UDDI to function as
normal. Service providers still wishing to register Web Services in the UDDI can do
so as per usual. Clients wanting to search for Web Services without being provided
with recommendations can do so with the RUDDIS model. With this transparency
being modelled the user may never know they are using an extended UDDI.
In order for RUDDIS to provide useful recommendations we investigate the use
of Recommendations using Market Basket Analysis. Market Basket Analysis is
mainly used for data mining in the retail industry for discovering association rules
between items in the data (Witten 1999). For example if we have a video shop that
has a database of every hire transaction ever made over the history of the store. Each
transaction contains customer details, the videos hired, how many and the video type
e.g. Comedy, Romance, Horror, Drama or Action. As we mine through this data we
find that in the cases where there was more than one video hired, selecting type
Drama, 50% of the time also implies a comedy video was also hired. Then rule can
be described as “drama” Î “comedy”. Knowing such information can be very
useful. In this case the store manager could place the Drama and Comedy sections
closer together or introduce a special promotion for the two types when hired
together. Association analysis is a relatively simple yet effective analysis tool and
should be able to be implemented into a Recommendation System algorithm with
ease. The Apriori algorithm (Witten 1999) or its many variants and enhancements
are widely used as an effective implementation tool to support association analysis. It
is simple and is computationally efficient. We propose to use Apriori for facilitation
recommendation in RUDDIS.
We now examine how to ensure the model supports the provision of useful
accurate recommendations. For the recommendations to be accurate, data being used
to generate the rules needs to be accurate and up to date. RUDDIS is concerned with
firstly how to obtain the data that will be used to generate the association rules then
secondly, often the rules will be refreshed. Refreshing of the rules will require extra
processing by the system which may slow down the performance. There is the need
to weigh the importance of the performance of the system against the provision of
the most accurate recommendations. We establish that to obtain the data required to
generate the association rules the users interactions with RUDDIS will be recorded.
The details of all the queries made by users will be saved into a RUDDIS usage
database. When the rules require refreshing the data from the RUDDIS usage
database will be run through the Apriori algorithm to generate the rules. Also
established is that the user should be able to determine the frequency of updating the
rules. This way the user has control over the performance of RUDDIS as updating
requires extra processing power. We also believe that it is essential to design this
recommendation component such that it can be situated at the client or UDDI server
for maximum flexibility.
2.1 RUDDIS Architecture
A scenario that could take place with the use of RUDDIS, is that a possible user is
interested in searching for Web Services to do with planning a family trip to the east
coast. Using RUDDIS, the user is looking up Web Services on airline flights to get
there. The RUDDIS usage database contains all the Web Service requests made to
RUDDIS and to which session it belonged. The RUDDIS usage database is utilised
when recommendation rules need to be found. When our user enters in the query
“flights”, it is recorded in the RUDDIS usage database. Any other Web Service
requests made by the same user at the one time will also be recorded under the same
session. Also occurring in RUDDIS, is the data from the RUDDIS usage database
being run through the Apriori algorithm producing a set of association rules.
RUDDIS then seeks out any rules supporting “flights”, if there are rules for this
query item existing, the supporting rule with the strongest confidence level is found
and the association item in that rule is extracted. So there maybe two rules for our
query found such as “flights” Î “car hire” and “flights” Î “accommodation”.
Which ever rule of the two has the strongest confidence level for example the
“flights” Î “accommodation” rule, gets the associated item extracted, in this
example, “accommodation”. The original query “flights” is then queried in the UDDI
registry which contains the details of all registered Web Services. The association
item extracted, “accommodation” is then also queried in the UDDI registry. For
either of the two queries any Web Services found, are compiled and presented to the
user, who may then decided to proceed integrating the Web Services.
The following five elements illustrated in Figure 1 have been identified as being
required to carry out the tasks needed to be accomplished by RUDDIS.
The Manager Component: Is in control of handling all the interactions with the
interface. As a Web Service request comes through the Manager Component
evaluates the environment options selected by the user and the query item. It then
directs the requests being made to the appropriate components. Any items returning
from the other components are managed and acted upon by the Manager Component.
Fig. 1. RUDDIS Architecture
UDDI Query Component: Is in control of interacting with the UDDI registry which
stores all the Web Services details. When passed a query item by the Manager
Component it encapsulates the query into the appropriate format used for inquiries to
the UDDI. It is supported by the UDDI API client framework which assists in the
discovery of Web Services when requests are made. Any Web Services retrieved are
then passed through to the Manager Component to deliver back to the user.
Database interfaces Component: Is in control of monitoring any databases within
RUDDIS. Primarily this will be the RUDDIS usage database, but enables the
provision of additional databases to be added to the system if this flexibility is
required. Interactions between the Manager, Recommendation, Usage tracking and
Databases interfaces Components occur when the tracking data is being recorded and
when the RUDDIS usage database data is needed to run through the Apriori
Recommendation Component: Is in control of discovering the association rules in
RUDDIS and finding the strongest rule for the Web Service query being made by the
user. If any results are found they are then passed back to the Manager Component to
forward onto the UDDI Query Component, who sees if any correlating Web Services
exist in the registry. It ensures the processes of extracting the data from the RUDDIS
usage database and running the Apriori algorithm to generate the association rules.
Usage tracking Component: Is in control of ensuing that the users session and all
the Web Services requested during the session are recorded. This data will be stored
in the RUDDIS usage database through the use of the Database interfaces
Each of the components have there own task which they are responsible for, but are
required to communicate with each other to accomplish providing the
recommendations to the user.
3 RUDDIS Implementation
A preliminary investigation of available UDDI implementations was required to
select one for implementation. In order to determine which UDDI registry to utilise
the following criteria was used in assessments. Based on the investigation we
selected the use of the open source UDDI juddi supported by the use of UDDI4J
(UDDI for Java) as the client. This selection was also based on recommendations
being made for these two technologies being used together (UDDI.org, Hess 2004,
Jung 2003).
The recommendation component in RUDDIS requires the ability to process the
data from the Usage database using the Apriori algorithm. WEKA stands for the
Waikato Environment for Knowledge Analysis. It provides practical machine
learning tools and techniques with Java implementations (Witten 1999). WEKA
contains an Apriori implementation which can be used to run the usage data through
to find association rules.
The implementation was built using Java. The RUDDIS implementation was built
as a web application using a combination of Java Server Pages (JSP) and Java
Servlets running on the Jakarta Tomcat Server. For the describing of Web Services,
they are categorised into two types, businesses and services. In RUDDIS the
assumption is made that what we do for business can also be applied to services. For
the implementation we have only the inquiry of businesses in the UDDI registry.
The Graphical User Interface (GUI) was implemented for RUDDIS takes the form
of a web application to be used in a web browser that then accesses the juddi registry
that resides on a server. The interface of RUDDIS was tailored to look like a
standard UDDI interface with just some minor enhancements to assist with the
recommendation section of the application and the facilitation of the selecting of
various environment options. The interface is aimed to comply with the look and feel
of existing public registries. Figure 2 provides a screen shot of the RUDDIS GUI.
4 RUDDIS At Work
The primary function of RUDDIS is to extend the UDDI to comprise of the ability to
make recommendations of Web Services. Aside from this RUDDIS also allows the
user to make various selections with regards to the recommendations being made.
The section demonstrates the functioning of RUDDIS. This section illustrates the
feasibility of our approach and various options provided to the user to control the
operation of RUDDIS such that the user has total control and the recommender
system is as unobtrusive as possible. We now illustrate the options are as follows:
A comparison of querying a local UDDI registry to querying an external
registry for Web Services. The user is presented with the selection of Registry being
either “juddi – internal” or “IBM – external”. When juddi is selected the juddi UDDI
registry on the local host is queried for Web Services. When IBM is selected the
IBM test registry on an external server is queried for Web Services.
A comparison of RUDDIS providing recommendations to RUDDIS working as
a typical UDDI by not providing any recommendations. The user is presented with
the selection of Recommendations being either “on” or “off”. When “on” is selected,
RUDDIS will attempt to provide any recommended Web Services found in the
UDDI registry. When “off”, RUDDIS will function as a typical UDDI providing
only the Web Services found for the query item and not attempt to provide any
For the purpose of assisting in the evaluation of RUDDIS, the juddi registry
database was populated with an assortment of 315 web service names. The
appropriate usage data was synthetically generated and used to populate the usage
database to assist in the provision of recommendations. The usage database contains
around 135 different sessions, each containing a number of Web Service requests.
The RUDDIS usage database has been set up to assure that some rules supporting
different scenarios will be generated. The evaluation data was used to generate the
ARFF file required by WEKA. This lists the 24 rules discovered once the usage data
is processed by WEKA. One of the rules generated supports the evaluation query of
“skiing” Î “hire” meaning that a user looking for a Web Service on skiing would be
highly likely to also want to look for Web Services on “hire”. Other associations that
could be useful that support this query are “lift passes”, “snow reports” and “ski
lessons”. Rather than the user having to remember that these are items they could be
interested in using, RUDDIS can offer them as recommendations.
The purpose of evaluating the difference between running with and without
recommendations, is to compare RUDDIS in both scenarios. Not only do we want to
see that associations analysis recommendations can be made with the methods that
have been selected, but what the impact is on a typical UDDI in providing
recommendations. When recommendations were turned on and “Skiing” was entered
in as the Web Service query the following Web Service results produced included a
recommended services list: board hire, car hire, hire costs, ski hire, taxi hire,
toboggan hire and hire snow gear.
What is observed in the previous results is that RUDDIS searches through the
rules and finds that for skiing, the strongest association rule contained the result of
“hire”. Under the Web Services Found heading, the Web Services retrieved from the
registry that contain “skiing” are displayed. Under the Recommended Web Services
heading any Web Services from the registry that contain “hire” are displayed. These
were retrieved using find_business from UDDI specification. When
recommendations are sected off the Web Service results are exactly the same as
when recommendations are switched “on”, except obviously no recommendations
are provided. From examining these we can observe that the UDDI can be extended
to provide Web Service recommendations. Also that it can be implemented in such a
way that it can be requested ensure no recommendations are made.
We also evaluated to establish RUDDIS’ ability to access an external UDDI
registry. In this case the IBM test registry was used. Again the same query was
entered. RUDDIS searched through the rules and found that for skiing, “hire” was
the strongest rule result. It found no Web Services in the registry using the
find_business library that contained “skiing”. Under the Recommended Web
Services heading any Web Services from the registry that contained hire are
displayed. In this case there was one with the name of “Saphire”. RUDDIS is
dependant on what Web Services are registered in the external UDDI, so there were
no Web Services existing in the IBM test registry that suited the query “skiing”.
It can be determined from the above results that RUDDIS is successfully able to
access an alternative external registry to the juddi UDDI on the local server and
provide recommendations. The main difference is the Web Services retrieved as this
is obviously a IBM test registry that contains a different set of registered Web
5 Conclusions and Future Work
We have proposed and developed a recommendation extension to UDDI that we term
RUDDIS. Recommendations can have potential benefits to both providers and
consumers of Web Services. We have also adopted a novel approach to making
recommendations that applies association analysis rather than traditional collaborative
filtering approach. We have implemented and demonstrated the functioning of
RUDDIS in an unobtrusive manner where the user has total control over the
recommendation process. Further, we make no changes to the existing UDDI and the
recommendation component acts as a plug-in that can used locally or at the server
We recognise that while we have highlighted the usefulness of this approach and
demonstrated its practical feasibility – in order to fully validate such a model user
trials that collect real data are essential. We recognise this as a limitation of our work
so far. We plan to address these in at least a simulated context given that access to
real usage data at this stage of web services research and development is not feasible.
Furthermore, it is essential to determine the search space issues associated with a
large list of recommendations. This notwithstanding, this paper takes the first step
towards bringing the widely and successfully used concepts of recommendation in e-
commerce to area of service oriented computing.
1. Guttman, R, H., Moukas, A, G., and Maes, P., (1998), Agent-mediated electronic
commerce: A survey, Knowledge Eng. Rev., vol. 13, no. 2, pp. 147--159, 1998.
2. Herlocker, J, L. Konstan, J, A., and Reidl, J., (2000), Explaining Collaborative Filtering
Recommendations, P
roceedings of the 2000 ACM conference on Computer supported
cooperative work
, Philadelphia, Pennsylvania, USA, pp: 241 - 250
3. Hess Andreas, (19th March 2004), “How to set up your own UDDI registry” Andreas Hess
[online] Available: http://moguntia.ucd.ie/programming/uddi/ [Accessed 2 June 2004]
4. Jung, Christoph. (15
October 2003), “Discovering and Publishing Web Services with
JBoss.net” JBoss: Professional Open Source [online] Available:
http://www.jboss.org/developers/guides/jboss.net/uddi [Accessed: 2nd June 2004].
5. Lyell M, Rosen L, Casagni-Sinkins M , Norris D, (2003), “On Software Agents and Web
Services: Usage and Design Concepts and Issues”, The MITRE Corporation [online]
Available: http://www.agentus.com/WSABE2003/program/lyell.pdf [Accessed: 24th June
6. Padovitz, A., Krishnaswamy, S., and Loke, S, W., (2003), Towards Efficient and Smart
Selection of Web Service Providers Before Activation , Proceedings of the Workshop on
Web Services and Agent-based Engineering (WSABE 2003), [online] Available:
http://www.agentus.com/WSABE2003/program/shonali.pdf [Accessed: 24th June 2004].
7. Pennock David, Lawrence Steve, Popescul Alexandrin, and Ungar Lyle, “Probabilistic
Models for Unified Collaborative and Content-Based Recommendation in Sparse-Data
Environments“,In Proceedings of the Seventeenth Conference on Uncertainty in Artificial
Intelligence (UAI-2001), Morgan Kaufmann, San Francisco, 2001, pp. 437-444.
8. Pokraev, S. Koolwaaij, J. Wibbels, M. (2003, Aug, 4), “Extending UDDI with context-
aware features based on semantic service descriptions”, Xerox Corporation [online],
Available: https://doc.telin.nl/dscgi/ds.py/Get/File-30562/
UDDI__paper__camera_ready.pdf [Accessed 4 August 2003].
9. Rashid,A.ShaikhAli,O.F.Rana,David.W.Walker (2003)“UDDIe: An Extended Registry for
Web Services” [online], Department of Computer Science Cardiff University, UK
Available: http://www.wesc.ac.uk/projects/uddie/uddie/papers/saint03.pdf [Accessed: 24th
June 2004].
Sarwar B, Karypis G, Konstan J, Riedl J, (10 May 2001), “
Item-based Collaborative
Filtering Recommendation Algorithms”,
GroupLens Research Group/Army HPC Research
Center [online] Available:
http://www10.org/cdrom/papers/519/ [Accessed: 16th July
11. Schafer J Ben, Joseph A, Konstan, John Riedl, (2001 January - April), “E-Commerce
Recommendation Applications”, Data Mining and Knowledge Discovery,
5 (1-2): 115-153
12. Muller Henning, Squire David, Pun Thierry, (8
November 2003), “Learning from User
Behaviour in Image Retrieval: Application of the Market Basket Analysis”, International
Journal of Computer Vision, vol. 56, no.(1/2/3), pp. 65-77.
13. “Systinet” (2004) New Features in Systinet UDDI registry 5.0, Systinet [online] Availbale:
http://www.systinet.com/download/whats_new_in_wasp_uddi_5.0.pdf [Accessed: 29th
July 2004]
14. “UDDI.org: UDDI Products and Components” (2
April 2004) UDDI.org [online]
Available: http://www.uddi.org/solutions.html [Accessed 2 June 2004].
15. Windley Phillip, (10
July 2003), Managing the Web services flow, InfoWorld [online]
Available: http://www.computerworld.com.au/index.php?id=1765450771&fp=16&fpid=0
[Accesssed: 29
July 2004]
16. Witten Ian H, Frank Eibe, (October 1999), “Data Mining” Data Mining: Practical Machine
Learning Tools and Techniques with Java Implementations, Morgan Kaufmann, p105-111.