Deliverable (public)

Transcription

Project Number
IST-1999-10375
Project Title
INTELLECT
Document Type
Deliverable
Document Title
Best Practice Report
Document Number
D18
Due Date
18/02/02
Delivery Date
08/03/02
Document Status
Final
Workpackage(s)
WP6
Security
Internal
File Name
INT-D18FINAL.doc
Short
Description
This document describes best practices from the INTELLECT project.
Keywords
Best Practice
Partners owning
BIBA
Partners contributed
All Partners
Made available to
Jorge Gasós (CEC)
INTELLECT
IST-1999-10375
Content
1
Starting point..................................................................................................................................... 4
1.1
INTELLECT Rationale ............................................................................................................... 4
1.2
INTELLECT Project Objectives ................................................................................................. 4
1.2.1
Technical Overview............................................................................................................ 4
1.3
INTELLECT Partnership............................................................................................................ 6
1.4
INTELLECT Approach............................................................................................................... 7
1.5
Innovation .................................................................................................................................. 7
2
INTELLECT Network Concept.......................................................................................................... 9
3
Experiencing the Pilots ................................................................................................................... 13
3.1
Effectiveness ........................................................................................................................... 13
3.1.1
Prototype platform ............................................................................................................ 13
3.1.2
Prototype architectural components ................................................................................ 16
3.2
Efficiency ................................................................................................................................. 18
3.2.1
3.2.1.1
Serving pre-generated HTML pages ........................................................................ 19
3.2.1.2
Serving HTML pages dynamically generated by Cocoon......................................... 19
3.2.1.3
Compiling, executing and serving XSP pages.......................................................... 20
3.2.1.4
Executing and serving pre-compiled XSP pages ..................................................... 20
3.2.1.5
Comparison between URLs from the three INTELLECT pilots ................................ 21
3.2.1.6
Comparison of different servlet engines ................................................................... 23
3.2.2
Configurator performance ................................................................................................ 24
3.2.2.1
Pure Java Implementation ........................................................................................ 25
3.2.2.2
SQL Implementation ................................................................................................. 27
3.2.2.3
SQL vs Java.............................................................................................................. 30
3.2.2.4
Conclusion ................................................................................................................ 31
3.2.3
4
eShop performance.......................................................................................................... 18
OrderProcessing performance ......................................................................................... 31
3.2.3.1
Database transactions .............................................................................................. 31
3.2.3.2
XML parsing.............................................................................................................. 31
3.2.3.3
XSL transformations ................................................................................................. 31
3.2.3.4
XPATH addressing ................................................................................................... 31
3.2.3.5
XML transformations................................................................................................. 31
3.2.3.6
Backoffice functionality ............................................................................................. 32
3.2.3.7
Results ...................................................................................................................... 32
3.2.4
Helpdesk performance ..................................................................................................... 32
3.2.5
VR Applet performance.................................................................................................... 32
INTELLECT Lean Configuration: Interactive Product Configuration for the Internet ..................... 34
4.1
Configuration concepts............................................................................................................ 35
4.1.1
INT-D18FINAL
Rules-based configuration ............................................................................................... 35
© The INTELLECT consortium – 2001
Page 2 of 58
INTELLECT
IST-1999-10375
4.1.2
Case-based configuration ................................................................................................ 35
4.1.3
Object oriented configuration ........................................................................................... 35
5
4.2
Requirements for on-line Configuration .................................................................................. 37
4.3
Lean Configuration .................................................................................................................. 37
4.4
INTELLECT Product Data Model ............................................................................................ 38
4.5
Implementation ........................................................................................................................ 41
4.6
Conclusion............................................................................................................................... 42
Secure Communication in Electronic Shop Systems ..................................................................... 43
5.1
Encryption................................................................................................................................ 43
5.1.1
Secret Key Encryption...................................................................................................... 43
5.1.2
Public Key Encryption ...................................................................................................... 44
5.2
Authentication and Digital Signature ....................................................................................... 44
5.2.1
Certificate and Certificate Authority (CA) ......................................................................... 45
5.2.2
Secure Socket Layer (SSL).............................................................................................. 45
5.2.2.1
5.2.3
5.3
6
7
8
9
SSL Protocol Stack: .................................................................................................. 46
HTTPS.............................................................................................................................. 47
Conclusion............................................................................................................................... 47
Help-desk System in E-Shop Systems........................................................................................... 48
6.1
IP communication .................................................................................................................... 48
6.2
Quality-of-Service .................................................................................................................... 49
6.3
Page Mirroring ......................................................................................................................... 50
Virtual Reality in variant Configuration ........................................................................................... 51
7.1
Functionality and implementation............................................................................................ 51
7.2
Creation of 3D-Data ................................................................................................................ 52
7.3
Conclusion:.............................................................................................................................. 54
Distributed Ordering system for the Extended Enterprise.............................................................. 55
8.1
Workflow system for incoming orders ..................................................................................... 55
8.2
Back-office system integration ................................................................................................ 55
8.3
Distributed Infrastructure ......................................................................................................... 55
8.4
XML parser issues................................................................................................................... 56
8.5
Conclusion............................................................................................................................... 56
Acknowledgements ........................................................................................................................ 57
References............................................................................................................................................. 58
INT-D18FINAL
Page 3 of 58
INTELLECT
IST-1999-10375
1 Starting point
1.1 INTELLECT Rationale
Even though the spreading of electronic shop systems grows continuously the presentation of the
products is mostly restricted to static pictures, in rare cases to stored videos. The opportunities to present the potential customers with the products including their variants and configurations using modern multi media techniques are not fully exploited in internet shops. An important reason for this situation is the poor support or even the lack of support by electronic shop systems for the product variant's
handling. This includes all possible variants and also automatically exclusion of impossible variants.
1.2 INTELLECT Project Objectives
To improve this situation the goal of the proposed project is the creation of an online configuration tool
for products. Customers of electronic shop systems should combine and select offered products via
Internet by the use of advanced multi media techniques and information.
Target group of companies are manufacturers, merchants, consultants, etc. who advise on or sell e. g.
bicycles, computer networks, computers, furniture, clothes, automobiles, travels. The customer continues visiting the electronic shop as usual via the Internet. The following cases should be taken into
account:
•
If the information presented does not fit the customer's needs, he will be able to configure the
selected product in all possible manners. Possible configurations are changing colours, composition or ingredients, equipment or décor, etc. Techniques to be used should be 3D views, virtual
reality, video and sound, textual support and more.
•
In case of questions the customer can contact the company's hotline or call centre via the Internet.
Internet phone, online chat system or video conferencing tools should be used to enter the support
process.
•
In addition the status of the current production or delivery process will be made visible to the customer with a monitoring tool attached to the order processing module.
•
Payment and/or clearing processes will be designed so that the various electronic means of payment are encapsulated in a system that will support as much as possible electronic currencies by
hiding their complexity to the users.
From the customer's point of view the system must be usable as easy as possible and should reflect
the proceedings of a 'real' shopping event one to one. The goal is to open the world of electronic purchase to the average consumer without any (computer related) specialised knowledge.
On-line configuration using 3D interfaces integrated into electronic shop systems with the use of a new
secure electronic financial transaction standard will lead to a new type of trade in the business sector
of trading and shopping.
1.2.1 Technical Overview
The system to be developed by the proposed INTELLECT project is composed of several modules
which are shown in the following figure. The main Intranet modules consist of the existing database
(management system) for the order processing module and electronic shopping. This database contains all product and order related information. It will be populated and updated using information already available in the supplier systems. This information will be updated on-line using standards for
the exchange of product data (e.g. STEP). In addition a second database is filled with multi media
representations (volumes models, sounds, videos, textures, etc.) as well as all rules of their interdependencies concerning the technical construction and representation of the company's product line.
A configuration module supports creation and population of this second database. An additional module, also based on the enhanced database information, is intended to generate print catalogues or
CD-ROM information.
Further – next to the electronic shop module – the presentation module is intended as the main module for online interaction with the customer. This module offers
INT-D18FINAL
Page 4 of 58
INTELLECT
IST-1999-10375
•
individual configuration of the viewed objects,
•
textual and audio visual explanations,
•
tips for the customer concerning his selections, things that fit well together in terms of technical
properties, style and design,
•
strength and weakness of the product when fitted with optional features and more.
oder receipt
customer
order
customer
selection
Internet
individual
configuration
All presentation on the screen of the customer's computer will be realised with newest multi media
technologies. Virtual reality (VRML) will be used to demonstrate e. g. the fit of the accessories selected to the virtual image of the main product.
user interface
interaction /
presentation
order processing
advanced shop
user interface
security module
catalogue preparation
(CD-ROM, printed)
configuration module
multimedia information,
rules
products, order
transactions
In case of unanswered questions the customer has the
possibility to call the company's hot line or call centre
with the application via the
Internet. Technologies to be
used are internet telephony
with screen sharing and / or
video conferencing.
The electronic shop module
takes the order of the customer over a secure connection via the Internet. At this
time a human employee
could carry out a spot check
of the order to attest the customer the correctness of the
order. An acknowledgement
with complete details of the
order will be returned automatically to the customer. In
addition a receipt with detailed information about the
possibility to trace the status
of the production or the delivery will be provided.
Intranet
Special attention will be directed to secure transactions over the Internet. The proposed project will
evaluate new emerging standards like the Internet Online Trading Protocol. IOPT is now being developed under the governance of the Trade Working Group of the Internet Engineering Task Force IETF.
The IOTP consortium has stated that they plan a pilot to support the German 'GeldKarte' card and
SET during 1999. The main focus of IOTP products is to establish interoperability, to enhance the
negotiation process of trading parameters, which subsume payment parameters, and to encapsulate
two or more of the available e-commerce payment schemes. These could be any combination of SET,
Mondex, CyberCash, VisaCash, Proton, GeldKarte, eCash, Millicent, E-Check, CyberCoin and edd
(electronic direct debit) to name just a few.
INT-D18FINAL
Page 5 of 58
INTELLECT
IST-1999-10375
1.3 INTELLECT Partnership
OptiNet GmbH the project co-ordinator is a German network services company. Their main areas are developing
and/or supporting their customers in the sectors of Internet, Intranet, Extranet, passive and active network components, and electronic commerce. Tasks of OptiNet are among other things conception and set-up of advanced
network solutions, security and firewall solutions, Internet access solutions, and training and coaching.
Partner
OptiNet
GmbH
BIBA
Anecon
Atlantide
S.A.
Blauwerk
HiTEC
Interset
CC
Main responsibility
D
Network service provide; project co-ordinator, developer and provider of the advanced internet service, and co-ordinator of the pilot system integration.
D Research Institute; developer of the variants' handling configuration module and visualisation of the product information; evaluation and dissemination activities.
A Bank software developer; implementation of system for secure electronic financial transactions supporting international standards.
F Software house and consulting; developer of the "Advanced Virtual Reality Internet Shop",
support of end users during the pilot phase.
A Small sized pushtype scooter producer; integration of system pilot, pilot site, end user.
F World class high-tech, high-performance, high-end bikes
EL Large computer hardware wholesaler
OptiNet hosts several electronic commerce solutions for customers. Main responsibility of OptiNet in
the project is to provide the shop, internet services, and networks.
Based on this experience and the restrictions of today's electronic shop systems OptiNet decided to
merge BIBA's experience in industrial variant handling procedures and applications, and OptiNet's
experience in electronic commerce solutions.
Looking how to develop a software demonstration pilot for their ideas they remembered the French
software house Atlantide. Atlantide was known as reliable partner and Atlantide's strategic development lines are in accordance with the planned development. Therefore Atlantide will be leader of the
"Software Concept" and Software Implementation" workpackages due to their experience. Their own
developments will be in the area of user interfaces to ensure a high grade of user friendliness, and in
integration of the other partners developments.
In electronic commerce the questions about security and payment is evident. A software company,
Anecon from Austria, committed themselves to complement the consortium in this area. They took
over the lead in the workpackages for conception and implementation of the security module for financial transactions. As a developer of bank and insurance software they are highly qualified for this task,
bringing in evident experience by former developments and by participation in appropriate bodies by
themselves and closely related companies.
BIBA will contribute the concept and prototype of the variant configuration module and on visualisation
of the product information. Finally, BIBA will disseminate the results of the INTELLECT project
throughout Europe by giving presentations on conferences, workshops and fairs. BIBA proposed as
highly qualified the bicycle manufacturing industry to join the consortium as and users.
Blauwerk is a manufacturer of pushtype scooters for adults. Blauwerk participates as end user who
aims to increase the customisability of its products via the Internet. Blauwerk has its own WWW site
but this shows only static product descriptions. Thus, they need tools and approaches for creating
configurable product models and the corresponding multimedia information.
HiTEC’s unique selling point and competitive edge as a bicycle manufacturer is the configurability of
their high performance products compared to those of the competitors. The customers can involve
themselves in the design of a product and thus get the feeling of obtaining additional (even exclusive)
information. This is made possible by extensive configuration possibilities allowing the end-user to
produce new variants on the product and to individualise them according to his taste, physical size etc.
Interset is a typical computer hardware wholesaler, offering its products to distributors and directly to
the customer. Due to the European spread of their production sites and market, Interset expects a
major benefit from the new INTELLECT tools for the availability of their product information both for
the customers and the company itself.
INT-D18FINAL
Page 6 of 58
INTELLECT
IST-1999-10375
1.4 INTELLECT Approach
Today's online shops offer different goods to Internet users. The shops are mostly realised to be used
with a World Wide Web browser, if necessary with additional plug-ins. The presentation of goods is
restricted to pictures, photos, textual descriptions or specifications, short video sequences and sound.
Interactive configuration or composition, 3-dimensional movable objects, variant's selection, and more
is not possible with the current systems. The field of bandwidth and transmission speed is not brought
into the focus of this proposal. The consortium is sure about the increase of performance in the Internet in the very near future.
Nearly all shop systems use database management systems to store and access all relevant information concerning products, orders, and buyers and a lot of them even have interfaces to current inhouse order processing systems. This is the point of departure to enhance the existing solutions with
new connectors based on standardised interfaces, protocols and languages (e.g. CORBA, ODBC,
JDBC). On the other hand, most of the systems lack a connection to product data, i. e. CAD, EDM or
PDM systems that would allow direct access to product configuration information.
Concerning paying methods from the customer's point of view various solutions are used to transfer
the money from credit card burden to electronic cash/money. The buyer as well as the vendor has to
own/support several means of payment to do business together. A third party concerned is the bank
which has to be integrated in all money processing tasks. To guarantee security for financial transactions also several solutions are implemented and have to be taken into account. From the technological point of view form paying mechanisms an international standardised procedure is missing to encapsulate existing transaction protocols. For this reason special attention must be drawn to secure
financial transactions. INTELLECT will strictly focus on standardised protocols (see 'IOTP' paragraph
in the workplan description)
Several software systems are available on the market to handle product variants. Most of them are
intended for complex products like assembly lines. Only very few applications are also suitable for
simpler and smaller articles like bicycles. The most important aspects to be covered by these systems
are the handling of the different product variants that have been actually generated. Additionally, it has
to be ensured, that only valid variants can be assembled. This is normally achieved by assigning rules
to all components, specifying the usage constraints.
1.5 Innovation
The INTELLECT project will use "intelligent" rules to define the degree of interaction the company
wants to deliver to customers on its product for individual configuration. Thus, these rules will be read
by the configuration module and processed to adapt customers individual configuration product tools
on its user interface, according to a limited set of behaviours. The main advantage consists in the opportunity for the company to personalise and make more attractive the services it offers to customers.
Normally the rules are defined using formal languages that are difficult to understand for the typical
customer or part supplier. It is therefore required to allow some kind of "nearly natural language" to
generate rules for new parts added to the database. The "intelligent" rules will be defined by the company itself. So, one of the main constraints will consist in giving the company the opportunity to easily
incorporate these rules in the second database and link them to the VRML and Java3D object parameters and behaviours.
For the envisaged goals, it is necessary to have an external interface that allows to import and export
the variant data in a neutral format and convert it into the 3D data needed for the visualisation.
Through this user interface, customers will be able to interact with the product they are interested in,
by modifying product parts parameter's, such as colour, size, shape, texture, etc., in the limits of the
interdependencies rules which will be preliminary fixed by the company and stored in the second database. To offer customers such services, the user interaction module will be based on latest VRML
and Java3D developments. Thus, a multimedia presentation of the product could be these delivered
by VRML or Java3D objects, so that the configuration of the viewed product on the user interface
could be reduced to interaction on the associated physicals VRML or Java3D object parameters. Such
interactions will be defined by the rules of interdependencies: Product parts are associated with a set
of physical parameters which are associated with a set of values defined by the company that sells the
product.
INT-D18FINAL
Page 7 of 58
INTELLECT
IST-1999-10375
The advancements to be achieved in the proposed project are composed of task for the electronic
shop system vendor, the shop owner/operator, and third the shop user.
The vendor will be able to sell a product that is featured with features for graphical representation not
available in today's shops and enhancement of the good's palette to succeed in higher market penetration. In addition clearing mechanisms in the scope of business to business, business to customer
and to banking institutions will be simplified by the use of a standardised protocol for financial transactions. The shop owner will also be able to update the product portfolio by simply adding new components to the database. The customers will then be able to define new variants of the product without
any changes to catalogues etc.
The shop owner/operator can increase buyers' rush by simple usage and better (more realistic) presentation. The configuration module of the proposed system allows the operator to handle the complete
product's multimedia information. For that purpose he has tools at his' disposal for using existing and
creating new graphical representations including logical interdependencies of all product's variants.
For the installation and management of the shop system the operator will have support by a holistic
tool kit to include product relevant information usually not stored in the order processing system of the
company.
With the proposed solution the shop owner will achieve a closer customer relationship by hotline via
advanced communication methods like Internet telephony, online chat system or video conferencing
tools up to better after-sales services. In addition parallel preparation of other product catalogues (CDROM, printed) based on the existing database managed information is available. Again, the system
will support all usual paying methods by implementing an open and standardised protocol for secured
financial transactions.
The prospective buyer is usually technical inexperienced. For this reason the proposed advanced
electronic shop will simplify the selection process of even complex products or product structures reflecting the 'real world'. The system will adapt the handling procedures of the shop to the needs of an
average customer by the use of simple and effective multimedia techniques. In addition the paying
process will be completely transparent to the user without any dependence on specific means of payment.
Summarised the following advancements will be achieved:
•
For the shop system vendor:
•
Higher chances of market penetration,
•
better standardised clearing mechanisms.
•
For the shop owner/operator:
•
Increased buyers' rush by simple usage and better (more realistic) presentation,
•
easy to handle configuration module for the complete product's multimedia information; tools for using
existing and creating new graphical representations including logical interdependencies of all product's variants,
•
installation and management of the shop with support by a holistic tool kit including product relevant information usually not stored in the order processing system of the company,
•
closer customer relationship by hotline via advanced communication methods like Internet telephony, online
chat system or video conferencing tools up to better after-sales services,
•
parallel preparation of other product catalogues (CD-ROM, printed) based on the existing database managed
information,
•
support of all usual paying methods by using e.g. OTP.
•
For the user:
•
User friendliness: simplified selection even by complex products or product structures, by better understanding of the handling procedures of the shop system for average customers, technical inexperienced people,
•
suitable and realistic display of the goods prevents a prospective buyer from ordering the wrong things and
guides him to the desired product; the return of purchase will be minimised,
•
paying process completely transparent to the user.
INT-D18FINAL
Page 8 of 58
INTELLECT
IST-1999-10375
2 INTELLECT Network Concept
The INTELLECT product is based on a three tier (layer) design. The next figure provides an overview
of the software products and tools, which were necessary for the development of the prototype of INTELLECT. On the one hand, the prototype uses open source products as it's underlying backbone. On
the other hand, third party products are used for direct real-time communication via NetMeeting or
security connectivity via SSL. In addition, commercial products regarding databases are used. Therefore the architecture can be devided into three tiers on the server site:
1. JBoss (Tier 1): The JBoss/server is an open source, standards-compliant, Enterprise Java
Beans (EJB) application server implemented in 100% pure Java code. The JBoss community
of over 500 developers world-wide is working to deliver the full range of J2EEtools as the
premier enterprise Java application server for the Java 2 enterprise edition platform. The
JBoss/server and complement of products are delivered under a public license. With 1500
downloads per day on average, JBoss/server is the fastest growing J2EE based server worldwide.
2. Tomcat (Tier 2): Tomcat is the reference implementation for the Java Servlet 2.2 and Java
Server Pages (JSP) 1.1 technologies. It includes the web server technology and offer this
functionality base for the prototype.
3. Cocoon (Tier 2): Cocoon is a 100% pure Java publishing framework that relies on new W3C
technologies (such as DOM, XML, and XSL) to provide web content. The Cocoon project aims
to change the way web information is created, rendered and served. The new Cocoon paradigm is based on the fact that document content, style and logic are often created by different
individuals or working groups. Cocoon aims for a complete separation of the three layers, allowing the three layers to be independently designed, created and managed, reducing management overhead, increasing work reuse and reducing time to market.
4. Oracle (Tier 3): The database Oracle8i standard edition enables business to cost-effectively
develop and deploy Internet-based solutions. Oracle8i includes native support for technologies
like SQL, XML, and Java that have become the standards on which today's e-businesses are
built.
For the independence of the end-user presentation and functionality, the project decided to use Java
Server Pages (JSP) technology which allows web developers and designers to rAPIdly develop and
easily maintain, information-rich, dynamic web pages that leverage existing business systems.
As part of the Java family, JSP technology enables rAPId development of web-based applications that
are platform independent. JSP technology separates the user interface from content generation enabling designers to change the overall page layout without altering the underlying dynamic content.
JSP technology uses XML-like tags and scriptlets written in the Java programming language to encapsulate the logic that generates the content for the page. Additionally, the application logic can reside in server-based resources (such as Java Beans component architecture) that the page accesses
with these tags and scriptlets. Any and all formatting (HTML or XML) tags are passed directly back to
the response page. By separating the page logic from its design and display and supporting a reusable component-based design, JSP technology makes it faster and easier than ever to build webbased applications.
INT-D18FINAL
Page 9 of 58
INTELLECT
IST-1999-10375
Servlet engine
Client’s
browser
EJB engine
database
Xsp
Cocoon
Admini
strative
tools
EJBs
Servlets & JSP
Tomcat
JBoss
Oracle
Application server
Server side
network
Figure 1 – System architecture of INTELLECT
JSP technology is an extension of the Java Servlet technology. Servlets are platform-independent,
100% pure Java server-side modules that fit seamlessly into a web server framework and can be used
to extend the capabilities of a web server with minimal overhead, maintenance, and support. Unlike
other scripting languages, servlets involve no platform-specific consideration or modifications; they are
Java application components that are downloaded, on demand, to the part of the system that needs
them. Together, JSP technology and servlets provide an attractive alternative to other types of dynamic web scripting/programming that offers platform independence, enhanced performance, separation of logic from display, ease of administration, extensibility into the enterprise and most importantly,
ease of use.
Java Beans component architecture is the platform-neutral architecture for the Java application environment. It can develop or assemble network-aware solutions for heterogeneous hardware and operating system environments, within the enterprise or across the Internet. Java Beans component architecture extends "Write Once, Run Anywhere" capability to reusable component development. In fact,
the Java Beans architecture takes interoperability a major step forward - every code runs on every
operating system and also within any application environment. A beans developer secures a future in
the emerging network software market without losing customers that use proprietary platforms, because Java Beans components interoperate with ActiveX. Java Beans architecture connects via
bridges into other component models such as ActiveX. Software components that use Java Beans
APIs are thus portable to containers including Internet Explorer, Visual Basic, Microsoft Word, Lotus
Notes, and others. The JavaBeans specification, which was completed ahead of schedule, defines a
set of standard component software APIs for the Java platform. The specification was developed by
Sun with a number of leading industry partners and was then refined based on broad general input
from developers, customers, and end-users during a public review period.
The Java Servlet technology provides web developers with a simple, consistent mechanism for extending the functionality of a web server and for accessing existing business systems. A servlet can
almost be thought of as an applet that runs on the server side - without a face. Java servlets have
made many web applications possible. Servlets are the Java platform technology of choice for extending and enhancing web servers. They provide a component-based, platform-independent method for
INT-D18FINAL
Page 10 of 58
INTELLECT
IST-1999-10375
building web-based applications, without the performance limitations of CGI programs. And unlike
proprietary server extension mechanisms (such as the Netscape Server API or Apache modules),
servlets are server- and platform-independent. This leaves you free to select a "best of breed" strategy
for servers, platforms, and tools.
Servlets have access to the entire family of Java APIs, including the JDBC API to access enterprise
databases. Servlets can also access a library of HTTP-specific calls and receive all the benefits of the
mature Java language, including portability, performance, reusability, and crash protection. Today,
servlets are a popular choice for building interactive web applications. Third-party servlet containers
are available for Apache Web Server, iPlanet Web Server, Microsoft IIS, and others. Servlet containers can also be integrated with web-enabled application servers, such as BEA WebLogic Application
Server, IBM WebSphere, iPlanet Application Server, and others. JSP technology is an extension of
the servlet technology created to support authoring of HTML and XML pages. It makes it easier to
combine fixed or static template data with dynamic content.
INTELLECT aims to provide an enhanced solution including all practicable electronic commerce features, and offering a qualitative representation of the product. The INTELLECT system is composed of
five modules:
•
The e-shop as the e-shop as the main interface visible to the customer supplies the general
infrastructure of an e-commerce system (basket, catalogue, secure communications, localisation, multimedia presentations, etc.).
•
The Virtual Reality module provides a 3D visualisation of the product, and enables the customer to configure its own product by choosing each of its components.
•
The Configurator supports the generation of product variants as well as implements a front
end to the database thereby offering infrastructure for the administration of products and components.
•
The help-desk provides on-line help to the customer using features like page mirroring, voice
over IP, and video conferencing.
•
The order-processing module as a front end to the back-office system manages the orders,
and offers an interface between the INTELLECT application, and the back office systems.
Client
Client
Distributor
Internet
Support
Backoffice
Helpdesk
Helpdesk
INTELLECT
Configurator
VR
VR
Producer
Client
DB
E-Shop
DB
Ordering
Client
Supplier
DB
Client
Figure 2 - INTELLECT Module architecture
The core modules use a common product database for all product and customer data. The database
contains all product and order related information partitioned into separate areas one for each module.
It is populated and updated by using information already available in the supplier systems. This information is updated on-line using standards for the exchange of product data (XML, SOAP). In addition,
a database of multimedia data (volumes models, sounds, videos, textures, etc.) exists on the HTTP
INT-D18FINAL
Page 11 of 58
INTELLECT
IST-1999-10375
Server serving the shop pages and is used for product demonstrations within the product catalogue of
the eShop.
Furthermore the Helpdesk and VR modules offer extended functionality that is implemented with software running on the customers computer. This software consists mainly of the browser and a Java
Virtual Machine (JVM). In order to make use of the Videoconferencing and CM/CW features of Intellect a H.323 compatible client (i.e. Microsoft Netmeeting) is required. The VR modules being the main
front-end to the Configurator offers:
1. Full VR navigation functionality based on VRML scene description data and Java3D 3D graphics
technology
2. Individual configuration of the viewed objects
3. Textual and audio visual explanations
4. The possibility of defining preferences that influence configuration
If the customer requires further assistance or simply wishes to speak to a salesperson a video or audio conference session with the company's hot line or call centre can be initiated via the Help-desk
module. The Help-Desk provides a direct link between the browser of the customer and the browser of
the salesperson thereby making it possible for the salesperson to view the same configuration the
customer is working on. The Salesperson also has the possibility to take part in the configuration
process and actively change the product variant in order to help the customer.
The electronic shop module finally takes the order of the customer over a secure connection via the
Internet. At this time, a human employee could carry out a spot check of the order to confirm the correctness of the order. An acknowledgement with complete details of the order is then returned automatically to the customer.
Customer
BROWSER
Web page
Cocoon
Servlets/
JSP‘s
EJB‘s
3D Applet
HD Applet
DB
Netmeeting
H.323
Helpdesk
BROWSER
Web page
3D Applet
HD Applet
Netmeeting
H.323
Figure 3 - INTELLECT Module Architecture
All INTELLECT Server modules are implemented as Java Enterprise Java Beans (EJB) that are installed on one or more EJB compliant application servers. It is important to note, that the various
beans can function separately from one another. This allows for a distributed setup with some beans
being installed on the server of an ISP and some being only partially online on the producers or distributors site. A further possibility is the use of more than one bean of a certain type (i.e. ordering) in
order to facilitate the integration of distributed back-office infrastructures.
All communication between the beans and the customers browser is filtered through appropriate Java
Servlets that serialize Java objects and tunnel them through a standard communications port (TCP
Port 80) used for HTTP transactions. This allows the use of INTELLECT through any standard type of
firewall or packet-filter employed by the customer.
INT-D18FINAL
Page 12 of 58
INTELLECT
IST-1999-10375
3 Experiencing the Pilots
This chapter presents the findings of the evaluation activities conducted in preparation, during and
after the INTELLECT pilots according to standardised usability testing criteria. The first section “effectives” directly addresses “The accuracy and completeness with which specified users can achieve
specified goals in particular environments.“ [2] For this we present the functionality offered by INTELLECT in relation to the tasks set for each pilot followed by concrete technical data on benchmarks
demonstrating the efficiency of the INTELLECT solution. The second section “efficiency” addresses
“The resources expended in relation to the accuracy and completeness of goals achieved.” [2] For this
we match goals identified during the user requirements phase of the project against the functionality
listed in the previous section as it was tested in the pilots in order to demonstrate “the accuracy and
completeness of goals achieved”. The last section contains findings in the area of satisfaction and
describes experiences of the end-users during the INTELLECT pilot phase.
3.1 Effectiveness
This criterion represents the functionality offered by the INTELLECT pilot within the three pilot scenarios formulated after the requirements of the three end-users. The first criterion to be considered is the
amount and type of functions offered by the software followed by detailed performance data on all
relevant parts of the INTELLECT prototype. Benchmark results presented here are not related to a
specific pilot instead they apply to all scenarios.
The subject of this section is to summarise the prototype-related aspects of the pilot scenario. The
INTELLECT prototype aims to provide an enhanced solution including all practicable electronic commerce features, and offering a qualitative representation of the product based on available VRML material. The following paragraphs present a rough overview of the components comprising the INTELLECT prototype. We then proceed to present the architecture of the prototype scenario of the INTELLECT pilot network.
3.1.1 Prototype platform
The INTELLECT prototype is based around the INTELLECT Application Server the software responsible for hosting the shops for the three INTELLECT pilots (see Figure 4). This server consists of a
group of Open Source Java based products that manage all INTELLECT Enterprise Java Beans and
Servlets as well as handle the XML files of the various Shops, generate HTML pages and serve them
to the client. The exact components of the Application Server and their specific function are described
in the following paragraphs. The INTELLECT Application Server used during the Pilots was installed
on a machine with permanent Internet access at BIBA. This gave the developers and the end-users
the possibility of updating and working with the system on a 24/7 basis. All three INTELLECT pilots
were installed on the same prototype server and were realised using the same database and application Server.
Producer
Internet
Helpdesk
Helpdesk
Client
INTELLECT
Application
Server
VR
VR
Client
Client
DB
Figure 4 – INTELLECT Pilot Topology
INT-D18FINAL
Page 13 of 58
INTELLECT
IST-1999-10375
The actual components of the prototype were the following:
•
Debian GNU/Linux Version 2.2 (potato)
The operating system employed as the main development and testing platform was Debian
GNU/Linux. The System was chosen for its performance and flexibility as well as popularity in
ASP/ISP circles targeted by the INTELLECT exploitation strategy. Regular tests on Microsoft
Windows NT4 and Windows 2000 have revealed no interoperability issues.
•
Oracle Enterprise Edition Version 8.1.7.
Oracle Enterprise Edition for Linux (http://www.oracle.com) is a best of class RDBMS providing efficient, reliable, secure data management for high-end applications such as high volume
on-line transaction processing (OLTP) environments, query-intensive data warehouses, and
demanding Internet applications. It should be emphasized, that INTELLECT uses none of the
proprietary Oracle extensions and can be ported to a different relational database (i.e. PostgreSQL) with a minimum of effort.
DB2
DB
Oracle
DB
Postgres
DB
Database
EJB Application
Server
jBoss
IPlanet
Apache/Tomcat
Jetty
Internet
Web/Servlet/JSP
Server
WWW
Figure 5 – INTELLECT Application Server
•
Apache Software Foundation Jakarta Tomcat Version 3.2.1.
Tomcat (The Apache Jakarta Project http://jakarta.apache.org/) is a servlet container and
JavaServer Pages(tm) implementation. It may be used stand alone, or in conjunction with
several popular web servers (Apache HTTPd, Microsoft Internet Information Server, Microsoft
Personal Web Server, Netscape Enterprise Server, etc.)
•
Apache Software Foundation Cocoon Version 1.8.2
Cocoon (The Apache XML Project http://XML.apache.org/) is a 100% pure Java publishing
framework that relies on new W3C technologies (such as XML and XSL) to provide web content. Apache Cocoon is an XML publishing framework that raises the usage of XML and XSLT
technologies for server applications to a new level. Cocoon interacts with most data sources,
including: filesystems, RDBMS, LDAP, native XML databases, and network-based data
sources. It adapts content delivery to the capabilities of different devices like HTML, WML,
PDF, SVG, RTF just to name a few. Cocoon is integrated currently as a Servlet. Specific features of interest are:
INT-D18FINAL
o
Database connection pooling
o
Servlet 2.0 spec compatibility
o
Good performance for heavy load conditions
o
High speed for XSP pages which include complex nodes
o
IBM Jikes Java compiler support for faster XSP page compilation
Page 14 of 58
INTELLECT
•
IST-1999-10375
jBoss Version 2.0
JBoss (The jBoss Project http://www.jboss.org) is an Open Source, standards-compliant,
J2EE application server implemented in 100% Pure Java. jBoss 2.0 is licensed under the
LGPL license. In our case jBoss 2.0 is working as an EJB-server.
According to the INTELLECT requirements analysis the requirements for the client should as low as
possible. Any current browser supporting Java either natively or with the Sun Java pluggin can display
the INTELLECT Shop-pages and make use of all the 3D presentation and configuration functions. All
testing during development was conducted with Microsoft Internet Explorer 5.5 and Netscape 6.0.
Testing during the pilot phase was based mainly on Internet Explorer.
The facilities for running the prototype INTELLECT marketplace during the three INTELLECT pilots
were provided by BIBA. The task of BIBA under the guidance of Anecon (being responsible for the
demonstration platform) as marketplace operator was to document and to solve problems that may
arise if the server is 24 hours per day in operation and has to answer the concurrent requests of buyers and sellers accessing the server. The experiences gained by running the marketplace will be used
as input for further refinement and debugging of the overall system.
The users of the INTELLECT marketplace mainly comprise the end users of the INTELLECT consortium as well as users that accessed the INTELLECT prototype via the link provided by the INTELLECT
Internet Web-Site. All users interested in configuring and buying products through INTELLECT needed
to access the marketplace by using a common browser (e.g. MS Internet Explorer or Netscape Communicator) including the Java 3D Java extension Library. Customers were provided with appropriate
installation instructions through the INTELLECT Web-Site.
Companies aiming to products through INTELLECT have to make use of the administrative tools developed by the INTELECT developer partners in order to enter new product data into the INTELLECT
database. This process was heavily supported by the INTELLECT developers as it was seen as too
complex for end-users with scarce technical experience to handle.
The main task performed by the INTELLECT Marketplace is to transform the entered product information into a browsable product catalogue containing configurable products. Such products can be ordered thereby generating orders in a format compatible to the back-office and workflow system of the
end-user (producer/distributor) systems. Support is provided through am online help-desk system that
offers video-conferencing and CMCW functionality.
INT-D18FINAL
Page 15 of 58
INTELLECT
IST-1999-10375
3.1.2 Prototype architectural components
The INTELLECT prototype is composed of five modules:
•
The e-shop as the e-shop as the main interface visible to the customer supplies the general
infrastructure of an e-commerce system (basket, catalogue, secure communications, localisation, multimedia presentations, etc.).
•
The Virtual Reality module provides a 3D visualisation of the product, and enables the customer to configure its own product by choosing each of its components.
•
The Configurator supports the generation of product variants as well as implements a front
end to the database thereby offering infrastructure for the administration of products and components.
•
The help-desk provides on-line help to the customer using features like page mirroring, voice
over IP, and video conferencing.
•
The order-processing module as a front end to the back-office system manages the orders,
and offers an interface between the INTELLECT application, and the back office systems.
Client
Client
Distributor
Internet
Support
Helpdesk
Helpdesk
Backoffice
INTELLECT
Configurator
VR
VR
Producer
Client
DB
E-Shop
DB
Ordering
Client
Supplier
DB
Client
Figure 6 - INTELLECT Module architecture
The core modules use a common product database for all product and customer data. The database
contains all product and order related information partitioned into separate areas one for each module.
It is populated and updated by using information already available in the supplier systems. This information is updated on-line using standards for the exchange of product data (XML, SOAP). In addition,
a database of multimedia data (volumes models, sounds, videos, textures, etc.) exists on the HTTP
Server serving the shop pages and is used for product demonstrations within the product catalogue of
the eShop.
Furthermore the Helpdesk and VR modules offer extended functionality that is implemented with software running on the customers computer. This software consists mainly of the browser and a Java
Virtual Machine (JVM). In order to make use of the Videoconferencing and CM/CW features of INTELLECT a H.323 compatible client (i.e. Microsoft Netmeeting) is required. The VR modules being the
main front-end to the Configurator offers:
•
Full VR navigation functionality based on VRML scene description data and Java3D 3D graphics technology
•
Individual configuration of the viewed objects
•
Textual and audio visual explanations
•
The possibility of defining preferences that influence configuration
INT-D18FINAL
Page 16 of 58
INTELLECT
IST-1999-10375
If the customer requires further assistance or simply wishes to speak to a salesperson a video or audio conference session with the company's hot line or call centre can be initiated via the Help-desk
module. The Help-Desk provides a direct link between the browser of the customer and the browser of
the salesperson thereby making it possible for the salesperson to view the same configuration the
customer is working on. The salesperson also has the possibility to take part in the configuration process and actively change the product variant in order to help the customer.
The electronic shop module finally takes the order of the customer over a secure connection via the
Internet. At this time, a human employee could carry out a spot check of the order to confirm the correctness of the order. An acknowledgement with complete details of the order is then returned automatically to the customer.
Customer
BROWSER
Web page
Cocoon
Servlets/
JSP‘s
EJB‘s
3D Applet
HD Applet
DB
Netmeeting
H.323
Helpdesk
BROWSER
Web page
3D Applet
HD Applet
Netmeeting
H.323
Figure 7 - INTELLECT EJB/Servlet Architecture
All INTELLECT Server modules are implemented as Java Enterprise Java Beans (EJB) that are installed on one or more EJB compliant application servers. It is important to note, that the various
beans can function separately from one another. This allows for a distributed setup with some beans
being installed on the server of an ISP and some being only partially online on the producers or distributors site. A further possibility is the use of more than one bean of a certain type (i.e. ordering) in
order to facilitate the integration of distributed back-office infrastructures.
All communication between the beans and the customers browser is filtered through appropriate Java
Servlets that serialize Java objects and tunnel them through a standard communications port (TCP
Port 80) used for HTTP transactions. This allows the use of INTELLECT through any standard type of
firewall or packet-filter employed by the customer.
A more detailed view of the INTELLECT Modules is presented in “D13: Pilot Integration Documentation and Handbook”.
INT-D18FINAL
Page 17 of 58
INTELLECT
IST-1999-10375
3.2 Efficiency
The resources expended in relation to the accuracy and completeness of goals achieved.” - This criterion tries to define the necessary amount of resources for the fulfilment of the specified goals.
3.2.1 eShop performance
The INTELLECT eShop benchmarks focused in the measurement of the performance related to the
generation of dynamic web-pages based on an XML infrastructure this being the technically most challenging task as well as the most interesting feature in terms of innovation for the end-users. The two
Servers involved in this process are Cocoon and Tomcat.
The role of Tomcat is to initialise the Cocoon Servlet, and to receive the HTTP Request and pass it on
to the Cocoon Servlet. On reception of a HTTP Request, Tomcat calls the Cocoon Servlet.service(HttpRequest, HttpResponse) method. When the Cocoon Servlet gets a HTTP Request
from the servlet engine, it sets up an Environment (a HttpEnvironment in this case) and passes that to
Cocoon. The Environment consists of a Request, Response, and some servlet info (such as requested URI and the servlet's path). This Cocoon object lets the Environment decide which sitemap to
use, and passes the sitemap filename along with the Environment to a Manager. This one puts a
Handler to work: it checks whether there already exists a Handler with a compiled version of the sitemap. If not, it creates one.
In order to test this functionality meaningfully four scenarios were identified:
•
Serving pre-generated HTML pages
o
•
Serving HTML pages dynamically generated by Cocoon
o
•
XML pages without logic i.e. no XSP pages, this is a pure conversion of XML and XSL
to HTML
Compiling, executing and serving XSP pages
o
•
Plain HTML pages i.e. www.ist-intellect.com
Tomcat executes the Cocoon Servlet, Cocoon compiles the eShop servlet
Executing and serving pre-compiled XSP pages
o
Tomcat as a Servlet engine executing the Cocoon servlet
In a realistic scenario the application server will generally generate all required pages in a relatively
short time depending on the traffic the site is subjected to. Effectively all pages both HTML pages and
Servlets will be pre-generated resp. pre-compiled. Therefore it is safe to assume that compilation or
generation time will normally not influence the performance of the site. In the following paragraphs will
we nevertheless present data on both serving pre-generated material and on serving material that is
being generated on-line.
In order to evaluate the INTELLECT eShop prototype a traffic simulation tool called “Web Stress” was
used (http://www.paessler.com/WebStress/webstress.htm). This tool is an HTTP client that offers the
possibility of starting multiple requests at the same time in order to simulate a situation of heavy traffic.
The tool also allows for extensive configuration of the behaviour of the simulated client and compile
and generate statistics describing the response of the server. Each test is configured to run for one
minute generating requests through 5 parallel clients.
All benchmarks were carried out on the INTELLECT on-line prototype server. This machine is a dual
Pentium II, 400MHz with 256 MB RAM and SCSI disk subsystem. The operating system was Debian
GNU/Linux 2.2 (potato) with Linux Kernel 2.2.18. All clients were connected via LAN to the server.
INT-D18FINAL
Page 18 of 58
INTELLECT
IST-1999-10375
3.2.1.1 Serving pre-generated HTML pages
In this benchmark the client is accessing plain HTML files and Tomcat is working as a plain Webserver not doing any processing of the files served. Each test is configured to run for one minute generating requests through 5 parallel clients. The request times ranging from 100ms to 250ms with an
average request time of roughly 150ms are somewhat high for a plain HTTP-Server, but nevertheless
acceptable. Tomcat answered successfully all requests with no errors. The occasional spikes in the
performance of the server can only be explained by internal Java Virtual Machine (JVM) fluctuations
that are not visible to the Java programme or the operating system.
Figure 8 –Request times for a single plain HTML URL
Figure 9 –User wait time and users per second
Figure 9 is a different view on the same test and demonstrates the effectiveness of Tomcat in terms of
the total number of users that can be served at the same time before the server starts losing requests
(ranging from 500 to 800 users per second).
3.2.1.2 Serving HTML pages dynamically generated by Cocoon
In this scenario XML pages without logic i.e. no XSP pages are served to the client. This is a pure
conversion of XML and XSL to HTML in order to provide the browser with a medium that it can understand. The same way a different format i.e. PDF could be produced for a different application, context
or output device or client.
INT-D18FINAL
Page 19 of 58
INTELLECT
IST-1999-10375
This functionality is present but has not been used in a realistic scenario as all INTELLECT pilot pages
contain dynamic data and have to therefore be generated dynamically (see 3.2.1.4 Executing and
serving pre-compiled XSP pages).
3.2.1.3 Compiling, executing and serving XSP pages
When accessing the XML–pages via Cocoon the servlet executed by Tomcat has to be compiled first.
This servlet is generated from the XML- and XSL- pages in the first 9 seconds of the test and is then
used without modification thereby accelerating the process to roughly 1 to 2 seconds per request. The
compilation of the Servlet only happens once after the startup of the application server or modification
of the page.
Figure 10 – Request time including compilation for a single client
Figure 11 – Request time including compilation for multiple clients
3.2.1.4 Executing and serving pre-compiled XSP pages
In this scenario the page is generated by the shop servlet with is pre-generated by Cocoon and simply
executed by Tomcat. This benchmark represents a “normal” usage scenario, were access to the INTELLECT pages is frequent and thus does not require permanent compilation of the Servlet.
INT-D18FINAL
Page 20 of 58
INTELLECT
IST-1999-10375
Figure 12 – Request times without compilation
Figure 13 - Average user wait time without compilation
3.2.1.5 Comparison between URLs from the three INTELLECT pilots
In the following scenario “Web Stress” targeted three different URLs for each of the 5 simulated users
one for each of the three different INTELLECT shop-pilots. The red line shows the request time for a
page without any graphics. The green line represents a page from the Blauwerk pilot containing a lot
of graphics. This page has to be compiled first and creates therefore the typical initial overhead.
INT-D18FINAL
Page 21 of 58
INTELLECT
IST-1999-10375
Figure 14 –Request time for multiple URLs
Figure 15 –Request duration without compilation
Figure 16 clearly demonstrates that the stress test caused the server to operate at maximum capacity
for a large part of the benchmark duration. This indicates that performance issues related to the
eShop servlets are at least to some degree related to performance issues with the server hardware.
INT-D18FINAL
Page 22 of 58
INTELLECT
IST-1999-10375
Figure 16 – Response time and CPU usage table
3.2.1.6 Comparison of different servlet engines
Previous benchmarks have shown that servlets generated and compiled an average request time of
about 1000 – 1200ms require. Such high response times are caused by the Servlet engine in Tomcat.
Tomcat while being an internationally acclaimed Servlet/JSP Server and the J2EE platform Reference
Implementation for Servlet/JSP technology is also known for its relatively bad performance. Jakarta
Tomcat Version 3.2 is a software mainly aimed at developers seeking a 100% standards compliant
implementation that offer many development related features and is not meant to be used as a deployment platform for commercial rollout. Jakarta Tomcat 4 is meant to address this problem and is
expected to offer much higher performance. Nevertheless the extremely short-term availability of the
new Tomcat version did not allow for further benchmarks with the new application server.
The following benchmark presents the performance of Tomcat 3.2 compared to that of two other popular products, Orion (http://www.orionserver.com/), Resin (http://www.caucho.com/).
Figure 17 – Performance comparison between Tomcat 3.2, Resin and Orion
INT-D18FINAL
Page 23 of 58
INTELLECT
IST-1999-10375
3.2.2 Configurator performance
The performance of the Configurator is heavily influenced by the underlying Product Data Model. This
insight had a major impact on the design of the Configurator as well as the underlying Product data
model for all the INTELLECT modules. The INTELLECT Product Data Model is designed to reduce
overhead caused by complex operations during product data processing [20]. Furthermore the INTELLECT product data model is constructed in a way that allows the mapping of configuration functions to
SQL sequences that can be executed by an RDBMS much faster and more efficiently than executing
the processing in the Configurator itself. This strategy further eliminates the need for extensive data
transfer between the database and the Configurator during configuration, thereby further reducing the
amount of resources (i.e. bandwidth) and reaction times required.
Following sections will focus on the main configuration function of the Configurator Bean, namely getPossibleComponents(). This function delivers all compatible components for a specific product while
at the same time taking into account all soft and hard criteria specified by the user. This function directly or indirectly uses all other Configurator functionality and is the one most frequently called by the
other modules. It is also the one with the highest resource consumption.
Moreover we will be presenting benchmarks for two implementations of the Configurator, one consisting of a pure Java algorithm that simply uses the database as a data-repository and one that maps
configuration requests to SQL as described in the previous passages. The direct comparison between
the results from both versions makes the advantage of “Lean Configuration” the Configuration concept
developed by the INTELLECT project evident.
All benchmarks were carried out on the INTELLECT on-line prototype server. This machine is a dual
Pentium II, 400MHz with 256 MB RAM and SCSI disk subsystem. The operating system was Debian
GNU/Linux 2.2 (potato) with Linux Kernel 2.2.18. All clients were connected via LAN to the server. The
product database contained the following data:
•
5 Products
•
5 Component lists
•
74 Components
•
44 Component types
•
67 Component categories
INT-D18FINAL
Page 24 of 58
INTELLECT
IST-1999-10375
3.2.2.1 Pure Java Implementation
The version of the Configurator tested here consists of a pure Java algorithm that simply uses the
database as a data-repository.
1st Scenario
In this benchmark five groups of clients with one up to five clients per group from five different client
machines are performing requests for getPossibleComponets in parallel for a product with a continuously increasing amount of components. The first call targets a product with one component, the second a product with two components, etc. The following graph demonstrates the average time required
for each client group to receive the configuration information for products with a specific amount of
components.
12000
10000
8000
1client
2 client s
6000
3 cleint s
4 client s
5 client s
4000
2000
0
1component 2 components 3 components 4 component s 5 component s 6 component s 7 components 8 components 9 component s
10
components
Figure 18 - Average request time for a specific amount of components (Java)
Figure 18 clearly demonstrates the following:
•
Response time is roughly 4 Seconds per request.
•
Response times are not dependent on the complexity of the product. Or in other words complex
products are handled just as well as simple products.
•
The overall performance of the system depends on the number of concurrent requests. The performance difference on the testbed hardware was roughly 1 sec per further client. This is to be attributed to the performance of the server as every concurrent connection requires a further Java
thread to be started. CPU usage on the server in all tests reached or exceeded 80-90% with three
or more concurrent connections.
INT-D18FINAL
Page 25 of 58
INTELLECT
IST-1999-10375
2nd Scenario
machines are performing requests for getPossibleComponets in parallel for a product with a single
component. The following graph demonstrates the average time required for each client group to receive the configuration information.
14000
12000
time (ms)
10000
8000
1 client
2 clients
3 clients
6000
4 clients
5 clients
4000
2000
0
1
2
3
4
5
6
7
8
9
10
Figure 19 - Average request time for a single component (Java)
•
Response times are not related to the state of the Java Virtual Machine (JVM) or the database.
The first and the last request have in general roughly the same response times. This precludes the
involvement of a cache/internal compilation or other event that impacts performance.
INT-D18FINAL
Page 26 of 58
INTELLECT
IST-1999-10375
3.2.2.2 SQL Implementation
This implementation of the Configurator maps configuration requests to SQL as described in the previous passages[20]. The direct comparison between the results from both implementations follows in
the next section and should make the advantage of “Lean Configuration” the Configuration concept
developed by the INTELLECT project evident.
1st Scenario
machines are performing requests for getPossibleComponets in parallel for a product with a continuously increasing amount of components. The first call targets a product with one component, the second a product with two components, etc. The following graph demonstrates the average time required
for each client group to receive the configuration information for products with a specific amount of
components.
1400
1200
time (ms)
1000
1 client
800
2 clients
3 clients
4 clients
600
clients
400
200
0
1
2
3
4
5
6
7
8
9
10
Figure 20 - Average request time for a specific amount of components (SQL)
Fehler! Verweisquelle konnte nicht gefunden werden. clearly demonstrates the following:
•
Response time is roughly 400ms per request, or in other words one 10 of the response times for
the pure Java implementation.
•
•
The overall performance of the system does not depend on the number of concurrent requests.
The performance difference on the testbed hardware was roughly 20ms per further client.
•
The decline in response time after the first queries indicates that the Database employs a cache
that improves performance as long as queries request the same information.
th
INT-D18FINAL
Page 27 of 58
INTELLECT
IST-1999-10375
2nd Scenario
machines are performing requests for getPossibleComponets in parallel for a product with a single
component. The following graph demonstrates the average time required for each client group to receive the configuration information.
1600
1400
1200
1000
time(ms)
1 client
2 clients
800
3 clients
4 clients
5 clients
600
400
200
0
1
2
3
4
5
6
7
8
9
10
Figure 21 - Average request time for a single component (SQL)
•
The first and the last iteration have roughly the same response time. This precludes the involvement of a cache/internal compilation or other internal optimisation that impacts performance.
•
Performance is heavily dependent on the performance of Oracle. Oracle reaches a CPU Workload
of over 50% with a single client connecting. The server being a dual process or machine can accommodate two Oracle processes under these circumstances. The second client can thus also be
accommodated with only a slight performance loss, but further clients then proceed to overburden
the server thereby considerably degrading performance.
INT-D18FINAL
Page 28 of 58
INTELLECT
IST-1999-10375
CPU Usage
machines are performing requests for getPossibleComponets in parallel for a product with a continuously increasing amount of components. The first call targets a product with one component, the second a product with two components, etc. The following graph demonstrates the average CPU load
caused by each client group for products with a specific amount of components.
100,00%
90,00%
80,00%
70,00%
CPU Usage%
60,00%
1 client
2 clients
50,00%
3 clients
4 clients
5 clients
40,00%
30,00%
20,00%
10,00%
57
55
53
51
49
47
45
43
41
39
37
35
33
31
29
27
25
23
21
19
17
15
13
9
11
7
5
3
1
0,00%
time (ms)
Figure 22 – Total CPU usage with up to five concurrent clients
100,00
90,00
80,00
CPU Usage %
70,00
60,00
Oracle
50,00
Java
40,00
30,00
20,00
10,00
0,00
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
time(ms)
Figure 23- Oracle/JVM CPU usage with up to five concurrent clients
INT-D18FINAL
Page 29 of 58
INTELLECT
IST-1999-10375
Fehler! Verweisquelle konnte nicht gefunden werden. and Fehler! Verweisquelle konnte nicht
gefunden werden. clearly demonstrate the following:
•
Performance is heavily dependent on the performance of the Server. The Server reaches a CPU
Workload of over 50% with a single client connecting. Further clients then proceed to overburden
the server thereby considerably degrading performance. The 100% mark is never achieved due to
the process management properties of the operating system.
•
Oracle requires the major part of available CPU resources thereby acting as the main bottleneck.
A setup where the Application server runs on a separate physical server than the RDBMS and
possibly addresses multiple RDBMS servers would definitely increase performance by dramatically.
3.2.2.3 SQL vs Java
This section contains a combined benchmark for both implementations of the Configurator. The direct
comparison between the results from both version makes the advantage of “Lean Configuration” the
Configuration concept developed by the INTELLECT project evident.
Overview
In this benchmark a single client performs requests for getPossibleComponets for a product with a
product with a continuously increasing amount of components. The first call targets a product with one
component, the second a product with two components, etc.. The following graph demonstrates the
average time required for each client to receive the configuration information for products with a specific amount of components.
6000
5000
time(ms)
4000
SQL
3000
Java
2000
1000
0
1
2
3
4
5
6
7
8
9
10
Figure 24 – Difference in response times between the SQL and pure Java implementations of the INTELLECT Configurator
•
Response time of the pure Java implementation is roughly 4 Seconds per request.
•
Response time of the SQL implementation is roughly 400ms per request, or in other words one
10th of the response times for the pure Java implementation.
INT-D18FINAL
Page 30 of 58
INTELLECT
IST-1999-10375
3.2.2.4 Conclusion
The direct comparison between the results from both Configurator versions makes the advantage of
“Lean Configuration” [20] the configuration concept developed by the INTELLECT project evident:
•
Response time is roughly 400ms per configuration request.
•
•
The overall performance of the system does not depend on the number of concurrent requests, as
long as the hardware can accommodate the number of clients. The performance difference on the
testbed hardware was roughly 20ms per further client.
•
The first and the last iteration have roughly the same response time. This precludes the involvement of a cache/internal compilation or other internal optimisation that impacts performance.
•
Performance is heavily dependent from the performance of Oracle. Oracle reaches a CPU Workload of over 80% with a single client connecting on the testbed server.
3.2.3 OrderProcessing performance
The work of the order processing starts, after the shop has accepted an order from a customer. Therefore the performance of the order processing module has no impact on the user expierience of the
customer, all the processes in this module occur offline.
We identified the following performance-critical areas within the Ordering-Module:
3.2.3.1 Database transactions
When the state of an order changes as a result of an incoming event, the order's state is reflected in 3
columns of the corresponding table: two of them are simple types (numeric and character data), the
XML-data of the order is saved in a CLOB ("character large object"). The duration of the update
statement is proportional to the length of the XML data. Benchmarks showed, that the part of these
database transactions are negligible in comparison to the transformations of XML documents. This is
further elaborated in the following paragraphs.
3.2.3.2 XML parsing
Parsing of the XML document is done with the Xerces reference implementation of the Apache Software Foundation. This implementation is free, but is known to be rather slow. There are commercial
implementations that are about five times faster than Xerces. Performance with the test XML was
about 5 to 7 milliseconds per parse.
3.2.3.3 XSL transformations
Generation of outgoing documents is accomplished via XSLT operations. For this, the XML document
has to be parsed into a tree representation by an XML DOM parser and after that transformed by an
XSLT engine. Both processes are rather time-consuming.
XSL-Transformation with a simple XSL stylesheet needed about 13 to 17ms.
3.2.3.4 XPATH addressing
XPath expressions are used within the workflow to get the information for the routing of orders. Xpath
evaluations are expensive, when the XML document is not already parsed; as the module needs the
parsed XML-document anyway the XPath addressing is also negligible.
3.2.3.5 XML transformations
Some backoffice functionality consists of XML-transformations; e.g. for the HiTEC pilot insertion of
parts list data was implemented, which resides in the database, into the order data. The time needed
INT-D18FINAL
Page 31 of 58
INTELLECT
IST-1999-10375
for these modifications of the DOM representation also had a negligible impact on the overall performance. We tested this with the HiTEC functionality of adding parts list information into the XML document from the database, this function required 600 to 830ms to perform on the test XML file.
3.2.3.6 Backoffice functionality
The integration of existing back-office systems is also part of the scope of the INTELLECT order processing module. As none of the end-users had no back-office system with necessary interfaces for
integration (they were all using proprietary products, that had no open interfaces) we tested this with
Anecon's self-developed "Admin Tool", which processes incoming and outgoing invoices.
These tests showed that the amount of time for communicating and processing the request in the
back-office system took much longer than any of the aforementioned points and was in the range of 5
to 9 seconds, depending on the desired back-office functionality.
For the pilots of our three end users sending of an email was the preferred back-office functionality,
because they implemented their workflow via sending "intelligent emails", which can trigger other
tasks. And even sending a short email via Anecon's SMTP server took 3 to 5 seconds.
3.2.3.7 Results
Our benchmarks showed, that the performance critical parts of the Order Processing module are not
located within the module, but by the external processes i.e. the external back-office systems that are
integrated by the module.
So the numbers for transaction throughput will depend mainly on the performance of the integrated
backoffice system. Business rules that are executed in the module (i.e. XML transformations like HiTEC’s parts list integration) can also influence the throughput if the logic is very complex. Compared to
the performance results of the eShop module and the configurator module, which expierience a much
higher load, because the number of shop and configurator transactions are between one and two
magnitudes over the number of completed purchases.
All performance tests were performed on the following system configuration:
•
Win2k Server, 256 MB RAM, 20 GB Harddisk, Intel Processor Pentium 3 800MHz
•
Java SDK 1.3.1
•
JBoss/Tomcat application server bundle, jBoss version 2.2, Tomcat 3.2
•
Xerces XML parser, version 1.4.3
•
Xalan XSLT processor version 2.1.0
•
XML test document : size is 25kB (this corresponds to a basket with 20 different items)
3.2.4 Helpdesk performance
Because of the unexpected long time the jBoss group needed to integrate the next version of the servlet container we had no time for performance benchmarks until now (see Fehler! Verweisquelle
konnte nicht gefunden werden.).
3.2.5 VR Applet performance
The Virtual Reality module as a front-end for the configuration module shows a view of the product,
which must be as realistic as possible. The user can interact with the product: turn, zoom, select and
configure a component; the possible configurations are given by the configuration module. Excepted
few cases where some simple configurations (colour, size) are directly available from the e-shop, the
customer must go in the Virtual Reality module to configure its product. The 3D view of the products is
obtained by assembling 3D models of its components stored in VRML files provided by the shop operator. If no 3D model is available for some of the components, configuration via the VR Applet is not
possible.
The use of Java3D, which is an API for Java, permits to render a 3D world in a Java application or a
Java applet. Java3D provides a collection of high-level constructs for creating, manipulating and renINT-D18FINAL
Page 32 of 58
INTELLECT
IST-1999-10375
dering 3D geometric objects in a virtual universe. The Java3D world corresponds to a scene graph,
which is an arrangement of 3D objects in a tree structure, that completely specifies the contents of the
virtual universe, and the way it is rendered.
VRML files can be loaded and added to a Java3D universe thanks to the VRML97 library, defined by
the VRML-Java3D working group.
The performance of the 3D Applet is therefore completely dependent on the performance of the
Java3D implementation, the 3D graphics language used (i.e. OpenGL, DirectX), the 3D driver for the
graphics hardware of the client and last but not least the graphics hardware itself.
In cases were the hardware offers appropriate 3D functionality (all current chipsets) which is supported by the graphics driver and the graphics language libraries installed on the operating system
(default in all modern platforms) the 3D Applet offers fluid navigation through the VR-World.
INT-D18FINAL
Page 33 of 58
INTELLECT
IST-1999-10375
4 INTELLECT Lean Configuration: Interactive Product
Configuration for the Internet
Current eCommerce solutions are based on conventional sales strategies and business models that
have simply been transferred to the Internet with the help of modern technology. Solutions based on
simple methods like catalogues demonstrating the palette of available products offer in spite of the
generous amount of multimedia present all over today’s Web no real added value compared to offline
stores other than 24/7 availability. On the contrary eCommerce customers often complain about the
lack of interaction with the product and the sales personnel. Most of the popular eCommerce businesses operating today offer standardised products like books, CDs, etc. that consist of one unit that
comes pre-packaged and their instances are normally identical.
The representation and sales of composite products that come in many variations poses additional
difficulties. The complex nature of products changing dynamically to fit the needs of the individual customer can only be managed through the deployment
of configuration systems similar to the ones currently
Requirements
used in standard ERP (Enterprise Resource Planning), PDM (Product Data Modelling) or DPM (Decentralised Production Management) systems. Such
systems can be used to exchange components in a
specific products to match the needs of an individual
customer. However conventional product developOptimal
ment systems are not built to support Internet or
Variants
more specifically eCommerce applications. Usage in
this specific environment requires modifications of the
methods used for both user interaction and configuraSolution
tion. This paper will present a overview of the solutions developed by the INTELLECT project.Product
Possible
Variant Configuration
Possible
Variants
Products
Configuration is the process of composing complex
products out of components. A Configurator is an
expert-system that supports this process and thereby
uses predefined goals as well as expert knowledge.
Figure 25 – Variant Configuration Design goals can be i.e. constraints, functional requirements, predetermined components or various
quality criteria [1]. Such systems do not follow a single predefined method, but rather a strategy based on a series of small steps. Each step representing
a certain aspect or assumption leading to the configuration of the product. Configuration is therefore
considered as the solution to a single exercise and not the solution to a whole problem or problem
class that has to be first methodically analysed [3]. This implies the following:
•
The set of all possible solutions is finite.
•
The solution sought after is not innovative, but rather a subset of the available parts.
•
The configuration problem is known and well defined.
Configuration functionality is usually integrated in large software packages meant to support the production process. Such software known as ERP (Enterprise Resource Planning), PDM (Product Data
Modeling) or DPM (Decentralized Production Management) normally contain extensive knowledge
based Configurator that are integrated in the design and production process. Configuration systems in
this area are traditionally rules based, modern systems however increasingly rely on the object oriented approach. Popular eShops or other similar Internet related technologies do not yet possess any
comparable functionality.
INT-D18FINAL
Page 34 of 58
INTELLECT
IST-1999-10375
4.1 Configuration concepts
4.1.1 Rules-based configuration
Traditional configuration systems are based on knowledge bases consisting of a description of all the
available components (objects) and an accompanying set of rules that define how specific objects
should behave under defined conditions and thereby control the flow of configuration[12].
Consequently configuration rules are structured according to the “if-then” principle familiar from various programming languages. The “if” part of a rule contains the conditions under which the actions
defined in the “then” part rule should be applied [13]. A configuration problem described using rules
based concepts is composed of the following three elements [14]:
•
Facts describe conditions that are necessary for configurations.
•
Rules describe the relationships between facts and describe actions to be takes.
•
Enquiries describe the problem to be solved.
The aim is to acquire answers to the questions posed with the help of the rules defined based on the
known facts[14].
Rule-based systems are easy to implement due to the simplicity of the individual rules, but are hard to
maintain after reaching a certain complexity. Production rules based systems are maintained by highly
qualified knowledge engineers that must have considerable knowledge on the products in question
and on the configurations system and most importantly the defined rules. Furthermore rule-based
systems are always restricted to a single knowledge domain in order to prevent the exponential complexity necessary for multiple rules-sets for multiple domains.
4.1.2 Case-based configuration
Case-based configuration makes use of libraries containing similar problems and predefined solutions
in order to formulate new product variants thereby reducing the configuration problem to the following
steps:
•
The search for a similar case.
•
The transformation of the original case to fit the current requirements.
The second step is where case-based configuration differs from other case-based methods, i.e. casebased reasoning or diagnosis where no such transformation is needed [9]. Collected knowledge can
be used for further configuration under the following conditions:
•
Creation and maintenance of appropriately organised libraries containing problems, solutions as well as the used process.
•
Existence of algorithms and heuristics for the selection of appropriate cases from the library.
•
The integration of case-knowledge in the configuration process. This includes procedures
for checking case consistency and case transformation[15].
Configurations created on the basis of such a library can often be less efficient than others created
with more conventional means. This is mainly due two the following characteristics of case-based
methods:
•
Resulting configurations are not fully compliant to the current requirements, but rather
adapted products that were originally designed for different requirements.
•
Changes in the knowledge domain can not be integrated in the case library without changing all relevant cases resulting in configurations that are sometimes not up-to-date[15].
4.1.3 Object oriented configuration
Object oriented configuration is based on the concept of iterative composition of the final product from
a set of different components that have been previously organised according to a hierarchy known as
INT-D18FINAL
Page 35 of 58
INTELLECT
IST-1999-10375
the object hierarchy that contains all knowledge concerning the product in question. Properties that
dictate how components fit together are described with the help of constraints.
Figure 26 – Object structure of a product domain
The object hierarchy contains all relevant objects and the relationships between them in a “is-a” relationship that defines types of objects, object classes and subclasses and their properties. The configuration process creates objects based on this information according to the products being configured. In
a specific hierarchy (as depicted in Figure 26 – Object structure of a product domain) for the configuration of cars, classes for specific car types (i.e. coupe, minivan, etc.) are connected with “is-a” relationships to the main “car” class. This hierarchy also allows the breakdown of a product in components
with the help of further “has-parts” relationships. These “has-parts” relationships are the basis for the
decision-making process employed to create new configurations. An example for such a relationship
would be the chassis and the wheel. A chassis can be connected to up-to 4 wheels in a passenger
car, but the wheels is represented only one with an appropriate cardinality in the diagram.
Constraints are constructs connecting two unknown or variable components and their respective attributes of predefined values (i.e. from a specific knowledge domain). The constraint defines the values the variables are allowed to have, but also connects variables and more importantly defines the
relationship between the two values. In other words constraints contain general rules that can be applied to make sure that specific components are put together in a correct fashion without having to
specify any component related rules or calculations[16].
The constraint satisfaction problem is defined as follows:
1. A finite set of variables X = {x1,...,xn}
2. For each variable xi, exists a finite set Di of possible values (its Domain)
3. And a set of constraints witch restrict the possible values that these variables are allowed to
take at the same time[17].
The configuration process is composed of the following steps[12]:
1. Analysis of the product in order to define possible further steps
2. Specification of further configuration steps
3. Executions of specified steps
Such steps are[12]:
1. Disassembly of the product into its components. This is meant to reduce the complexity of the
problem and create a large number of smaller objectives in the manner of conventional topdown specification.
2. Assemble of components, integration, aggregation. This step creates a product out of its
components in bottom-up manner.
3. Creation of specialised objects. Object classes are specialised through the definition of subclasses.
4. Parametrise objects. Define attributes and parameters for the specified objects that can be
used for the application of constraints or other configuration mechanisms.
INT-D18FINAL
Page 36 of 58
INTELLECT
IST-1999-10375
Object oriented configuration systems are a modern approach to configuration. They allow for a flexible approach to domain independent configuration that can support complex product structures. Furthermore the object oriented approach allows for relatively simple maintenance of established product
databases. Its advantages are flexibility and clear hierarchical structures that make maintenance easier compared to the other methods presented in this paper. The disadvantage of this method is the
overhead imposed by the handling of the object hierarchies.
4.2 Requirements for on-line Configuration
The industry requirements on configuration as captured by the INTELLECT consortium [2] focus on
two major usage situation.
1. Assisting private customers when experimenting with new variants on their own in a user
friendly fashion
2. Allowing salespersons in a retail store to produce and ultimately order correct individual configurations according to the customers wishes.
Configuration functionality in these scenarios reduces the workload on the salespeople on one hand,
and involves the consumer personally giving him the feeling that he is ordering something individual
and special on the other. The use of such functionality in an e-commerce context and the resulting
requirements impose restrictions, but also offer new possibilities concerning the implementation of
existing configuration methods. A short overview of these requirements is presented here:
•
Interactivity: The customer must be able to interact with the e-commerce System.
The aim is to allow him to construct the product piece by piece according to his own
preferences and wishes thereby giving the customer the feeling that he is a part of the
construction process of an individual product.
•
Multimedia: The customer must be able to receive visual feedback of his configuration efforts.
Product independence: The Configurator must be in a position to handle arbitrary
products. Main issues here are the handling of the attributes (the quantity and type of
the components attributes should be handled dynamically) and the components of the
product (a product’s composition should not be restricted by any non configuration related issues).
•
•
Performance: The system must be able to handle large numbers of concurrent configuration requests. This implies a scalable and simplified architecture that can operate with a minimum of product data in order to ensure acceptable performance and
make efficient use of bandwidth.
•
Soft criteria: The use of a Configurator in an e-commerce environment imposes additional requirements on usability and user friendliness. Configuration should not restrict
itself on mechanical or “hard” criteria, but should also consider soft criteria expressed
by the customer. Relevant configuration criteria are “hard” factors like whether a component fits in an existing product as well as “soft” factors like personal preferences of
the user as well as other non operability related information (i.e. price, size, weight,
performance criteria, image, popularity, etc.).
Additionally, the products offered by the INTELLECT end-users have different characteristics thus
requiring different sales strategies. Most of the products are highly configurable, some of them even
require the consumer to possess special skills in order to integrate them in existing configurations.
This characteristic has a number of consequences depending on the development cycle for new products, the nature of the components or products and the marketing strategies of the specific firm. Nevertheless, all of the end-users could greatly profit in different ways from a configuration process simplified through intelligent software and visual representation of the data. Functionality of this nature will
enable less experienced consumers to produce their own configurations or individualised variations
based on existing models.
4.3 Lean Configuration
The greatest difficulty to be resolved when configuring new products is the fact that the software is
required to make decisions that are not based on available information. Such an action can lead to a
possibly dysfunctional product or simply a product that does not conform to user requirements. In this
INT-D18FINAL
Page 37 of 58
INTELLECT
IST-1999-10375
case all configuration steps have to be undone (so called backtracking) in order to return to a valid
state. The longer it takes for the Configurator to detect that a mistake has been made, the more difficult it is to correct the error in question.[1]
The configuration process as described by [12] is composed of the following steps:
1. Analysis of the product in order to define possible further steps
2. Specification of further configuration steps
3. Executions of specified steps
The INTELLECT approach to Configuration attempts to reduce the Configuration processes to a
search problem by eliminating the complex, computationally intensive and error prone first two steps
of variant configuration. In accordance with the first criterion identified during the analysis of the user
requirements related to an eCommerce environment the configuration process should be interactive in
order to maximise user friendliness. The customer does not need or wish to specify his wishes in the
form of a computer programme and wait for the Configurator to produce a variant. A system that requires programming beforehand (as in conventional configuration systems) in order to automatically
produce products variants would be far too uncomfortable and impractical for use in an e-shop. A simplification of the methods involved and involvement of the user in the configuration process is therefore a requirement also stemming from the interactive user-friendly nature of Internet applications. An
optimal solution should give the user the feeling that he is configuring the product on his own while at
the same time being fully supported by the Configurator.
The reduction in complexity is realised by the usage of correctly configured, complete products as the
basis for interactive configuration. As long as the user uses a pre-configured product as a template for
the new variant the configuration process is transformed into a search problem, and specifically the
search for the next component to be exchanged. The user chooses a product that fits his general requirements from the product catalogue of the shop and then proceeds to individualise it by exchanging
components. Further added value is realised by allowing the user to define various “soft” criteria before or during configuration that describe the desired product. This information can be used by the
Configurator to further reduce the list of possible components before presenting it to the user. The
Configurator supplies the user with lists of components that are a) compatible to the part being exchanged and b) are in accordance to the customers already defined “soft” criteria and can be safely
used in place of the component to be removed. This mechanism ensures that the product is constantly
in a functional state. The interactive nature of this approach further simplifies the task by allowing the
user to make the final choice out of the list of appropriate parts. Variants generated by the customers
can also be used as the basis for new “pre-configured products” by the shop owner. [6, 7]
Vector getPossibleComponents(long productId,long componentId,Vector categoryIds);
Figure 27 – Configuration functions
The INTELLECT Configurator supports the previously described configuration process with the getPossibleComponents function. This function is called with the identifier of the product being modified
(productId), the identifier of the component to be exchanged (componentId) and a dynamic array of
“soft” criteria specified by the user (categoryIds). The function returns a dynamic array of Components
that fit the list of requirements.
This search can be further simplified by the specification of database schemata that correspond
closely to the object hierarchy representing the product. This allows for the use of database queries for
most of the tasks related to providing lists of compatible components, so that configuration is largely
reduced to a series of complex database queries. This offers further added value in the sense that the
Configurator implicitly profits from the optimised performance of current database management systems, but also from the fact that configuration data is in a perpetually consistent state enforced by the
mechanisms of the database management system.
4.4 INTELLECT Product Data Model
Primary goal during the specification of the INTELLECT Product Data Model was flexibility in respect
to the different kinds of products that can be categorized and simplicity of design in order to minimize
the overhead imposed by the model itself. Product data can be entered into the INTELLECT database
INT-D18FINAL
Page 38 of 58
INTELLECT
IST-1999-10375
either manually through an application (see Figure 30) designed to be used by the knowledge engineer administering the knowledge base or in a bulk fashion i.e. from data exported from a back-office.
The structure consists of the following entities:
1. Pre-configured products
2. Products
3. Component types
4. Components
5. Component categories
Products represent a package sold to the customer. This can be either a single object or a combination of components comprising a specific variant. Products contain one or more list of components.
Lists are meant to support structuring of related components. An example of a product with more than
one component list is kitchen furniture. The equipment for a whole kitchen could be specified as one
product that is clearly structure in one or more related groups of components (i.e. a table and chairs,
various cupboards, etc.). A computer on the other hand will most likely contain only one component
list for all components. The configuration of the component lists and the categorization of the components is up to the administrator’s discretion.
Hard
Categories
Soft
Categories
Component
Types
Components
HardDisks
Mainboards
AVEquipment
High-End
Low-End
IBM
DCAS3440
Maxtor
4567
IBM
DORS3240
U2W, 8 GB,
5400rpm
U, 4 GB,
5400rpm
UW, 2 GB,
5400rpm
Figure 28 – Component types, Components and Categories
INT-D18FINAL
Page 39 of 58
INTELLECT
IST-1999-10375
<<Interface>>
IProduct
updateCurrentProductKey()
playMultimedia()
setPrice()
getPriceOfAllComponents()
getManufacturer()
showDetails()
PreconfiguredProduct
createNewProduct()
NewProduct
customiseProduct()
show3D()
getComponentList()
getPossibleComponents()
changeComponent()
ComponentCategoryConstraint
Product
ComponentCategory
price : Integer
availibility : Boolean
productKey : Integer
productName : String
taxrate : Double
1
CategorySpecificData
CategoryType : String
playMultimedia()
getPriceOfAllComponents()
showDetails()
setPrice()
updateCurrentProductKey()
getManufacturen()
ComponentConstraint
1..*
ComponentList
Item
ComponentType
id : Integer
multimediaUrl : String
configurationContrains
manufacturerName : String
manufacturerId : Integer
1..*
updateItem()
deleteItem()
getManufacturerName()
getManufacturerLogo()
showInfo()
createItem()
componentTypeName : String
emptyComponentAttributes : HashTable
IComponent
getComponentTypeName()
setComponentTypeName()
componentKey : Integer
componentName : String
filledcomponentAttributes : HashTable
componentPrice : Integer
availibility : Boolean
setAttributesType()
getAttributesType()
ComponentTypeattribute
name : String
valueType : String
setName()
setValueType()
getName()
getValueType()
FilledComponentAttribute
ComponentAttribute_Integer
ComponentAttribute_Float
ComponentAttribute_String
attributeValue : Integer
attributeValue : Float
attributeValue : String
setValue()
setValue()
setValue()
Figure 29 – INTELLECT Product Data Model Class-diagram
Products exist furthermore in one of two variations, pre-configured products and new products. Preconfigured products are the ones used to generate the product catalogue and are used as templates
for generating new variants. Every time a user decides to configure a product, a copy of the preconfigure version thereof is made. The new product is then modified to produce the desired variant.
The differentiation between the two kinds of products is required in order to prevent modification of the
original designs.
Component types represent a certain type of part, possibly a specific model (i.e. the IBM DCAS2340
hard-disk). A component type is used to define the attributes related to this object. A dynamic attribute
mechanism allows for arbitrary types and quantities of attributes. It is important to note that attributes
of component types have not values, they simply provide the infrastructure needed for the usage of
attributes in a specific product.
Components on the other hand represent concrete elementary parts sold either separately or as part
of a product. Such components are instances of a specific component type and contain concrete val-
INT-D18FINAL
Page 40 of 58
INTELLECT
IST-1999-10375
ues for the defined attributes. A component for a specific type of hard disk (specific component type)
i.e. would have concrete values for attributes like size, speed, form-factor etc.
Figure 30 – Tree view of a complete product
Component categories exist in two variants hardware categories and soft categories. Hard categories
represent a whole group of components that have the same basic function (i.e. all hard-disks), soft
categories define configuration preferences and general criteria. Both types are used to reduce the
number of components that are suitable. Soft categories are also used to define the “soft” criteria suitable for this product domain (see Figure 28). The knowledge engineer designing the knowledge base
for a new Configurator has to decide what groups of components are necessary in order to provide the
end-user with a sufficient set of options during configuration.
PCI Card,
Elsa Erazor
ConnectionInput=PCI
Equality
Constraint (=)
Mainboard,
Asus xyz
ConnectionOutput=PCI
Figure 31 - Constraints
Constraints between attributes of specific component types enforce “construction” rules (see
Figure 31). Constraints are operators that can be defined nearly arbitrarily and can be used to support
new configuration behaviour. The Attributes “ConnectionImput” and “ConnectionOutput” together with
the equality constraint i.e. are used to define which components fit together physically and what sort of
interfaces each component type requires or makes available.
Due to the modular and extensible design of the INTELLECT Configurator, it is relatively easy to add
new Constraint types (i.e. bigger than, smaller than) that make new kinds of configurations possible.
Products used for testing in the first version of the Configurator (scooters and computers) were fully
modelled using only the equality constraint and appropriate Component Categories.
4.5 Implementation
The INTELLECT Configurator was developed based on cross-platform pure Java2 and Java Enterprise Beans (EJB) Technology. The Configurator is implemented as an Enterprise Java Bean that runs
in an EJB container provided by an application server. The application server used for development
and testing was JBoss[18]. The eShop and Ordering modules make extensive use of Apache Software Foundation Java Packages providing XML-Handling Functionality. All data is stored in an Oracle
relational database. Great care was taken to avoid usage of any proprietary extensions in order to
INT-D18FINAL
Page 41 of 58
INTELLECT
IST-1999-10375
facilitate cross-platform compatibility and avoid vendor lockup. The system was developed on RedHat
and Mandrake GNU/Linux and deployed/tested on Debian GNU/Linux, further tests and demonstrations were successfully conducted on MicroSoft Windows NT 4 and Windows 2000 platforms. Testing
of the client was achieved on various consumer Windows versions. Browsers used on client systems
were Microsoft Internet Explorer 5.5 and Netscape 6. The VM and JDK used for development and
testing was Sun JDK 1.3. The Java3D extension was also installed on the client machines.
4.6 Conclusion
This paper has presented various possibilities for interactive configuration of complex products in an
eCommerce environment. It has been shown, that based on the proposed concept such functionality
is feasible in an efficient and user friendly manner thereby extending the functionality of conventional
eShops. Moreover it has been shown that a VR representation of the product itself as well as the configuration process as a whole is feasible. This sort of graphical representation can provide new means
of interaction with the product and allow for the user to enjoy a “hands on experience” with the modified product variant.
INT-D18FINAL
Page 42 of 58
INTELLECT
IST-1999-10375
5 Secure Communication in Electronic Shop Systems
The modern world of information and communication needs more and more the help of information
technology to manage the growing amount of electronic data. Numerous work processes, both in public and in industry, are electronically controlled. As a result, many organisations depend on perfectly
operating IT and communication systems. Information is digitally stored, electronically processed and
transferred through private and public networks, such as the Internet. The Internet is a low-price possibility to connect business partners, suppliers and customers world-wide. But availability of the connection is not enough, the user needs the certainty that his data transmission is secure. Especially for
pecuniary transactions which will take place more and more often via the Internet, IT security must
become an integral part and develop from security systems to secure systems. Therefore the awareness for security must grow. The following list of security aspects of information can help to identify the
threats for messages transferred via the Internet or stored on servers connected to the Internet:
1. Confidentiality: Protecting information from being read or copied by anyone who
has not been explicitly authorised by the owner of that information. This type of security includes not only the information in toto, but also the protection of individual
pieces of information that may seem harmless by themselves but that can be used
to infer other confidential information.
2. Data Integrity: Protecting information (including programs) from being deleted or
altered in any way without the permission of the owner of that information. Information to be protected also includes items such as accounting records, backup tapes
and documentation.
3. Availability: Protecting services so they are not degraded or made unavailable
(crashed) without authorisation. If the system is unavailable when an authorised
user needs it, the result can be as bad as having the information that resides on
the system deleted.
4. Authentication: Authentication is a very important point to realise authorisation.
Authentication is the process of proving that a subject (e.g. a user or a system) is
what the subject claims to be.
5. Access Control: Restrictions on the ability of a user to use a system or an object
in that system. Such control limits access to authorised users only.
6. Non Reputation: Non reputation prevents either sender or receiver from denying a
transmitted message. Thus, when a message is sent, the receiver can prove that
the message was in fact sent by the alleged sender. Similarly, when a message is
received the sender can prove that the message was in fact received by the alleged receiver.
Most of the measures to protect information are based on encryption methods.
5.1 Encryption
Encryption is the technology for encoding messages so that only the recipient can read the message.
The aim of encryption is to make an attack on information as difficult as possible. Encrypted information can only be decrypted, without the knowledge of the decryption key, with a certain expense of
technology. How secure encrypted information are depends on factors like the type of encryption
(asymmetric/symmetric), encryption algorithm and the key length but also the technical effort and time
a “cracker” is willing to spend.
5.1.1 Secret Key Encryption
Secret key encryption, also known as symmetric encryption, uses the same key for encryption and
decryption. Secret key encryption algorithms are DES (Data Encryption Standard), Tripple-DES, Blowfish, IDEA (International Data Encryption Algorithm), RC4 (Rivest Cipher Nr.4), etc.
Problems with the secret key crypto-system are:
INT-D18FINAL
Page 43 of 58
INTELLECT
IST-1999-10375
•
Key transmission (key exchange): It has to be ensured that the private key will be transferred to its destination in a secure way.
•
Limited number of user: Everyone who is in possession of the private key can decipher
the data. The less people are in possession of the key the more secret the data are. The
increasing number of user will also raise the transfer problem.
•
No signature possible: Because two people (at least) are using the same key it has to be
ensured that both people are using the key rightly.
The benefits of secret-key encryption technology is its fast encryption (compared to public-key encryption). Especially in open systems with a large number of users, secret-key crypto-systems has difficulty providing secure key management. Key management is known as the generation, transmission
and storage of keys. All keys in a secret-key crypto-system must remain secret. The main problem
which has to be solved is the key exchange. In order to solve the key management problem the public
key encryption can be used.
5.1.2 Public Key Encryption
To overcome the problem of key exchange, Whitfield Diffie and Martin Hellman created the concept of
public-key cryptography in 1976. The Diffie-Hellman algorithm can only be used for key exchange.
1997 Rivest, Shamir and Adleman invented a public key algorithm (RSA) for key exchange and data
encryption, today’s de facto standard among public key algorithms.
Public key encryption is a technique that uses a pair of asymmetric keys for encryption and decryption.
Each pair of keys consists of a public and a private key. The public key is made public by distributing it
widely, the private key is never distributed, it is always kept secret. Data that is encrypted with the
public key can be decrypted only with the private key. Conversely, data encrypted with the private key
can be decrypted with the public key. This asymmetry is the property that makes the public key encryption so useful.
Advantages
•
Provides data encryption and digital signature. (RSA)
•
Increased security: Private keys never need to be transmitted to anyone.
Disadvantages:
•
Slow: Caused by the complex mathematical concept the asymmetric encryption is slower than the
symmetric encryption.
•
Does the public key of a potential recipient belongs to this recipient? Need of a certificate
The secret-key encryption is fast but needs a secure way for transmitting the key. The public-key encryption is slow but offers a secure way for the key exchange. To overcome the limitations the secretkey and an public-key encryption will be combined.
There are two basic approaches:
1. At the beginning of the communication the secret key will be encrypted by the public key. Now, the
encrypted secret key can be transferred in a secure way. At the other side the secret key can be
decrypted by the public key. Finally, a secure data exchange can be realised by using the secret
key.
2. The secret key will be transferred with the data altogether. This is called a digital envelope. The
information which will be transferred are containing the encrypted secret key followed by the data,
encrypted with the secret key (digital envelope).
5.2 Authentication and Digital Signature
Authentication is the process of verifying identity so that one user can be sure that the other user is
who it claims to be. One way of authentication is the digital signature which uses the public key encryption technology.
A digital signature is a cryptographic means that a particular message did indeed originate from the
signer and was not alerted or exchanged during transmission.
INT-D18FINAL
Page 44 of 58
INTELLECT
IST-1999-10375
The digital signature is created through the use of a hash function to the message creating a message
digest. This digest, usually shorter than the message, will be encrypted with the sinners private key.
After receiving the message the same hash function has to be applied to this message, the received
encrypted digest has to be encrypted with the public key and the two digest have to be compared. If
the two are the same the signature was successfully authenticated.
5.2.1 Certificate and Certificate Authority (CA)
Using the public key encryption, a user does not know for sure that the public key of a potential recipient belongs to this recipient. A way to overcome this problem is to use a digital certificate for authentication:
•
Digital Certificate: A digital certificate attest that a public key belongs to a certain person
or organisation. The standard for digital certificates is defined by the ITU norm X.509 which
will be used by all browsers, Internet servers and security protocols (e.g. SSL).
•
Certification Authority: This certificate will be issued by a trusted organisation called Certification Authority (CA), also know as a Trust Centre. A certificate issued with the users
public key will be encrypted with the CAs private key. To verify that the public key belongs
to the sender the receiver decrypts the certificate with the CAs public key.
•
A certificate contains the following information:
•
Subject (who has to be certified): name and public key
•
Issuer (CA): name and signature (public key ?)
•
Period of validity: not before date, not after date
•
Administrative information: serial number and version
5.2.2 Secure Socket Layer (SSL)
Secure Sockets Layer (SSL) is a crypto protocol created by Netscape for managing the security of
message transmissions in a network. Netscape's idea is that the programming for keeping the messages confidential ought to be contained in a layer between an application (such as the Web browser
or HTTP) and the Internet's TCP layer.
SSL allows a SSL-enabled server to authenticate itself to an SSL-enabled client (e.g. sending a credit
card number over the network), allows the client to authenticate itself to the server (e.g. a bank is
sending confidential information to a customer) and allows both machines to establish an encrypted
connection.
SSL is an integral part of each Netscape and Microsoft browser. If a Web site is on SSL capable
server, SSL can be enabled and specific Web pages can be identified as requiring SSL access.
HTTP, FTP, SNMP
Handshake- Change-CipherSpecProtocol
Protocol
AlertProtocol
ApplicationDataProtocol
SSL-Record-Protocol
SSL-Record-Protocol
TCP, UDP
IP
Figure 32 – SSL Protocol Stack
INT-D18FINAL
Page 45 of 58
INTELLECT
IST-1999-10375
5.2.2.1 SSL Protocol Stack:
The cryptographic parameters of the session state are produced by the SSL Handshake Protocol,
which operates on top of the SSL Record Layer. When a SSL client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each
other, and use public-key encryption techniques to generate a session key.
After negotiating the security attributes of the session the Change-CipherSpec protocol informs the
Record layer about the cipher (cryptographic algorithm) settings. The whole SSL secured communication will be encapsulated by the Record Protocol which defines the format used to transmit data and
fragments, compresses and encrypts data (or attaches digest signatures) as specified by the current
active session state (see figure 3).
The Application Data Protocol transfers data from the application layer to the Record Protocol. If problems during the data exchange occurs the Alert Protocol is sending error and warning messages.
Figure 33 – SSL Record Protocol
Caused by this encapsulation, web server which are communicating with HTTP via SSL receive messages at a port different from the standard. HTTP communication without SSL will be received normally at port 80. The HTTP communication via SSL take place at port 443 (SMTP at Port 464, NNTP
at port 563). SSL supported a variety of cryptographic algorithms:
•
During the handshaking process, the RSA key exchange algorithm (certificates are used)
or the Deffie-Hellman key exchange algorithm (without certificate) is used.
•
After the key exchange, a number of ciphers are used including RC2, RC4, IDEA, DES or
Triple-DES.
•
The MD5 (128 bit) and SHA-1 (160 bit) message-digest algorithm is also used. The publickey certificates follow the X.509 syntax.
INT-D18FINAL
Page 46 of 58
INTELLECT
IST-1999-10375
5.2.3 HTTPS
A common use of SSL is to secure HTTP communication between a browser and a web server. Using
HTTP over SSL is named HTTPS and will be indicated with the URL scheme https and a different
server port (443).
5.3 Conclusion
For financial transaction via the Internet SSL (HTTPS) must be used. This technology is a standard
security protocol, already tested and commonly used in the Internet. SSL can be implemented in every
http-based application. With the encoding it is only important that one uses long key lengths. Thus
SSL should use RSA with a 1024-Bit-key for key exchange and Triple DES or IDEA with 128-Bit-key
at least!
INT-D18FINAL
Page 47 of 58
INTELLECT
IST-1999-10375
6 Help-desk System in E-Shop Systems
One important aim for the INTELLECT shop is to implement a help-desk system, for those customers
that have difficulties with the configuration of the product or with the shop itself. The customer will be
able to connect the help desk with a videoconferecing tool directly. Because voice-to-voice communication without visual assist has a lack on information for the help-desk agent, a page mirroring
mechanism will be integrated into the shop.
6.1 IP communication
The first method forces the users to essentially schedule calls with others, or to use directory servers
listing potential partner. On the other hand, PC to Phone voice over IP (VoIP) the Internet Telephony
call is carried over the Internet to a gateway. At the gateway, the call is converted between the Internet
and the standard PSTN network. Hardware solutions can enhance the quality of basic Internet telephony via DSP-based voice compression and echo cancellation (e.g. Quicknet Technologies Internet
PhoneJACK).
A video conferencing system consists of the following components: computer, web cam/full-duplex
soundcard, headset or speakers/microphone set, and codec for audio/video compression. The following subjects were extracted by examining the features of available products: Live-transmission of
video- and audio information, whiteboard, text chat, voice chat, file transfer, application sharing, and
Internet directory used to locale individuals.
Leading products are based on H.323. H.323 is an ITU standard (International Telecommunication
Union) that describes how a flexible, real-time, interactive set of multimedia communications can be
exchanged on packet-based networks like TCP/IP. There are standards for voice, fax and video; it is
also important for multimedia streaming. H.323 is a call-control protocol. The protocol stack is running
on both machines (end-entities) and it negotiates call set-up, teardown, voice codec used and the
relative priorities of voice and data traffic between nodes during the conversation. H.323 also defines
other entities for other communication infrastructures, but we will concentrate here on point-to-point
communications. H.323 can use G.729a codec or the G.723.1 codec (voice compression algorithms).
T.120 is another standard from ITU for data collaboration over the Internet. It handles Multipoint Data
Delivery, Interoperability, Reliable Data Delivery, Multicast Enabled Delivery, Network Transparency
and Scalability. It can be used for working collaboratively on a document (e.g. application sharing or
whiteboard).
The project also evaluated the desktop sharing features of NetMeeting, which allows a help-desk
agent to take over control over a browser window of the customer, if the customer has also installed
NetMeeting. But this approach had to many disadvantages: NetMeeting has to be installed and configured correctly (configuration is not easy for an non professional user).
The need of dynamic port handling from NetMeeting for doing video conferencing makes the use of a
firewall more insecure. To pass through H.323 control and H.323 streaming the ports between 1024
and 65535 have to be permitted, otherwise video and audio transmission would not be possible. With
this computer hackers is offered a wide range of possibilities to attack the net behind the firewall. Furthermore the tests showed that NetMeeting has problems with the Network Address Translation (NAT)
of Cisco’s routers. This case is well-known from Cisco, but not solved, yet.
Port
Function
Outbound Connection
1503
T.120
TCP
1720
H.323 call set-up
TCP
1731
Audio call control
TCP
Dynamic
H.323 call control
TCP
Dynamic
H.323 streaming
Real-Time Transfer Protocol (RTP) over UDP
Table 1 - Used ports by NetMeeting
INT-D18FINAL
Page 48 of 58
INTELLECT
IST-1999-10375
Despite of the restricted settings that would possibly improve communication (e.g. more accurate audio settings) NetMeeting is offering a sufficient quality of audio and video. Nevertheless with communication over low bandwidth networks like the Internet NetMeeting would fall behind in quality aspects
of video conferencing. The reason is that the Internet does not have any QoS features. [18]
6.2 Quality-of-Service
The default service offering associated with the Internet is characterised as a best-effort variable service response. Within this service profile the network makes no attempt to actively differentiate its
service response between the traffic streams generated by concurrent users of the network. As the
load generated by the active traffic flows within the network varies, the network's best-effort service
response will also vary. The objective of various Internet QoS efforts is to augment this base service
with a number of selectable service responses. These service responses may be distinguished from
the best-effort service by some form of superior service level, or they may be distinguished by providing a predictable service response which is unaffected by external conditions such as the number of
concurrent traffic flows, or their generated traffic load.
Any network service response is an outcome of the resources available to service a load, and the level
of the load itself. To offer such distinguished services there is not only a requirement to provide a differentiated service response within the network, there is also a requirement to control the servicequalified load admitted into the network, so that the resources allocated by the network to support a
particular service response are capable of providing that response for the imposed load. This combination of admission control agents and service management elements can be summarised as "rules
plus behaviours". To use the terminology of the Differentiated Service (DiffServ) architecture, this admission control function is undertaken by a traffic conditioner (an entity which performs traffic conditioning functions and which may contain meters, markers, droppers, and shapers), where the actions
of the conditioner are governed by explicit or implicit admission control agents.
As a general observation of QoS architectures, the service load control aspect of QoS is perhaps the
most troubling component of the architecture. While there are a wide array of well understood service
response mechanisms that are available to IP networks, matching a set of such mechanisms within a
controlled environment to respond to a set of service loads to achieve a completely consistent service
response remains an area of weakness within existing IP QoS architectures. The control elements
span a number of generic requirements, including end-to-end application signaling, end-to-network
service signaling and resource management signaling to allow policy-based control of network resources. This control may also span a particular scope, and use 'edge to edge' signaling, intended to
support particular service responses within a defined network scope.
One way of implementing this control of imposed load to match the level of available resources is
through an application-driven process of service level negotiation (also known as application signaled
QoS). Here, the application first signals its service requirements to the network, and the network responds to this request. The application will proceed if the network has indicated that it is able to carry
the additional load at the requested service level. If the network indicates that it cannot accommodate
the service requirements the application may proceed in any case, on the basis that the network will
service the application's data on a best effort basis. This negotiation between the application and the
network can take the form of explicit negotiation and commitment, where there is a single negotiation
phase, followed by a commitment to the service level on the part of the network.
This application-signaled approach can be used within the Integrated Services architecture, where the
application frames its service request within the resource reservation protocol (RSVP), and then
passes this request into the network. The network can either respond positively in terms of its agreement to commit to this service profile, or it can reject the request. If the network commits to the request
with a resource reservation, the application can then pass traffic into the network with the expectation
that as long as the traffic remains within the traffic load profile that was originally associated with the
request, the network will meet the requested service levels. There is no requirement for the application
to periodically reconfirm the service reservation itself, as the interaction between RSVP and the network constantly refreshes the reservation while it remains active. The reservation remains in force until
the application explicitly requests termination of the reservation, or the network signals to the application that it is unable to continue with a service commitment to the reservation [18]. The essential feature of this Integrated Services model is the "all or nothing" nature of the model. Either the network
commits to the reservation, in which case the requestor does not have to subsequently monitor the
INT-D18FINAL
Page 49 of 58
INTELLECT
IST-1999-10375
network's level of response to the service, or the network indicates that it cannot meet the resource
reservation. [19]
The question of QoS can not be solved by the INTELLECT project, but has to keep in mind if you want
to establish a help-desk system with real-time applications.
6.3 Page Mirroring
A further important feature of the help-desk system is the page mirroring of web sites for user
suppport. Page mirroring means that all actions that are done by the customer in the shop are also
executed on a mirroring browser window of the help-desk agent. So the help desk agent is able to
recognise the problems of the customer. This mirroring process can change directions, so that the
help-desk agent can force the customer’s browser window to execute all the actions the help-desk
agent executes in his browser. So the help-desk is able to take over control, to show the customer
how to perform the actions he liked to.
Because of the concept of HTTP, page mirroring has some limitations. Normally a webbrowser sends
http-requests to the web-server every time he needs a page or image. Because HTTP is stateless, the
web-server has no possibility to maintain the connection between the browser and himself. After the
request the connection is lost. That is the reason why the INTELLECT consortium implemented a polling mechanism.
Shop page generator
JS Code Adder
Mirror controller
servlet
Customer Webpage in browser
Applet
Webpage help-desk
Mirroring
Servlet
Applet
Figure 34 – Functionality of mirroring
Every time the customer creates an event in his browser (e.g. clicking on a link, pressing a button,
submitting a form, or editing a form element), this event is caught by special EventHandlers written in
JavaScript. These handlers parse the supplied information and activate a method in a hidden applet.
This applet encodes the event information and sends it together with session information (to identify
the customer) to a servlet. This servlet stores the event in a queue.
On the help-desk agent side the hidden applet is working in the so called slave mode where it is polling the servlet. So the help-desk conntects the servlet continuously (because of the HTTP limitations
as described above) and asks for incoming events. All incoming events are decoded and a JavaScript
command is generated that simulates the event. This instruction is executed with the Netscape JSObject (which is also available in the Internet Explorer).
Before a HTML page is delivered to the customer (either a static page or a dynamic page via Cocoon)
it is intercepted by a mirror controller servlet which adds the necessary JavaScript code to the HTML
code and also handles the session information for the mirroring process. All events generated on the
customer’s web page are sent to the applet which forwards this information to the mirroring servlet.
The help-desk’s browser’s applet periodically fetches all new events produced by the customer. The
web page and multimedia push service will be done at the same way as mirroring. Basically a
JavaScript instruction is created and sent to the servlet that stores the request. For the page that
should execute it. So the administrator can pop up a new browser window at the customer’s side. The
browser of the customer must be in a page mirror session in slave mode.
INT-D18FINAL
Page 50 of 58
INTELLECT
IST-1999-10375
7 Virtual Reality in variant Configuration
The objective of INTELLECT is to enable the suitable representation of products including all practicable variants in electronic commerce systems to achieve the most realistic possible visualisation. The
VR Applet as the main Configurator user-interface aims to present the product in a way that is as realistic as possible while facilitating configuration. This is achieved through a product visualization in 3D
and interactive navigation in 3D space.
7.1 Functionality and implementation
The user can interact with the product: turn, zoom, select and configure a component; the Configurator
supplies the possible configurations. The 3D view of the products is obtained by assembling 3D models of its components stored in VRML files. This functionality is implemented with the help of two programmes:
•
The manager application is intended for the shop operator, which will be in charge of the
management of the 3D data, and the assembling rules definition.
•
The user application is intended for customer use, and will mainly offer a 3D view of the product, which the customer will be able to view in several positions, and to configure according to
his wishes.
The use of Java3D (the 3D API for Java) allows the rendering of a 3D world in a Java application or a
Java applet. Java3D provides a collection of high-level constructs for creating, manipulating and rendering 3D geometric objects in a virtual universe. The Java3D world corresponds to a scene graph,
which is an arrangement of 3D objects in a tree structure that completely specifies the contents of the
virtual universe, and the way it is rendered. VRML files can be loaded and added to a Java3D universe thanks to the VRML97 library, defined by the VRML-Java3D working group.
The figures in this section show the client VR applet in action. The customer sees in the main window
(see Figure 35) the pre-defined product he has chosen in the eShop, and is able to interact with it and
manipulate it in various ways.
Three modes are available for the user: Translate, Rotate and Interact. The translate mode allows the
user to use the mouse to translate the object in the current visualisation plan, the rotation mode allows
the user to rotate the object with the mouse, and the interaction mode disables navigation with the
mouse (but not the other navigation means), so that the user can use the mouse to interact with the
scene (select an anchor or a component, or move an anchor).
Figure 35 – Client VR configuration applet
To make it easier for the user who may not be used to use the mouse for moving objects, the application calculates a list of predefined ones (Face, Back, Right, Left, Up, Down), using rotations from the
initial viewpoint. Another viewpoint allows the user to see all the objects of the scene.
The user also has the possibility to zoom in or out with the Zoom functionality. He can give directly the
zoom value, increment or decrement the existing one, or reset the zoom. All these navigation possibilities allow the user to view the object in several points of view even if he isn’t very used to navigation,
INT-D18FINAL
Page 51 of 58
INTELLECT
IST-1999-10375
and to move objects with the mouse, which may seem difficult for a novice, but which bring the sensation of manipulating the object.
Figure 36 – Component exchange dialog
Configuration of the product is accomplished as follows. The user can select the component he wants
to modify in the components list or in the viewing area, if he is in the interaction mode, and if the 3D
model is available. The customer indicates then, that he wants to replace this component, thereby
opening the component exchange dialog (see Figure 36).
The component exchange dialog displays the list of possible components that can replace the selected one. This component list is generated by the Configurator from the product database and
represents the subset of available components that will fit into the product physically and mechanically
and at the same time meet all the “soft” criteria specified for this product, or manually specified by the
user. Selecting a component in this list shows a 3D view of the component (if available) and its technical description (see Figure 36).
7.2 Creation of 3D-Data
The experiences of the various INTELLECT end-users during the development and pilot phase of
INTELLECT were in general quite similar. Nevertheless the fact, that Blauwerk, HiTEC and Interset all
produce and sell very different products had major impact in the effectiveness of the strategies employed for procurement or creation of the needed 3D material.
Blauwerk for instance faced many of the difficulties described by HiTEC and Interset in its efforts to
acquire or produce VRML models for its products. Nevertheless the relatively small product palette of
Blauwerk and the relatively simple nature of the scooter allowed the company to outsource the creation of a single VRML scooter model which was used representatively for all the Blauwerk products
(see Figure 35).
The mountain bikes produced by HiTEC consist of parts purchased from renowned suppliers like Shimano, Marzocchi, Manitou. When the representatives of these producers were contacted for the first
time the first half of the year 2000 with information about the Intellect Project, there were positive and
encouraging reactions. The industry appreciated the potential of promoting high-end equipment
through appealing VR/3D representation. Industry representatives especially stressed the necessity of
a detailed presentation of the product features to justify the higher prices of professional components.
When the first prototype had to be filled with real data, the first problems were encountered. According
to the producers there were component data available, both in 2d and 3d format. Some of the companies even had rendered product files for simulation purposes. However, the company representatives
were reluctant to give this information to outside parties.
HiTEC contacted suitable producers on numerous occasions:
INT-D18FINAL
Page 52 of 58
INTELLECT
IST-1999-10375
•
Marzocchi Spa (Bologna/IT) was contacted on the Taipei Cycle Show in April 2002 on management level. The result was, that the company would reconsider their point of view – after a
few weeks an numerous meetings with the Austrian representative, HiTEC’s request was
turned down,
•
A formal meeting with Shimano Europe Gmbh. (the European branch of the world market
leader in gear shifting and brake equipment) took place at the “EuroBike” Fair in Friedrichshafen. Also the European General Distributor participated in this meeting. Again no decision was taken at this event, but was postponed for further internal consultations. After a few
weeks and two meetings with the head of the marketing department Mr. Zeilberger only a CD
with component images was sent with an apology that this is all what Japan was ready to distribute.
•
For the negotiation with Answer Products USA (Manitou etc.) HT was in a better position, being the general representative of the company in Austria. The first request for data, with which
3d models could be generated, was communicated to Answer at the Taipei fair of 2001.
Through the regular contact with the European Management the headquarters in the States
was pushed even more. Nevertheless the request was rejected. Only after an intervention in a
personal meeting with Glen Miller, Answer’s president an assent could achieved. It took until
11/2001 until one file with the construction data of a 2 two year old fork reached HiTEC.
The situation is maybe best explained by a mail sent to HT by Manitou Inc. during the negotiation
phase, in which the development department explains that “.... any competitor would be able to use
the data for copying our product to the very detail. It even would be able to feed the information to
production machines and get a bootleg product within a few hours”.
While this stance is clearly understandable, from the viewpoint of the INTELLECT consortium the lacking co-operation from the suppliers was a major drawback for the overall goals of HT and endangered
the whole strategy of bike configuration via the Internet.
As a consequence HT Trading tried to get 3D data from other sources. First there were attempts to
capture construction data by copying them by a CAD system. HT technicians, though experienced
with system used hours of drawing time without promising results. 2D construction plans could be
generated quite easily, because it was similar to the development work being done for the components designed by HT personnel. When it came to adding the third dimension to these drawings, the
problems could not be overcome. Firstly an abundance of additional data would have been necessary
to give in. Secondly, additional program components would have been necessary together with
lengthy qualification measures for the employees involved.
All in all, no economic way of generating 3D in-house could be found by HiTEC. So, contacts with
some 3rd party suppliers of rendering services were established. But very quickly it became apparent,
that outsourcing the production of 3D models of existing parts would also become a very expensive
task. There were bids for creating a detailed 3D model of key parts like gear shifts components at
about 3.000 Euro, which would rise the price of a fully equipped VR-mountain bike summed to over
20.000 euro.
As a potential alternative, there were contacts to a company providing 3D scanning services. But also
in this case, the cost was way too high for a economic production of the necessary data (app. 5.000
Euro per hour including personnel, with the potential outcome of 1-2 parts per hour).
Also within the consortium there were attempts to generate the necessary data for the visualisation
module using. Existing blueprints were transferred to CAD systems and tested by developer partners
for their usability as source material for rendering. Such material also proved inadequate as it only
contains data of two out of three dimension on the components. Three dimensional blueprints as previously described could not be obtained from suppliers.
Interset on the other hand followed more or less the same procedure as HiTEC, but actually managed
to produce high quality material which was used in the HiTEC pilot. The first move of Interset was
much like HitEC did, to try to collect these data from each product’s manufacturer. The result was
completely disappointing. All the manufacturers responded negatively. There were two main reasons
for that result. The first was because they could not help us and the second because they did not want
to provide such valuable data to others. Immediately this idea was abandoned.
The nex approach was to rent or buy a 3D Scanner system, however after few weeks of negotiations
this idea was considered as a very expensive solution. Specifically the cost for buying such a system
INT-D18FINAL
Page 53 of 58
INTELLECT
IST-1999-10375
was starting from €2000 (for just a geometry scanner) and it was ending at around €80000
(http://3dscanners.com - a system which had as output a complete VRML file). The renting costs were
extremely high as well (around € 900 per model).
Another idea provided by Antlatide the developer partner responsible for the VR product presentation,
was the use of the PhotoModeler application (http://www.photomodeler.com/). PhotoModeler is a
software product that calculates measurements and constructs 3D models from photographs without
additional hardware. This solution was evaluated and it was considered as a very slow and inefficient
solution for the nature of the Interset products.
So the final and the only remaining idea was to construct these models from scratch. This solution was
not much faster than using PhotoModeler but it was much more efficient from the side of the file size.
PhotoModeler is constructing vertex by vertex models having as a result of huge VRML files. Interset
used a CAD tool that had the ability of constructing VRML files that were consisted by primitive 3D
data. This technique extremely reduces the file size. The consequence of using large 3D models is the
network cost. Imagine what would be the cost, if just one of the parts was 1Mb. In a configurable
product there is not only one part, there are lot more. A user using a simple 56k modem would have to
wait for too long whenever he was changing his/her configuration. So this solution was chosen and at
this time there available several VRML files of various computer parts used for the pilot.
Figure 37 – VRML model of an AGP graphics adapter
7.3 Conclusion:
Summarising it might be said, that there was a massive under-estimation of the efforts, which would
be required for getting the basic data for a VR/3D shop in general. The suppliers had understandable
objections against giving away construction details, which could be used for copying the components,
But without their co-operation, a different concept would have to be used. Maybe economic 3D scanners would have solved the problem. Or, if he 3D representation aspect would have been foreseen in
the construction process, more simple and not so secret-revealing CAD files could have been used.
The consortium also had to learn, that maybe 3D technology available at the moment is still too sophisticated and costly to be used in a plain commercial project. There was no way to justify the additional costs for creating VR promotion material, since it would not necessarily yield so much additional
turnover/profit to break even within a reasonable time frame. 3D technology - when not already foreseen in the construction process and therefore produced only for marketing reasons – would almost
double product development cost and would therefore considerably reduce the producer’s margin.
INT-D18FINAL
Page 54 of 58
INTELLECT
IST-1999-10375
8 Distributed Ordering system for the Extended Enterprise
Order processing turns out to consist mainly of the following components:
•
•
a well defined information flow in the merchant’s back-office
communication over different media:
•
between different parties (consumer, merchant, business partners, suppliers, ...)
•
between different back-office systems, which have to be integrated (legacy systems, accounting software, fax, mail system, ...)
8.1 Workflow system for incoming orders
The workflow system receives an incoming order from the webshop as an XML document with a common DTD.
The workflow defines all the necessary activities to process an order via a flexible definition of the
workflow process and is a possibility to integrate/replace the existing handling of an order at the merchant’s side. Of course tracking of order the state is also possible.
The choice for using XML as representation of the order data proved to be a very flexible way to handle workflow data. Many of the actions necessary in the workflow could be realised via XSL transformations without the need to write a single line of code. documents, that had to be created based on
the order data could be generated via stylesheets. Stylesheets are like templates and their variable
parts are filled by data of the XML representation of the order.
While XML technology has made many steps forward during the duration of the project, XML tools not
really have improved. Creating a stylesheet still means writing it by hand with the need of a deep
XSLT knowledge. XML tools (like Altova’s XMLspy or softquad’s xmetal) ease this task, but still a
highly skilled person has to do it. While this conception enabled to do rather complex tasks without the
need to code something, the load is still on programming skilled people to perform the task of writing
the stylesheets.
8.2 Back-office system integration
Operational systems are varying widely in their possibilities to communicate with them. They provide
file or database interfaces, library or socket API's, Java interfaces or messaging functionality, to name
just a few. There are also many possibilities for the data formats, like CSV (Comma Separated Values), EDI formats (Electronic Data Interchange), XML formatted data, etc.
Our end-users had no back-office system, that could have been integrated, because they were all
proprietary with no open interfaces or not already fully working (SAP at Interset).
The order module provides some standard interfaces based on XML, which is the most important
standard for this by now. Because all the internal data structures of the order module are also based
on an XML representation, it’s rather easy to convert XML-based data from one schema to another
with a stylesheet.
There is also an Intellect Order Module API that makes it possible to develop integration software for
BackOffice systems using proprietary formats.
8.3 Distributed Infrastructure
Integration of the merchant’s BackOffice systems into the Intellect shop is one of the major goals of
the order module. As long as these operational systems are situated at the same location as the remaining Intellect shop, this is easy to achieve, by implementing the required interfaces to those programs. Within a distributed situation this feature requires that the operational systems have a connection to the Intellect shop. Because all the other modules can exclusively reside on an ASP’S (Application Service Provider) side, the order module needs a special infrastructure for this. Every merchant
would have to install an “Intellect BackOffice Connector” in his network; depending on the security
INT-D18FINAL
Page 55 of 58
INTELLECT
IST-1999-10375
structure, the communication between the BackOffice connector and all the other parts of the order
module takes place over RMI, HTTP or email. The order module handles these components, that have
to be accessed via this special mechanism as external order processing modules.
The technology to achieve this was SOAP (simple object access protocol) which was developed in
late 1999 and which experienced tremendous support from the industry since this is the basis for the
overhyped “web service” area.
8.4 XML parser issues
XML technology still was at the beginning when we started coding for the intellect project. Since then,
many versions of XML parsers, XSL transformators and Xpath additions have been released. While
the main functionalities of XML parsers where rather standardized via the SAX and DOM API, especially Xalan, which is the java reference implementation for XSL processors, frequently changed their
interface. Our developers often stood in front of the decision whether to rewrite much of the existing
code to use the recent version of Xalan or not to use some important new features. The same was
true for the XPath processors.
The JAXP (java API for XML processing) standard from sun was published in 2001, this API abstracts
most of the XML/XSL functionality; Anecon did not rewrite their order processing module another time,
because the Xalan API has stabilized since then and we where not sure, if the JAXP specification will
experience major changes after their initial version 1.0. Furthermore JAXP does still not include Xpath
functionality, which is absolutely necessary for the module.
8.5 Conclusion
Using cutting edge technology proved to be very dangerous for a project with such a long duration.
Since the start of development in June 2000 many dozens of new versions of XML parser, XSL processors, XPath evaluators, soap implementations have been available, every time with new features
and lacking compatibility to earlier versions.
Maintaining the code, so that it is up to date with the industry standards needs much resources, that
were not planned in the project. Remaining on the initial versions means ignoring the improvements in
performance and features. So it is a very hard decision when to upgrade and when not.
In the area of soap for our distributed order processing this problem was even worse. The unexpected
hype about web services made changes of standards and versions much faster. The active discussion
about web services in eBusiness also brought many new ideas to our vision of the order processing
module. If we had the chance to re-design the whole module from ground up, our approach would be
based much more radically on XML, because standards and API’s have matured now and been consolidated, and much more problem domains can be addressed now with a infrastructure that is based
on XML.
INT-D18FINAL
Page 56 of 58
INTELLECT
IST-1999-10375
9 Acknowledgements
This project is funded by the European Commission as IST project IST-1999-10375 INTELLECT “Intelligent Online Configuration of Products by Customers of Electronic Shop Systems” (http://www.istintellect.com). The authors wish to thanks the European Commission for their support. We also wish to
acknowledge our gratitude and appreciation to all INTELLECT partners for their strong support and
valuable contribution during the various activities presented in this paper.
INT-D18FINAL
Page 57 of 58
INTELLECT
IST-1999-10375
References
[1] Neumann B. (1988) Configuration Expert Systems: A Case Study and Tutorial. Proc. Conf. on
AI in manufacturing, Assembly, and Robotics, Oldenbourg
[2] INTELLECT (2000) Software functional specification. Handbook D07, internal document, INTELLECT Consortium
[3] INTELLECT (2000) Module Integration Specification. Deliverable D08, internal document; INTELLECT Consortium
[4] Gamma E., Helm R., Johnson R., Vlissides J. (1995) Design Patterns, Elements of reusable
Object-Oriented Software. Addison Wesley
[5] Schilingheider J. (1994) Methodik zur Entwicklung rechnerunterstützter Konfigurationssysteme. Carl Hansen Verlag, München Wien
[6] Detken K.-O., Fikouras I. (2000) Intelligent and Secure 3d-Configuration of Products in Electronic Shop Systems. Third International Conference on Telecommunications and Electronic
Commerce (ICTEC3), Dallas/Texas, USA
[7] INTELLECT (2001) System Implementation intermediate Progress Report. Deliverable D09,
internal document, INTELLECT consortium
[8] Günter, A; Dörner, H; Gläser, H; Neumann, B; Posthoff, C; Sebastian, H-J., Das Projekt
PROCON: Problemspezifische Werkzeuge für die wissensbasierte Konfigurierung. Technische Uni Chemnitz, Martin-Luther Uni Halle-Wittenberg, Uni Hamburg, Technische Hochschule Leipzig, Technische Hochschule Zwickau. PROCON-Bericht Nr.1, 1991
[9] Beckmann M (2000) Conception, testing and implementation of IP based applications regarding the field of Computer Supported Co-operative Work (CSCW): Standards, Products, Platforms. Bremen University of applied sciences and South Bank University London; Master
Thesis; Course: Beng (Hons)
[10] Braden R., Clark D., Shenker, S. (1994) Integrated Services in the Internet Architecture: an
Overview. RFC-1633, IETF
[11] Cunis, R; Günter, A; Strecker, H. Begriffshierarchie-orientierte Kontrolle. In Das PLACONBuch. Springer, Informatik Fachberichte Nr. 266 1991
[12] Bense, H; Bodrow, W. Wissensbasierte Dialogführung für ein Beratungssystem zum Softwarequalitätsmanagement. In Objektorientierte und regelbasierte Wissensverarbeitung. Heidelberg, Berlin, Oxford: Spektrum, Akad. Verl., 1995
[13] Lunze, J., Künstliche Intelligenz für Ingenieure. München, Wien: Oldenburg Verl. 1994
[14] Cunis, R; Günter, A; Strecker, H., Fallbasiertes Konstruieren mit Bibliothekslösungen. In Das
PLACON-Buch. Springer, Informatik Fachberichte Nr. 266 1991
[15] Tsang, E., What is Constraint Satisfaction? 1998. http://scwww.essex.ac.uk/CSP/tutorial.html,
15.12.00
[16] Barták, R., Constraint Programmimg: In Pursuit of the
http://ktilinux.ms.mff.cuni.cz/~bartak/html/publications.html, 13.12.00
Holy
Grail,
1999,
[17] Jboss EJB Application Server, http://www.jboss.org/
[18] Braden R., Clark D., Shenker, S. (1994) Integrated Services in the Internet Architecture: an
Overview. RFC-1633, IETF
[19] Huston G. (2000) Next Steps for the IP QoS Architecture, RFC-2990, Category: Informational,
Network Working Group, IETF
[20] Ioannis Fikouras, Ewgeni Gisbrecht, Lean Configuration: Interactive Configuration for the
Internet, eBusiness and eWork 2001, Venice, 17-19 October
INT-D18FINAL
Page 58 of 58

Deliverable (public)

Transcription

Similar documents

Intellect-powered security at Abu Dhabi National Oil Company

Investors Presentation - Intellect Design Arena Ltd

Deliverable (public)

Deliverable (public)

The Difference Between the Brains of Men and Women

Cover

Skate Board Collab Poster

A LOVE LIKE NO OTHER - Vlisco V