D21 Evaluation and Assessment of the SODIUM Platform ... - ATC

SODIUM 0621F40_Evaluation and Assessment of the SODIUM Platform Methodolodgy and Tools 

SIXTH FRAMEWORK PROGRAMME 

INFORMATION SOCIETY TECHNOLOGIES 

IST-FP6-004559 SODIUM 

“Service Oriented Development In a Unified framework” 

D21 Evaluation and Assessment of the SODIUM 

Platform, Methodology and Tools 

Identifier 

Date: January 2007 

Author(s): 

Distribution: All partners 

A.M. Zaharia, M. Enache, G. Grecu (Medisystem); A. Kalligeris, R.M. 

Brown, S.Topouzidou (ATC); T. Hansen (LOCUS), A.Berre (SINTEF) 

Workpackage: WP4-SODIUM platform integration and evaluation 

Version: 4.0 

Status: Final 

Abstract: 

This document comprises the final version of the Evaluation and 

Assessment of the SODIUM Platform, Methodology and Tools 

FP6-004559 p.1 of 139

Revision History 


Version Identifier Revision Outline Revision Author 

0.1 Template and TOC provided. Initial 

version 

A. Kalligeris (ATC) 

0.2 First Revised Version A. Kalligeris (ATC), R. 

Brown (ATC), M. 

Melissinos, A. Birbilis (ATC), 

0.3 Second Revised Version: Added 

Quality Assessment Chapter 7 

0.4 Second Revised Version: Revised 

Quality Assessment Chapter 7 for 

suitability with SODIUM 

0.5 Addition of End Users Sections; 

Update of Industrial User 

Requirement; Final Editing 

0.6 Updated Section 6 regarding 

Medisystem requirements 


R. Brown (ATC), M. 

Melissinos, A. Birbilis (ATC) 

T. Hansen, A-M Zaharia, M. 

Enache, A. Kalligeris (ATC), 

R. Brown (ATC), M. 

Melissinos, A. Birbilis (ATC) 

A-M Zaharia, M. Enache, R. 

Brown (ATC) 

0.7 Updated edition S. Topouzidou, A. Kalligeris 

(ATC) 

0.8 Edition after MEDISYSTEM part of 

D5.2 received 

0.9 Update with comments by ETH and 

NKUA 

S. Topouzidou, 

M.Melissinos, A. Kalligeris 


M. Melissinos (ATC) 

1.0 Updated edition A. Kalligeris, S. Topouzidou 


1.1 New enhanced Edition after 

completion of D3 Part I 

1.2 Updated Version with comments 

received by NKUA 

1.3 Final Version after new ETHz, 

NKUA comments 


S. Topouzidou, M. 

Melissinos, R. Brown, A. 

Kalligeris (ATC) 

S. Topouzidou, A. Kalligeris 





1.4 Version on progress up to M24 M. Enache, A.M. Zaharia 

(Medisystem), S. 

Topouzidou, R. Brown 


1.5 Revisions M. Enache, A.M. Zaharia 


Topouzidou (ATC) 




1.7 Revisions S. Topouzidou, A. Kalligeris 


1.8 Revisions T.Hansen (LOCUS) 

1.9 Revision to include feedback from 

NKUA and SINTEF 

G. Athanasopoulos (NKUA); 

R.Gronmo (SINTEF); M. 

Enache, A.M. Zaharia 

(Medisystem); S. 





2.1 Revisions as per comments by 

NKUA, ATC 

M. Enache, A.M. Zaharia 



2.2 Section 4.4.1 completed by LOCUS T.Hansen (LOCUS) 

2.3 Updated Table 12, Section 5.4.1.9 M. Enache (Medisystem) 

3.1 Section 4 updated by LOCUS T.Hansen (LOCUS) 

3.2 Section 5 updated by Medisystem M. Enache (Medisystem) 

3.3 Section 1,3,7,8, 9 updated by ATC S.Topouzidou, A.Kalligeris 





3.4 Section 6, 7 updated by SINTEF Arne J. Berre (SINTEF) 

3.5 Section 5 updated by Medisystem M. Enache (Medisystem) 

3.6 Section 3,4 and 5 updated by 

NKUA 

A. Tsalgatidou, G. 

Athanasopoulos, M. 

Pantazoglou (NKUA) 

4.0 Final checking S.Topouzidou (ATC) 


Executive Summary 


This document comprises the final version of the deliverable for the Evaluation and 

Assessment of the Outcome of Project SODIUM, available at the end of the project. 

The document provides the assessment of project results with respect to: 

� the requirements set by the Industrial Partner (ATC) 

� feedback from the LOCUS pilot 

� feedback from the MEDISYSTEM pilot 

� feedback from User Groups 

� feedback received from the demonstration of SODIUM during the IST event 2006 

in Helsinki 

� Business Plan requirements 

This latest version has been mainly based on the feedback to be received from the two user 

pilots as well as feedback from external users (those comprising the SODIUM user forums in 

Greece, Norway and Switzerland) as well as the SODIUM demonstration in the IST event 

2006. 


Table of Contents 


1. Introduction ..................................................................................................................12 

2. Methodology for Assessment .......................................................................................13 

3. Evaluation of the SODIUM Methodology, Platform and Tools with respect to the 

requirements set by the Industrial Partner of the Project (ATC).............................................15 

3.1 Summary of Requirements .......................................................................................15 

3.1.1 Top Level Business Requirements and Assessment of Achievement upon 

Project end. .....................................................................................................................15 

3.1.2 Functional Requirements....................................................................................19 

3.1.3 Non - Functional Requirements..........................................................................22 

3.2 Assessment of Using the SODIUM Approach...........................................................26 

3.2.1 Qualitative Assessment of Benefits from using the approach.............................26 

3.2.2 Problems envisaged in Using the Approach.......................................................27 

4. Evaluation of the Results of the LOCUS pilot...............................................................28 

4.1 Scope of the Pilot......................................................................................................28 

4.1.1 Business Requirements......................................................................................28 

4.1.2 Technical Requirements.....................................................................................29 

4.1.2.1 Functional requirements ..............................................................................29 

4.1.2.2 Non functional requirements ........................................................................29 

4.1.3 Pilot Description .................................................................................................30 

4.2 SODIUM Features tested (LOCUS) ..........................................................................31 

4.3 Evaluation checklists used........................................................................................41 


4.4.1 Preliminary Assessment –Installation Phase......................................................41 

4.4.1.1 Description of LOCUS environment in the context of the pilot .....................41 

4.4.1.2 SODIUM platform tools installation : problems and solutions ......................42 

4.4.1.3 Evaluation of platform-level requirements during the installation .................43 



4.4.2 Assessment related to the use of tools and methodology till end of project .......45 

4.4.2.1 Evaluation of the Visual Editor .....................................................................45 

4.4.2.2 Evaluation of the USQL engine....................................................................47 

4.4.2.3 Evaluation of the overall methodology .........................................................49 

4.4.2.4 Overall evaluation conclusions ....................................................................51 

4.4.3 Meeting Key Business Requirements for LOCUS ..............................................55 

4.4.4 Qualitative Benefits from using the SODIUM Approach .....................................56 

4.4.5 Cost of Using the SODIUM Approach ................................................................57 

4.4.6 Cost Benefit Analysis .........................................................................................59 

4.5 Lessons Learned, Recommendations and Suggestions for improvement for 

commercialization ...............................................................................................................61 

4.5.1 Recommendations for future enhancement........................................................70 

5. Evaluation of the Results of the MEDISYSTEM pilot ...................................................76 

5.1 Scope of the Pilot......................................................................................................76 

5.1.1 Business Requirements......................................................................................76 

5.1.2 Technical Requirements.....................................................................................77 

5.1.2.1 Functional requirements ..............................................................................77 

5.1.2.2 Non functional requirements ........................................................................77 

5.1.3 Pilot Description .................................................................................................78 

5.2 SODIUM Features tested (MEDISYSTEM)...............................................................80 

5.3 Evaluation checklists used........................................................................................85 


5.4.1 Preliminary Assessment –Installation Phase......................................................85 

5.4.1.1 Description of Medisystem environment in the context of the pilot ..............85 

5.4.1.2 SODIUM platform tools installation : problems and solutions ......................87 

5.4.1.3 Evaluation of platform-level requirements during the installation .................88 



5.4.2 Assessment related to the use of tools and methodology till end of project .......89 

5.4.2.1 Evaluation of the Visual Editor .....................................................................89 

5.4.2.2 Evaluation of the USQL Engine ...................................................................91 

5.4.2.3 Evaluation of the USCL Engine ...................................................................94 

5.4.2.4 Evaluation of the Composition repository.....................................................96 

5.4.2.5 Evaluation of the overall methodology .........................................................97 

5.4.3 Meeting Key Business Requirements for MEDISYSTEM...................................99 

5.4.4 Qualitative benefits from using the SODIUM approach ....................................100 

5.4.5 Cost of Using the SODIUM Approach ..............................................................103 

5.4.6 Cost Benefit Analysis .......................................................................................104 

5.5 Lessons Learned, Recommendations and Suggestions for improvement for 

commercialization .............................................................................................................106 

5.5.1 Recommendations for future enhancement:.....................................................108 

6. Evaluation as per the feedback from external user forums ........................................111 

6.1 Feedback from user forums ....................................................................................111 

6.1.1.1 Norwegian User Forum..............................................................................112 

6.1.1.2 Greek User Forum .....................................................................................114 

7. Evaluation at the IST Event 2006...............................................................................115 

8. Evaluation of Results with Respect to Business Plan Requirements .........................117 

8.1 Summary of SODIUM Assets .................................................................................117 

8.2 Summary of SWOT Analysis Findings ....................................................................118 

8.2.1 Effectiveness of SODIUM Methodology, platform and Tools in Exploiting 

Opportunities .................................................................................................................119 

8.2.2 Provisions and Measures taken to minimize weaknesses and their effects .....120 

8.3 Recommendations and Suggestions for Commercialization...................................121 

9. Conclusions and Suggestions for further work / Guidelines for Productisation ..........122 

9.1 Recommendations from the Industrial User............................................................122 



9.2 Recommendations from LOCUS.............................................................................123 

9.3 Recommendations from MEDISYSTEM .................................................................123 

9.4 Recommendations from the User Forums ..............................................................124 

10. References.................................................................................................................125 

11. Appendix I –Questionnaires used in the sessions held in Athens & relevant results 

(Greek User forum) ..............................................................................................................126 

12. Appendix II - Norwegian User Forum Questionnaire and related results....................135 

13. Appendix III - Evaluation checklists for the SODIUM tools.........................................136 

13.1 Visual Editor ........................................................................................................136 

13.2 USQL engine .......................................................................................................137 

14. Appendix IV - Evaluation checklists for the SODIUM methodology............................139 


LIST OF ABBREVIATIONS 

CIO Chief Information Officer 

DB Database 

ERP Enterprise Resource Planning 

GPRS General Packet Radio Service 

GSM Global System for Mobile Communications 

HTTP Hypertext Transfer Protocol 

IDE Integrated Development Environment 

IIS Internet Information Services 

ISA Internet Security & Acceleration 

ISP Internet Service Provider 

IST Information Society Technologies 

LGPL GNU Lesser General Public License 

MS Microsoft 

NA Not Applicable 

QoS Quality of Service 

RAD Rapid Application Development 

RDS Romanian Data System 

RTD Research Technological Development 

SMS Short Message Service 

SOA Service Oriented Architecture 


SODIUM Service Oriented Development In a Unified fraMework 

SWOT Strengths, Weaknesses, Opportunities, Threats 

UDDI Universal Description, Discovery and Integration 

UML Unified Modelling Language 

USCL Unified Service Composition Language 

USQL Unified Service Query Language 

VSCL Visual Service Composition Language 

WSRF Web Services Resource Framework 


LIST OF TABLES 


Table 1: Source of evaluation for ATC’s functional requirements ..........................................21 

Table 2: Source of evaluation for ATC’s non-functional requirements ...................................25 

Table 3: SODIUM platform features tested at LOCUS pilot ...................................................37 

Table 4: Important features tested at LOCUS pilot ................................................................40 

Table 5: LOCUS equipment and internet services used in the context of the pilot.................41 

Table 6: Required software for the LOCUS pilot ....................................................................42 

Table 7: LOCUS: Installation of SODIUM tools / server side: problems and solutions...........43 

Table 8: LOCUS : Installation of SODIUM tools / client side: problems and solutions ...........43 

Table 9: Evaluation of platform level requirements: installation phase at LOCUS .................44 

Table 10: SODIUM platform features tested at MEDISYSTEM pilot ......................................83 

Table 11: Important features tested at MEDISYSTEM pilot ...................................................84 

Table 12: MEDISYSTEM equipment and internet services used in the context of the pilot ...86 

Table 13: Required software for the MEDISYSTEM pilot.......................................................86 

Table 14: MEDISYSTEM: Installation of SODIUM tools / server side: problems and solutions 

........................................................................................................................................87 

Table 15: MEDISYSTEM : Installation of SODIUM tools / client side: problems and solutions 

........................................................................................................................................88 

Table 16: Evaluation of platform level requirements: installation phase at MEDISYSTEM ....88 

Table 17: MEDISYSTEM Preliminary qualitative assessment .............................................102 

Table 18: Norwegian User Forum Activities .........................................................................113 

Table 19: Greek User Forum Activities ................................................................................114 

Table 20: SODIUM tangible assets......................................................................................117 


1. Introduction 


The purpose of this document is to provide an assessment of the results of the SODIUM 

project, taking into account: 

� Requirements set by the Industrial partner (ATC) including top level business, 

functional and non-functional requirements, the latter two based on the user pilots 

assessment as described below 

� Functional and non-functional capabilities of the SODIUM platform and tools 

based around the two user pilot applications that can be used to examine whether 

the requirements of the SODIUM platform described in deliverable D3 part I [1] 

are met. To ensure that the evaluation is comprehensive the pilots have exercised 

all SODIUM components, from the visual development tools to the run-time 

environment. 

� Feedback received from the external user forums 

� Feedback received from the demonstration of SODIUM during the IST event 2006 

in Helsinki 

� Requirements set by the SODIUM Business plan 


2. Methodology for Assessment 


The Methodology to be followed is developed especially for SODIUM taking into account its 

characteristics as: 

1. A project for pre-competitive research in state-of-the-art Technology co-funded by the 

European Commission, where the Contribution of Technology Institutes and 

Universities is of paramount importance. 

2. A project with users with completely different profiles and different (though compatible 

and complementary) aspirations for the outcome of the project that have provided very 

specific and comprehensive requirements 

3. A project where full–scale commercial exploitation is the direct goal of the one main 

industrial partner, whereas internal exploitation the goal of the two users 

4. A project, which offers significant possibilities for offering Consulting Services by all 

Technical Partners. 

5. A project that develops a Software Platform and tools that, irrespective of their future 

use, will need to satisfy certain Quality standards in order to be commercially 

successful 

6. A project which adopts an Open Source Approach 

To meet the above ends, Evaluation and Assessment is being performed in a composite 

multi-stage approach in order to ascertain that all the above characteristics are both taken 

into account and exploited towards obtaining the optimum project outcome. 

This approach involves: 

• An assessment of the degree that the SODIUM Outcome satisfies the Top-level 

Business, Functional and non-Functional Requirements of ATC, who in addition to 

being the project coordinator also serves as the main Industrial partner in the 

Project. 

• An assessment of the degree that the SODIUM Outcome satisfies the Functional 

and non-Functional Requirements of LOCUS, a user that will mainly integrate and 

compose publicly available services within its current software product line, along 

with recommendations for Commercialization for clients of a similar profile to them 

• An assessment of the degree that the SODIUM Outcome satisfies the Functional 

and non-Functional Requirements of MEDISYSTEM, a user that has specific 

issues as it is a member of a large multinational Group of companies and will also 

deploy and use services within a “closed environment” in addition to publicly 

available services, along with recommendations for Commercialization for clients of 

a similar profile to them. 



• An assessment of the degree that the SODIUM Outcome satisfies market 

Requirements stemming from the analysis of the feedback received from the 

SODIUM user forums. 

• An assessment of the degree that the SODIUM Outcome satisfies Business 

Strengths and Opportunities for Commercialization of said Outcome, while, at the 

same time, catering for Weaknesses identified in the Business Plan. 

Thus, this Report bridges the gap between Technology Development and Commercial 

Activities, by assessing Project Outcome in Business Terms and by providing guidelines on 

how to improve this Outcome for being competitive in the real Market, as this has been 

traced in the description of work. 



3. Evaluation of the SODIUM Methodology, Platform and Tools 

with respect to the requirements set by the Industrial Partner 

of the Project (ATC) 

3.1 Summary of Requirements 

3.1.1 Top Level Business Requirements and Assessment of Achievement upon 

Project end. 

For each of the Top Level Business Requirements set by the Industrial Partner (ATC) and 

presented in Deliverable D3 Part I [1], we summarise below the assessment method, 

executed evaluation activities and results up to M30 of the project 

A. Top Level Business Requirement: Employ technologies and tools for service discovery 

and composition that, upon the project end, are or are expected to become very soon, 

industry standards and thus acceptable by customers. 

Assessment Method 

� SODIUM will be presented to ATC’s customer base. A survey will be used to 

evaluate SODIUM platform features with respect to addressing key functional and 

non-functional requirements of a platform supporting the discovery, composition, 

and execution of services as set in D3 Part I. This is directly related to the 

operation of the User Forum set up by ATC in Greece and related activities are 

also reported in Section. 6 

Related evaluation activities and results M18-M24 

� SODIUM has been presented to the Chief Information Officers (CIOs) of the 

Fourlis Group (where ATC participates) at the end of June 2006. The session 

involved a presentation of the SODIUM approach in supporting SOA development 

and evolved into an open discussion regarding participants’ familiarity with SOA, 

as well as perceived benefits and problems with following such an approach. In 

addition, respondents were asked 1 to rate the importance of the SODIUM 

platform features supporting discovery and composition of heterogeneous 

services. The rationale for such an approach was to confirm the relevant rating of 

SODIUM features performed by partners as reported in Deliverable D3 Part I [1] 

which influences related development work. As this was the first session with 

these participants, reference was made only to the overall SODIUM platform 

features rather than detailing features of the different SODIUM tools, which would 

require a detailed demonstration of the tools. As per respondents answers, the 

1 (A simple questionnaire was used and can be found in Appendix I –Questionnaires used in the sessions held in Athens & relevant results) 



following were considered the most important “selling” features of the SODIUM 

platform : 

o Modularity 

� provision of the SODIUM platform tools as modules which can be easily 

used on their own (e.g. use of the service discovery module only) or 

along other complementary applications available within an organisation 

(e.g. use of an alternative composition editor or execution engine) 

o Compatibility with services developed by different development tools 

� .NET based services should be accommodated as they form a large part 

of services used within organisations 

o Standards compliance 

� Open source on the other hand, although considered a desirable feature for the 

platform, is not seen as a must 

� Not surprisingly, respondents stated that their familiarity with SOA is mainly 

around web services, thus did not comment on the platform’s support for JXTA 

p2p services and WSRF specifications (especially as p2p and grid services are 

not deployed within their business environments). 


� Related assessment has been further ascertained before project end with 

workshops / presentations of the SODIUM results to representatives of ATC 

customer base including the banking and media sectors which form part of the 

User Group in Greece. These workshops have been held in November 2006 as 

also reported in Section 6. 

� Both workshops included a discussion and brainstorming session which evolved 

around the drivers, challenges and perceived impact of the adoption of SOA by 

these two sectors. 

� Furthermore, in the context of these workshops and as part of the relevant survey 

initiated in the previous period, participants have been asked to respond to the 

questionnaire enabling the identification of the key features of the SODIUM 

platform and tools that should be taken into consideration for further exploiting 

results post project end. 

Feedback from the Banking workshop 

� As identified by participants, the banking sector is considered among the early 

adopters of SOA 

� The main drivers for SOA adoption in the sector include the need to 



� overcome the limitations of legacy systems and increase reuse 

� adapt banking systems to changing customer requirements 

(Multichannel integration is considered key for all participants) as well as 

compliance regulations while keeping operating costs low 

� address integration challenges brought about by mergers and 

acquisitions 

� In terms of challenges, the following were identified: 

� perceived costs and complexity related to SOA implementation 

� need for Business and IT alignment (not a sector specific issue but still of 

high importance) 

� need to maintain a balance between flexibility brought about by SOA 

solutions and the security and data integrity that are absolutely critical in 

the banking environment 

� ensuring availability of services comprising an application when the 

application is executed 

� trustworthiness of third party service providers 

� Despite challenges, impact of SOA in the sector is perceived positively as banks 

are expecting a greater reuse of IT assets, a reduction in the cost related to the 

development and implementation of new systems and an enhanced ability to 

create dynamic business services that respond to customer needs 

� In summary, participants agreed that the SODIUM solution fits well in the banking 

environment where there is a strong need to develop applications that respond to 

changing customer needs and support reuse of services in the context of the 

bank’s multi-channel approach through a variety of access devices (PC, PDA, 

mobile) to support customer self-servicing. 

In addition to the feedback received from the discussion and brainstorming session, 

following a demonstration of the SODIUM platform and tools, participants were also 

asked to identify the most important features of the solution. Participants identified 

Standards compliance as a very important feature The ability to support 

heterogeneous services is also a unique selling point for the platform, especially as 

the sector places importance in support of grid services (in addition to already 

extensively deployed web services) to address expanding data volumes and ensure 

increased response times. The ability to specify QoS properties at design time is also 

seen as a very important feature. Furthermore, the fact that the solution addresses 

the whole development life-cycle from design to execution is also considered as a 

key selling point. 

Feedback from the Media workshop 



� As identified by respondents, the Media industry is one facing numerous 

challenges in terms of complexity and inefficiencies. 

� Workflow is the key word in content–oriented businesses, however still and to a 

large extent many activities are being performed manually in a non-organised 

manner 

� Processes supporting the creation, management and distribution of digital assets 

are not linked with other business systems resulting in delivery delays 

� SOA’s perceived impact lies in support of integration which is currently lacking in 

the sector as per participants views. For instance the ability to integrate content 

and billing systems is considered very important As is the case with the Banking 

sector, multichannel delivery is also considered critical and is expected to be 

facilitated by SOA. 

� In summary, participants stated that service oriented development with SODIUM 

can potentially improve process workflows in content delivery enabling integration 

of their systems. SODIUM support for heterogeneous services is also considered 

important as the sector has strong needs for collaboration in work which can be 

supported through p2p services as well as processing of content which can be 

effected through grid services. Modularity of the solution is also considered a very 

important feature. 

Participants in both workshops identified the need for training for potential users of the 

SODIUM platform and tools that should be provided by a team of qualified SODIUM experts, 

the provision of documentation and support for the tools. 

B. Top Level Business Requirement: Provide total independence from platform providers, 

Operating Systems, Proprietary Solutions, etc. 


� Ensuring that this requirement has influenced the SODIUM Architecture and 

subsequent development and integration work continues to satisfy this 

requirement 


� This requirement was a pre-requisite and is already reflected in the Open 

Architecture of SODIUM. SODIUM platform constituent tools namely Visual 

Composition Studio, USQL engine, USCL engine and Composition Repository are 

all provided as open-source and platform-independent software components. 


� It is considered that this requirement has been met. No further integration or 

refinement activities were expected or proved to adversely affect this requirement. 


3.1.2 Functional Requirements 


The following table summarises the Functional Requirements set by the Industrial Partner 

and presented in Deliverable D3 Part I [1] and source of evaluation thereof. The assessment 

of achievement of these requirements has been elaborated in the context of the two pilots, as 

described in Sections 5 and 6 hereinafter. 


Req. Requirement Description Source of 

code 

Evaluation 

RP04 Quick & easy The platform should MEDISYSTEM Pilot, 

discovery of enable the quick and LOCUS pilot 

heterogeneous easy discovery of 

services 

heterogeneous services Related functionality 

(P2P, Grid or Web to be evaluated is 

Services), primarily based provided by the 

on the desired 

characteristics. 

USQL engine 

RP12 Audit Trails With all our Enterprise MEDISYSTEM Pilot, 

solutions, audit trails are 

accentual in diagnosing 

LOCUS pilot 

fails and problems. In Related functionality 

some applications it is a to be evaluated is 

requirement by law. It is provided by the 

essential to be able to USCL engine and 

capture execution the Composition 

information such as who 

executed a composition, 

when, what where the 

inputs to the execution 

and the result 

Repository 

RP05 Visual design of Being able to visualize MEDISYSTEM Pilot, 

compositions compositions aids the 

developer to understand 

LOCUS pilot 

the service composition, Related functionality 

reduces the amount of to be evaluated is 

code that is written and provided by the 

reduces the time taken to Visual Composition 

produce compositions Studio 

FP6-004559 p.20 of 139 


Req. met Notes from the pilots 

Yes. The USQL Client has been integrated into the 

Visual Composition Studio as a dialog, so the 

USQL engine is accessed just by right-clicking 

on a task in the composition In addition, 

queries are formulated with the USQL Dialog in 

a service type-independent manner. 

Yes. All execution is logged in the Execution 

Engine. It is possible to see all input and all 

output in the log. 

Yes. The Visual Composition Studio provides a 

graphical interface making it easy to create a 

composition.


code 


RP06 Reuse of existing The platform should MEDISYSTEM Pilot, 

solutions 

enable the reuse of 

existing services as well 

LOCUS pilot 

as existing compositions Related functionality 

to be evaluated is 

provided by the 

Visual Composition 

Studio, and the 

Composition 

repository 

RP14 Composition 

Storage and 

Management 

The platform should 

enable the management 

and versioning of source 

code produced by the 

SODIUM platform tools 

MEDISYSTEM Pilot, 

LOCUS pilot 

Related functionality 

to be evaluated is 

provided by the 

Composition 

repository 




Yes. A composition can be created in the Visual 

Composition Studio, and then stored in the 

Composition Repository. At a later stage the 

composition can be retrieved from the 

Composition Repository and be opened in the 

Visual Composition Studio. 

Yes The Composition Repository can store several 

versions of a composition. 

Table 1: Source of evaluation for ATC’s functional requirements

3.1.3 Non - Functional Requirements 



The following table summarises Non Functional Requirements Set by the Industrial Partner (ATC) and source of evaluation thereof. It is 

Compatible with Table 6-1 of D3 Part I [1]: 


code 


RP03 Platform 

SODIUM platform MEDISYSTEM 

Independence should be 

Pilot, 

independent of 

platform providers 

LOCUS pilot 

and Operating The pilots make 

Systems 

use of different 

environments. The 

successes or 

failures of setting 

up and running the 

SODIUM platform 

will be captured by 

maintaining a log of 

the setup and 

operation of the 

SODIUM platform. 


Partially LOCUS and MEDISYSTEM have set up the SODIUM platform on a 

Windows environment and did not attempt to install the SODIUM 

platform in different platforms, as this was not required by their 

business and pilot needs. 

Still, SODIUM is Java-based; thus, as Java is platform-independent, 

it should not cause any problems to set up the SODIUM platform on 

other platforms


code 


RP07 Open Source The platform should It is considered that 

accommodate an this requirement is 

open source 

approach so as to 

met. 

enable its extension The adoption of 

with additional Open Source 

features if needed. implementation has 

been ensured in the 

design and 

subsequent 

development of the 

platform and tools. 

RP10 Scalability The platform should MEDISYSTEM 

accommodate the 

needs of various 

Pilot, LOCUS pilot 

types of clients, The pilots with 

ranging from low SODIUM have 

demanding solutions different load 

supporting just a few scenarios. The 

concurrent users, to pilot users will be 

high demand 

asked to measure 

solutions supporting the performance 

higher levels of characteristics of 

concurrent users. the SODIUM 

platform during the 

pilots. 




Yes The SODIUM platform was installed under LGPL. Source code will 

be available after completion of the project. 

Yes This was demonstrated at an earlier review by ETHz. Additional 

comments from Locus are: there seems to be little overhead in 

running the composition through the Execution Engine. The only 

overhead occurs after the Execution Engine has been restarted, then 

the first execution takes a bit longer. 

In addition a test was done starting the Execution Engine using first a 

single client, then using two clients.. 

When running the Execution Engine from one client, and running a 

composition 50 times, the average performance was 1644ms. 

When running the same composition from two clients, the average 

perfomance was 1831ms and 1782ms. There is hence a lower 

perfomance when running two clients, but this is probably due to lack 

of memory on the computer where the Execution Engine was 

installed.





code 


RP01 Standards The SODIUM 

MEDISYSTEM Yes The SODIUM tools support standard SOAP Web services, JXTA P2P 

Compliance Platform should Pilot, LOCUS pilot 

services, and WSRF-compliant Grid services (i.e. stateful web 

support appropriate 

services). 

standards for P2P, Both pilots make 

Grid and Web use of services 

Services. 

from different 

sources. Any 

related problems 

encountered during 

the pilots will be 

reported. 

RP13 RAD The platform should LOCUS pilot Yes Creating compositions in the Visual Composition Studio facilitates the 

enable rapid 

process instead of manually having to create the composition in a 

application 

standard programming language. Transformation to the USCL 

development and 

language format is straight forward, and deploying the USCL file into 

deployment. 

the Execution Engine is just a matter of copy-paste. 

The composition can then be executed by setting start parameters in 

the Execution Engine, or be called from a client using standard web 

service interface. 

RP08 Secure sharing The platform should MEDISYSTEM Yes There is nothing in the Visual Composition Studio that secures the 

of source files enable the secure Pilot, LOCUS pilot 

composition files, but the Composition Repository requires the use of 

accessing of files (e.g. 

username/password, so as long as the compositions are stored only 

who is allowed to view 

or alter stored 

compositions, who is 

permitted to create 

new versions of 

compositions) 

there the requirement is met.


code 


RP15 Extensibility The platform should Close to project 

enable the 

end, technical 

incorporation of new partners will identify 

service technologies emerging 

as they appear technologies (if 

any) and explain 

how SODIUM 

would 

accommodate them 

RP16 Modularity The platform should 

be modular so as to 

User Forums 

be able to combine Participants will 

the different parts provide input on the 

according to the possibility of using 

different customer SODIUM platform 

needs and to 

modules in 

incorporate 

combination with 

extensions and legacy external tools 

systems used by the available in their 

customers 

environments. 




Yes Particularly the USQL Engine was easily extended to support the 

new W3C recommendation on semantic service description, 

SAWSDL 

Partially Within the project scope no attempt was made to integrate the 

SODIUM tools independently with other commercially available 

tools. 

Nevertheless, the sodium tools have been developed 

independently of each other with standard interfaces. Thus, 

they can be combined in various ways according to the 

customers’ needs 

Table 2: Source of evaluation for ATC’s non-functional requirements


3.2 Assessment of Using the SODIUM Approach 

3.2.1 Qualitative Assessment of Benefits from using the approach 

For the Industrial partner, the Business Benefits from using the SODIUM Platform are those 

pertaining to a Software Developer / Integrator thus associated with the Requirements 

summarized in the previous section. Below we summarise the assessment method, executed 

evaluation activities and results up to M30 of the project: 


� Consultation of the SODIUM Technology to members of four different Business 

Units of the Industrial Partner namely the ERP/Financial Solutions for Enterprises 

Unit; the Banking Solutions Unit; the Digital asset Management Unit and the 

eLearning and Web Services Unit. A series of presentations and focused 

workshops will be held with the aim to collect feedback from each unit. Particular 

differences from different Business Units will be particularly interesting in both 

shaping the final SODIUM outcome and in providing appropriate directions 

towards which type of clients exploitation should focus. 

Related evaluation activities and results during M18-M24: 

o An introductory workshop was held in May 2006 involving the ATC SODIUM 

team and the directors of the four aforementioned Business Units where 

SODIUM in support of SOA development was discussed. 

o The main preliminary feedback received by participants at this stage relate to 

the perceived value of SODIUM with respect to : 

� Increased developer productivity 

� Reduction of development cost 

� Reuse of services 

Furthermore, participants commented on SODIUM potential contribution to 

achieving enterprise level SOA and its anticipated benefits of revenue growth, 

cost reductions, and IT productivity that should be considered as a selling point 

for further exploitation of the approach. This should be preceded by a series of 

pilot projects within organisations which will demonstrate the added value of the 

approach. 

The above activities were introductory, in nature, and did not aim at obtaining 

specific feedback for assessment. More formal activities aiming at practically 

assessing business benefits of the industrial user will be conducted in the last 

Phase of the Project, as detailed below. 

Related evaluation activities and results during M24-M30 



� A follow-up common session was held in mid December 2006 with 

representatives of the four ATC main Business units where the SODIUM platform 

and tools were demonstrated. Representatives are of technical background and 

have extensive experience in working in commercial projects. 

� During this session, following the demonstration, discussion evolved around 

possible enhancements of the SODIUM platform and tools that can further 

improve exploitability of the SODIUM solution in the business environment 

� The ability to store and retrieve compositions so as to reuse them in 

different applications is considered an important feature, thus post 

project end, the role of the Composition repository could be extended to 

provide additional relevant functionality 

� In terms of the Composition Studio, the graphical support in the area of 

transformations of messages between services could be enhanced 

� In terms of the USQL engine, the ability to store query results to the 

Local Dictionary of the Composition Studio is seen as an additional 

feature that can facilitate the developer 

� In terms of using the USCL engine in a commercial environment issues 

related to load balancing and fail over should be addressed Furthermore, 

automatic code generation to support the integration of the compositions 

into applications would provide additional value to the solution 

� Support for p2p services should be extended (beyond JXTA) 

o Finally, the SODIUM methodology is seen as an asset that should be exploited 

when selling the SODIUM solution in addition to the provision of the platform 

and tools 

3.2.2 Problems envisaged in Using the Approach 

As discussed during the sessions organized by the Industrial Partner, the ones involving 

external parties, namely the CIOs of the Fourlis Group, representatives from the Banking and 

Media sector and the ones involving internal to the company parties, the main issues 

identified relate to the demands placed on business by SODIUM in the general context of the 

SOA paradigm such as 

� impact on existing business and IT processes 

� skills needed for developers, architects, and business analysts 

Furthermore, as in all adoption lifecycles, it is expected that initial projects will be 

characterized by increased complexity and cost. Pilot projects in an organisation can pace 

the way for more extensive use of the approach and the tools. Training and support in the 

initial stages of application are considered an important factor for successful project 

completion. 



4. Evaluation of the Results of the LOCUS pilot 

As detailed in Deliverable D5 Part I [3], Locus provides digital map solutions, decision-making 

tools, messaging systems, communication solutions, fleet management systems and patient 

monitoring systems. Our solutions contribute to shortening response times which in turn 

makes for better services to the general public. Life-critical information is obtained, logged 

and documented. This implies more lives saved, reduced suffering and lower costs. 

Emergency crews are offered an improved working environment and the quality and 

efficiency of services increases. 

Locus develops and provides solutions for efficient vehicle fleet management and/or mobile 

users. Locus has also a dominant role within the area of public safety in Norway with 

customers in the health, fire and police services. Locus is also in a strong position in the 

security, assistance and transport segments. The customers are major players in the Nordic 

countries and give us a strategic platform for further growth. 

4.1 Scope of the Pilot 

The Locus pilot will be based on an existing Locus’ software product called TransMed. The 

ambition is to replace parts of the existing program code by service compositions created by 

means of the SODIUM platform. 

Locus represents two user roles in the project: 

1. The one role is that of a user of the SODIUM platform, developing service 

compositions, integrating them into their products and/or (possibly in future) publishing 

compositions as web services, and finally executing the compositions as integrated 

parts of Locus’ software products/applications. 

2. The other role is that of a representative for the Locus products end-users. Locus has 

very good knowledge of its customers’ needs, as the products they develop are used 

in an area with very strict requirements in the crises domain. In addition, end users will 

be involved when possible, e.g. in user seminars and demos. 

4.1.1 Business Requirements 

Why use SODIUM? 

• Encapsulate application logic in services. 

• Be able to create compositions consisting of services 

• Compositions should be stored outside the application so that a composition might be 

modified without having to modify the application 

• Be able to reuse compositions from an existing application 

• Discover services either at design-time or at run-time 

• Be able to integrate services of different standards, including but not limited to web 

services, grid services and p2p services. 


4.1.2 Technical Requirements 

4.1.2.1 Functional requirements 


Major functional requirements for LOCUS include: 

• Unified service discovery: Must be able to discover Web, P2P and Grid services 

quickly and easily. Services can be discovered when the composition is being 

developed (i.e. at design-time), or when the composition is being run (i.e. at run-time) 

• Dynamic service discovery: To dynamically discover services they must be 

adequately described and appropriately published in registries or networks, such as 

UDDI, JXTA, etc. 

• Support of heterogeneous services: Services can be heterogeneous. Should at 

least support web services, grid services and p2p services 

• Service Composition: A composition can be used by more than one application. 

Therefore one must be able to store a composition and then retrieve it at a later stage. 

A composition can be modified on-the-fly 

• Audit: Be able to monitor the execution of a composition. 

• Platform independence: The composition should be able to be run on any platform 

4.1.2.2 Non functional requirements 

• Security: SODIUM must be able to support secure/closed environment for some parts 

of the application. This means that the platform will be part of the closed environment, 

i.e. installed on site. As regards secure service invocation, username/password should 

not be part of composition but should be passed as parameters to the composition. 

Must therefore be encrypted. Must be able to run on secure connection (https). 

• Availability. Preferably 24/7 with 98.5% reliability 

• Extensibility: As new technologies (e.g. new service types) emerge, the SODIUM 

platform should be able to incorporate them. 

• Modularity: It should be possible to install and run the SODIUM components as 

individual modules 

• Robustness: If a service fails, then the system should try an alternative service (if 

available, and configured). If no alternative service has been configured, the system 

should search for alternative services, pick the ‘best’ automatically and run it. The 

system must log that the original service failed, and log which service was used 

instead. The application should be notified, so that it is possible to inform the user that 

an alternative service has been selected. This should be done with no involvement 

from the users. 



• Scalability/Expandability: Must be able to scale and expand the SODIUM platform to 

be able to handle an increasing traffic. 

• Maintainability: If a service has been upgraded, then the old version of the service 

must be available for some time (e.g. a month) in order for the IT personnel to 

upgrade the software to use the new version of the service. This means that the 

system should log any attempt to use an out-of-date service and send a message to 

the responsible personnel about this. 

4.1.3 Pilot Description 

As detailed in Deliverable D5 Part I [3], the Locus pilot will be based on an existing Locus’ 

software product called TransMed. The ambition is to replace existing code with 

heterogeneous service compositions created by using the SODIUM platform. 

TransMed is a fleet management system used by EMS communication centres throughout 

Norway. 

TransMed is designed to transfer information between the EMS communication centres and 

the ambulances. 

A simplified form of a Web Service usage is implemented today: On the TransMed PDA the 

map images are loaded from an Internet server. But to achieve this all code has been put into 

the TransMed source. The goal is to have a unified interface when running Internet services. 

This will be achieved by using the SODIUM platform to create a service composition, and 

then from TransMed using a SODIUM API, execute the composition and return the result 

from the execution to TransMed. 

TransMed today is based on traditional client-server technology, GSM-SMS and GPRS. Most 

of the processing is performed on the server, with only minor GUI processing performed on 

the various clients. 

The SODIUM outcomes will be used by the pilot to: 

• identify which tasks to be solved and their interrelationship (flow patterns) 

• detail these tasks (subtasks) 

• specify QoS requirements (optional, as this information is not provided by most 

available services and due to lack of standards in the three service domains) 

• identify which of these tasks can be executed by services 

• locate suitable services or optionally associate a query with that task 

• ensure correct flow of data 

• execute composition (both design and real time) 

• upload, update, reuse, delete compositions in composition repository 


4.2 SODIUM Features tested (LOCUS) 



The following table presents the main SODIUM platform features tested and validated in the context of the SODIUM pilot as described in 

deliverable D5 Part I [3]. Each of these features is related to one or more specific requirements that have been formulated in D3 part I [1]. 

LOCUS 

Testing 

Code 

SODIUM platform feature Validated in the context of the 

pilot 

L01 Use of the Visual Editor to 

create the visual graph of the 

composite service by the pilot 

team. 

L02 Access the repository to retrieve 

stored services (if any) by the 

pilot team 

L03 Access the USQL engine to 

retrieve available services 

L04 Access the USCL engine to 

execute resulting composition 

L05 Open and save compositions 

both in the local file system and 

in the composition repository 

Done when running the 

composition suite. 


composition repository. 

Done when running the USQL 

engine GUI. 

Done when passing a 

composition converted into USCL 

to the execution engine and when 

invoking the execution engine 

from the pilot application. 


composition suite 

Requirement in D3 

Part I Section 6.2 

RP05, RP13, RM02, 

RM03, RM06, RM10, 

RM11, RM31, RD08, 

RM27 

Req. met Notes 

Yes. 

RM02, RF01, RF02 Yes. Compositions were stored in the 

Composition Repository and retrieved 

again. The compositions could then be 

edited in the Visual Composition Studio. 

RP04, RM13, RD08 Yes Tested from within the Visual Composition 

Studio. 

RE05, RD01, RD02, 

RD03, RD04, RD05, 

RD08 

RM02, RM32, RP08, 

RF01, RF02, RD03, 

RF05, RF06, RF07 

Yes. Executed the composition by starting it 

from within the Execution Engine and 

starting it from a .NET client. 

Yes. Visual Composition Studio has the ability 

to store the composition to the file system. 

The Composition Repository handled the 

storage of the composition in the 

repository.

LOCUS 

Testing 

Code 


pilot 

L06 Use basic control pattern 

Sequence. (Executes activities 

in sequence) 


Parallel Split. (Executed 

activities in parallel) 


Synchronization. (Synchronize 

two parallel threads of 

execution) 


Exclusive Choice. (Choose one 

execution path from many 

alternatives) 

Will be done when composing 

and running the service 

compositions: 

• Create gas dispersion 

plume and map 

presentation 

• Calculate resource 

coverages 

• Chat communication 



composition: 

• Find caller’s position 



composition 




composition 






RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 

RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 

RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 

RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 


Yes. All compositions can be run with the tasks 

executed in sequence. 

Yes Tasks can be executed in parallel, and 

the Execution Engine waits for both to 

complete before execution is resumed. 

Yes. The Execution Engine waits for all tasks 

involved in a parallel thread to complete 

before execution is resumed. 

Yes Is solved by using XPath expression in 

decision node.

LOCUS 

Testing 

Code 


pilot 

L10 Use basic control pattern Simple 

Merge. (Merge two alternative 

execution paths) 

L11 Use advanced branching and 

synchronization pattern 

Discriminator. 

(wait for one among a set of 

activities completes before 

proceedings; if several of the 

activities being waited for are 

executed, the discriminator only 

fires once) 

L12 Use advanced branching and 

synchronization pattern Multiple 

choice. 

(choose several execution paths 

from many alternatives) 

L13 Run query engine, search for 

services and let query engine 

return no results. 



composition 




compositions: 

• Create gas dispersion 

plume and map 

presentation 

• Contact GeoData 

provider 



compositions: 



coverages 

Will be done by running one of the 

compositions with query 

parameters that are not used by 

any service. 





RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 

RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 

RM03, RM06, RM09, 

RM12, RM16, 

RM21, RM24, RM27, 

RM30 

RD01, RD02, RD08, 

RD14, RD23, RD24 


Yes Was tested when getting information from 

stationary phone and mobile phone, only 

one of the tasks was executed and 

execution continued when the task was 

completed. 

Yes Done when we have alternative (web) 

services on a task, 

Yes Several tasks are fired and the result from 

the tasks was inspected before execution 

continued. 

Yes Tested by using name of service that did 

not exist, name of provider that did not 

exist.

LOCUS 

Testing 

Code 


pilot 

L14 Translate VSCL file to USCL file Will be done when composition is 

complete, and we are ready to 

run/test it in the execution engine 

L15 Run composition, defined 

service is not available, use 

alternative service defined in 

composition instead. 

L16 Run composition, defined 

service is not available, run 

query engine to search for 

services instead. 

Will be done by modifying and 

running the Contact geoData 

provider composition and make 

sure that defined service is not 

available. 

Will be done by modifying and 

running the SetupAppointment 

composition and make sure that 

the defined service is not 

available. 






RM15, RM23 Yes Done in the Visual Composition Studio. 

After translation the USCL file was 

inspected and then deployed in the 

Execution Engine. 

RM17, RM18, RM19 Yes Contacted the GeoData provider (by 

getting a map) on two different servers. 

Shut down one of the servers, the map 

was then retrieved from the still running 

server. 

RD08, RD23, RM14 Yes This was done using a MEDISYSTEM 

query, hence not tested by Locus

LOCUS 

Testing 

Code 


pilot 

L17 Run query engine to search for 

services based on specific QoS 

criteria. No services are found to 

meet the specified QoS 

constraints. 

This will be done by modifying the 

find caller’s position composition. 

First, a query based on syntactic 

and/or semantic criteria for a 

specific task in the composition 

will be performed, resulting in 

some matching services. 

Next, the same query will be 

further constrained with the 

addition of tight QoS criteria, 

making sure that the previously 

returned services do not meet the 

requested quality values. 





RD05, RD08, RD23, 

RM14 


Yes Used a 100% availability criterion, which 

was not met by any of the services.

LOCUS 

Testing 

Code 


pilot 

L18 Run query engine, return 

service of type Web Service. 

Invoke the service. 


service of type p2p. Invoke the 

service. 

Done by running compositions: 


• Crate gas dispersion 

plume 

• Determine best route to 

location 

• Contact resource 

coverage provider 

• Contact Geo data 

provider 


• Char communication 

• Transfer clip to server 

• Transfer clip to recipients 





RD01, RD02, RD04, 

RD06, RD07, RD08, 

RD09, RD11, RD23, 

RM14 

RD03, RD07, RD08, 

RD18, RD23, RM14 


Yes 

Searched for the service in the Query 

Engine. The service was then connected 

to a given task. USCL file was created 

and Execution Engine executed the 

composition. 

Yes Locus tested the part of querying for a 

p2p service. This test was successful. 

We were able to discover the p2p service, 

but the result did not contain adequate 

information for invoking it directly. (The 

actual execution of the composition was 

performed in the context of the 

MEDISYSTEM pilot)

LOCUS 

Testing 

Code 


pilot 


service of type Grid Service. 


L21 The USQL Engine will accept a 

USQL query containing USQLsupported 

QoS search criteria 

such as availability, reliability, 

processing time, and security. 

Then, the query will be 

forwarded by the USQL Engine 

to the appropriate service 

registries and / or p2p networks 

where it will be executed. 

The resulting USQL response 

will contain only services 

conforming to the specified QoS 

requirements and the best 

service will appear first in the list 

for the execution engine to 

select and invoke it. 



coverages 

• Determine best route to 

location 

Will be done by running the 

composition 


and make sure that services that 

match the QoS criteria are 

selected. 





RD07, RD08, RD16, 

RD24, RM14 


Yes 

Table 3: SODIUM platform features tested at LOCUS pilot 

Locus tested the part of querying for a 

grid service. This test was successful. 

We were able to discover the grid service, 

but the result did not contain adequate 

information for invoking it directly.(The 

actual execution of the composition was 

performed in the context of the 

MEDISYSTEM pilot) 

RD05, RD08 Yes Done in the Composition Studio by 

invoking the USQL engine with a given 

set of QoS criteria. The Query Engine 

then returned matching services.



The following table summarises validation of the following important features of SODIUM in the context of the LOCUS pilot: QoS, trust & 

security, fault handling/tolerance, dynamic discovery of services and performance. 

Features Validated in the context of the pilot 

QoS QoS offers was defined for some specific services, paying special attention to the alternative ones, i.e. services which are 

functionally similar and expose a similar interface. The QoS parameters were manually annotated in the service descriptions 

with the use of the WS-QoS schema. 

The Query Engine used the QoS values when selecting services. We gradually refined the query until we were left with only 

the services with the best fitted QoS values. 

Trust & Security The ability to use services from specific service providers is important and was demonstrated using three different approaches: 

1. Register /import services from known (and hence trusted) providers into the Visual Composition Studio and thereafter 

use these services in the composition. 

2. Create a reusable query in the USQL engine where a filter can be added specifying which service providers that 

should be excluded or included. 

3. Define a query in the USQL engine that searches for services in specific registries. 

4. Use the Security search criterion of USQL to discover services operating over secure communication channels (e.g. 

HTTPS) 

The first 3 approaches were tested and worked. The last approach was not tested, as all Locus services operate over HTTP.


Fault handling/tolerance Exception 



Tested by closing the web server where a service resided before starting the Execution Engine. The Execution Engine then 

used an alternative service (if available) or returned to the client with an error code if no service was available. 

Timeout 

Added two services as alternative services to a specific task. Set the timeout so low that the first service was not able to reply 

before the time-out. The second service was then executed. 

Dynamic discovery of services A query may be associated with a task in the composition. At run-time the USCL Execution Engine will forward the query the 

the USQL Engine for execution, and the first service on the query result from the query execution will be selected. Then the 

USCL Execution Engine will invoke the selected service. 

This scenario was successfully tested by MEDISYSTEM


Performance 



The USCL ExectionEngine logs all execution times. 

An example of this is displayed below: 

{FindARouteUsingWsAndGrid}Proc_Transform_input_N66115[1.0].0.0:0:WALL 

5 

0.015 

{FindARouteUsingWsAndGrid}Proc_N66213_Alt_2[1.0].CalculateFastestRoute.0:0:WALL 

5 

1.016 

{FindARouteUsingWsAndGrid}GetFastestRouteDescription[1.0].0.0:0:WALL 

5 

2.031 

{FindARouteUsingWsAndGrid}Proc_N66115_Alt_1[1.0].GetFastestRouteDescription.0:0:WALL 

5 

0.984 

{FindARouteUsingWsAndGrid}Proc_Transform_input_N66115[1.0].Task_Transform_input_part_1.0:0:WALL 

5 

0.015 

{FindARouteUsingWsAndGrid}Proc_N66213_Alt_2[1.0].Task_Transform_input.0:0:WALL 

5 

0.016 

{FindARouteUsingWsAndGrid}Proc_Transform_input_N66213[1.0].Task_Transform_input_part_1.0:0:WALL 

5 

0.016 

{FindARouteUsingWsAndGrid}Proc_N66213_Alt_2[1.0].0.0:0:WALL 

5 

.047 

The time is given in seconds with milliseconds as precision. The first transformation took 0.015 seconds to complete. 

There are also time indications for when processes start and end in the same log: 

{FindARouteUsingWsAndGrid}Proc_N66213_Alt_2[1.0].CalculateFastestRoute.0:0:STARTDT 

23 

2007-01-11 13:24:17.585 

{FindARouteUsingWsAndGrid}GetFastestRouteDescription[1.0].CalculateFastestRoute_Alt_2.0:0:ENDDT 

23 

2007-01-11 13:24:18.616 

By subtracting the start from the end the complete execution time can be calculated. 

Table 4: Important features tested at LOCUS pilot

4.3 Evaluation checklists used 


Checklists used in the context of the LOCUS pilot for evaluating the SODIUM tools and 

methodology can be found in Appendix III - Evaluation checklists for the SODIUM tools and 

Appendix IV - Evaluation checklists for the SODIUM methodology. 


4.4.1 Preliminary Assessment –Installation Phase 

This section provides a first assessment of the installation phase of the SODIUM tools at 

LOCUS premises up to Month 27 of the project. 

Details of the LOCUS environment including Operating System, Application Server(s), other 

required software and hardware where SODIUM platform is installed are included. 

The assessment addresses the installation of the SODIUM components Visual Composition 

Suite, USQL engine, USCL engine and Composition Repository. Encountered problems with 

installation of these are described as well as the resolution approach followed where 

applicable. 

4.4.1.1 Description of LOCUS environment in the context of the pilot 

Equipment & internet services 

The following table contains the equipment and services located at LOCUS premises that are 

used for the LOCUS Pilot and for the installation of the SODIUM platform. 

Equipment/Service Name 

Operating 

System 

Role 

Status 

Fortinet Fortigate 100A Fortinet Linux Firewall Operational 

Fiber Optic Internet 

Operational 

Internet Connection Open System 

Owned by 

Locus 

Connections from Local ISP. 

It is the main access to our 

web server to store the 

services 

Fujitsu Siemens 

computer 

(Laptop) 

laptop 

MS Windows 

XP Professional 

Used as a client for the 

Sodium pilot and Visual 

Editor. 

Operational 

No Brand 

Server 

transmed_data 

MS Windows 

Server 2003 

Store IIS Server, UDDI 

Server. 

Operational 

MS Windows Contains the Spider and the Operational 

No Brand Server spiderserver XP Professional 

2002 

ResponseAnalyzer programs 

Table 5: LOCUS equipment and internet services used in the context of the pilot 

Required software 

The following table contains the software and applications that are used in conjunction with 

the LOCUS Pilot and the SODIUM platform 


Software / Application Installed on 

DB MS SQL Server 

2000 

MS IIS Server 5.1 transweb_data 

MS UDDI Server 

ver.5.2.3790 

MS .Net Framework 2.0 

v2.0.50727 

MS SQL Desktop 

Engine (UDDI) 


Related 

databases / 

files 

Transweb_data GAB, TC30 

InternalWS 

ExternalWS 

UDDI, 

transweb_data UDDI 

tone_laptop NA 

transweb_server UDDI 

Spider 2.1 SpiderServer NA 

ResponseAnalyzer 1.0 SpiderServer NA 

Visual Studio 2005 

v 8.0.50727.42 

tone_laptop NA 

Role 

SQL database used for the Web 

services 

Store and publish web pages 

Table 6: Required software for the LOCUS pilot 

4.4.1.2 SODIUM platform tools installation : problems and solutions 


Status 

Operationa 

l 

Operationa 

l 

Publish UDDI information Operationa 

l 

Used by web services created in Operationa 

Visual Studio 

l 

Database used by the UDDI 

Operationa 

publisher 

l 

Route calculation and optimization Operationa 

l 

Equipment coverage Operationa 

l 

Web service development Operationa 

l 

Server environment installation: 

The following table lists the software applications and SODIUM components that are used for 

the Locus Pilot and in order to deploy the SODIUM platform on the server side. Problems 

encountered during installation and solution to these are also included. 

Software / component Computer Status Problem encountered Solution 

Eclipse 3.1 IDE 

tone_laptop 

Operational 

Versioning Install the 

latest version 

transweb_dat 

The web server did not start Problem was 

a 

due to old 

Web Server Apache 

Tomcat 4.1.31 

Operational 

installation of 

Tomcat 4.0 

which kept 

ports 

allocated. 


Tomcat 5.0.30 

tone_laptop 

Operational 

None 

NA 

Java 1.5.0 

transweb_dat 

a 

Operational None 

NA 

SODIUM: USQL Engine tone_laptop Operational None NA 

SODIUM: USCL Engine tone_laptop Operational None NA 

SODIUM: Composition 

Repository 

transweb_dat 

a 


NA 

transweb_dat 

Problem importing SQL scripts Had to give 

SODIUM: Composition a 

password of 

Repository DB (MySQL 

Operational 

user 

4.1) 

sodiumrepo 

instead of


Software / component Computer Status Problem encountered Solution 

root user. 


Engine 

transweb_dat 

a 


Table 7: LOCUS: Installation of SODIUM tools / server side: problems and solutions 

Client environment installation (all on laptop): 

The following table lists the software applications and SODIUM components that are used by 

the LOCUS Pilot and in order to deploy the SODIUM platform on the client side: Problems 

encountered during installation and solutions to these are also included where applicable. 

Software / component Status Problem Solution 

Eclipse 3.1 IDE Operational None NA 

Java 1.5.0 Operational None NA 

SODIUM: Visual Editor 

(Eclipse Plug-in) 


NA 

SODIUM: USQL Engine 


NA 


SODIUM: USCL Engine 



Table 8: LOCUS : Installation of SODIUM tools / client side: problems and solutions 

4.4.1.3 Evaluation of platform-level requirements during the installation 

The following table summarizes the evaluation of SODIUM platform level requirements as per 

D3 Part I during the installation of the SODIUM platform components at LOCUS: 

Requirement Satisfied Assessment at 

installation 

RP03: Platform 

independence 

Details 

YES All installed OK All components were installed 

without issues related to the 

platform. But must bear in mind 

that only the Windows platform 

was selected. System was not 

installed on for instance a Linux 

installation. 

RP11: Security YES All installed OK All the security issues were 

managed outside the SODIUM 

platform such as firewall, use of 

trusted sites and sources. 

RP16: Modularity YES All installed OK Modularity requirement is fulfilled. 

Each SODIUM component was 

installed separately and was able 


NA 

NA



installation 

Details 

to run on its own. 

Table 9: Evaluation of platform level requirements: installation phase at LOCUS 


4.4.2 Assessment related to the use of tools and methodology till end of project 

4.4.2.1 Evaluation of the Visual Editor 



Criterion/Indicator Requirements Measurement tool Data collection method Result Comment 

Heterogeneous 

service types 

Ability to model 

service operation calls 

to Web, Grid and P2P 

services 

Basic file handling Support for create, 

open, edit and print 

Common workflow 

patterns 

Support for sequence, 

parallel split, 

synchronization, 

exclusive choice, 

multiple choice, 

simple merge and 

discriminator 

Documentation Support for basic 

annotation and 

commenting 

functionality 

Standardized 

modeling language 

Should be based on a 

standard modeling 

language 

QoS Characteristics The ability to specify 

QoS properties of 

specific services as 

Manual inspection Operational tests, trials OK Web service, grid service and 

p2p service was successfully 

modelled. 

Manual inspection Operational tests, trials OK 

Manual inspection Operational tests, trials OK Visual Composition Studio has 

the ability to model the common 

workflow patterns, and the 

execution engine can execute 

the USCL created by the 

Composition Studio. 

Manual inspection Operational tests, trials OK All elements have a Description 

column that can be used for 

commenting. 

In addition all elements have 

semantic type definition. 

Manual inspection Comparison with UML2 

activity models 

OK The composition looks like a 

UML2 activity model. 

Manual inspection Operational tests, trials OK QoS criteria can be specified for 

each task.




well as the QoS 

requirements of 

specific tasks 

Basic composition 

constructs 

Support for task 

modeling, service 

operation modeling, 

input/output 

parameters and data 

transformations, start 

and end nodes 

Parameter types Support for defining 

both syntactic and 

semantic types for 

input/output 

parameters. 

Timeouts Ability to specify 

maximum response 

Task hierarchy 

time for a service 

Support for specifying 

sublevels of tasks 

Graphical symbols Should be standardsbased 

Authentication 

constraints 


distinct 

authentications 

requirements for 

different service 

operations within the 

same composition 

Manual inspection Operational tests, trials OK All has been implemented. 

Manual inspection Operational tests, trials OK All types of parameters are 

provided. 

Manual inspection Operational tests, trials OK Can set maximum response 

time for each task. 

Manual inspection Operational tests, trials OK Can create sub compositions. 

Compare with UML2 Comparison with UML2 


Manual inspection Operational tests, trials Not OK This has not been implemented. 

OK




Basic editing 

functions 

Technical evaluation 

Support for 

enabling/disabling 

sticky selection 

4.4.2.2 Evaluation of the USQL engine 

Manual inspection Operational tests, trials OK Sticky selection can be easily 

enabled and disabled. 


Response time < 20 seconds Log files Operational tests, trials OK When searching for services in a 

JXTA network which was not 

available, it took a long time 

before the query timed out. 

However this timeout could be 

modified, and after doing that the 

response time was within the 

requested limit. 

Exception handling Transparency, 

effectiveness 

Security Authentication for 

administrators 

Interviews, Log files Operational tests, trials OK Exceptions and any error 

conditions are logged in the 

standard Tomcat log, easily 

available in the log folder. 

Interviews Operational tests NOT OK Previous versions of the USQL 

Engine used a web service 

interface with authentication to 

administer the server. Current 

version is not using that, and 

management is done manually




and locally with respect to the 

installation, hence the need for 

authentication is limited. 

Availability 24/7 Interviews Operational tests, trials OK The Query Engine can be set up 

on any server, therefore if the 

server is available 24/7 then the 

Query Engine is available. 

Expandability Extensions must be 

easily accommodated 

Interviews Trials OK This refers to the ability of the 

USQL Engine to accommodate 

different types of registries (e.g. 

UDDI, JXTA) and service 

description protocols (e.g. WSDL, 

SAWSDL, WS-QoS) with the use 

of plug-ins. Tested searching for 

Web services, p2p and grid 

services. 

Maintainability On a monthly basis Interviews Trials Not 

tested. 

Scalability 3 registries per query 

within accepted 

response time 

Log files Operational tests, trials Partially 

supported 

Cannot answer this since we are 

not in production. 

Locus maintains only 2 registries 

(1 UDDI server and 1 JXTA 

network). Thus, only 2 registries 

per query were tested. 

Portability Install anywhere Interviews Operational tests OK Installed on Windows platform – 

no problem. The Query Engine 

uses Tomcat, therefore portability 

is ensured.

User acceptance and impact analysis evaluation 




Usefulness Use of the engine 

within the development 

lifecycle 

Ease of 

understanding 

Novice users must be 

able to use the engine 

for service discovery 

Willingness to use Users must be willing 

to use the query engine 

during service 

composition 

Willingness to pay Users must be willing 

to pay in order to use 

the query engine 

4.4.2.3 Evaluation of the overall methodology 

Questionnaires Post-surveys OK The engine is very useful when 

there are a lot of services 

available. It makes it easy to 

search for and select the most 

appropriate service. 

Questionnaires Trials OK Only problem was in 

understanding of the concept of 

ontologies, but developing and 

maintaining an ontology is not 

within the scope of SODIUM. 

Interviews Pre-survey, Trials OK Tool was used when developing 

new compositions in the Visual 


Interviews Post-surveys OK Based on Locus’ need for a 

query engine the answer is no, 

but a larger company with a pool 

of services will be more willing 

to pay for the query engine in 

order to facilitate the search for 

services.



Criterion/Indicator Requirements Measurement tool Data collection method Req. met. 

Abstract and 

concrete 

compositions 

Bottom-up 

composition 

development 

Discovery of existing 

services 

Dynamic service 

discovery 

The ability to specify 

compositions of tasks 

without knowledge of 

existing services, and 

to select specific 

services for the tasks, 

and the ability to 

maintain this 

information in the 

same model 

The ability to produce 

compositions when 

the user knows 

exactly which services 

to use 

The ability to search 

for services 

The ability to define 

run-time queries, 

meaning that the 

search for a matching 

service is performed 

as part of the 

execution 

Manual inspection Operational tests, trials Yes. 

Tasks can be fully specified, partially 

specified or not specified at all. If not 

specified, the execution engine will treat it as 

a black box that does not return any output. 


The ability to drag a specified service into a 

composition is implemented. By doing that all 

details regarding input and output are 

automatically handled. 


Using the USQL Query from inside the 

Visual Composition Studio enables the 

discovery of existing services. 


A query can be solved in the composition in 

the Visual Composition Studio. The 

translated USCL file will contain the query, 

and the Execution Engine will execute the 

query at run-time. 

This was tested in the context of the 

MEDISYSTEM pilot.



Criterion/Indicator Requirements Measurement tool Data collection method Req. met. 

Data 

transformations 

Multiple services per 

task 

Transformation to 

executable format 

Support for defining 

data transformations 

between data objects 

Support to select 

several candidate 

services for a task 

including an execution 

strategy for final 

selection. 

Support for 

transformation 

4.4.2.4 Overall evaluation conclusions 


Data can be transformed on multiple levels: 

1) Output from one task 

transformed 

another task. 

into input to 

2) Input/output to the task can be 

transformed into input/output 

for a specific service that don’t 

have the same service 

description. 


A task can have more than one actual 

service to be invoked at execution time. The 

services will either run in parallel or in series. 

Run, the transformation, 

deploy the result in 

USCL engine and 

execute it 

To summarize, we take a look at the functional and non-functional requirements and conclude: 

Operational tests, trials Yes. 

The composition can be transformed into a 

USCL file which can be deployed and 

executed in the Execution Engine.



Requirement Description of requirement Req. met 

Unified service discovery 

Dynamic service discovery 

Support of heterogeneous 

services 

Service Composition 

Must be able to discover services quickly and easily. Services 

can be discovered when the composition is being developed 

(i.e. at design-time), or when the composition is being run (i.e. at 

run-time) 

To dynamically discover services they must be adequately 

described and appropriately published in registries or networks, 

such as UDDI, JXTA, etc. 

Services can be heterogeneous. Should at least support web 

services, grid services and p2p services 

A composition can be used by more than one application. 

Therefore one must be able to store a composition and then 

retrieve it at a later stage. A composition can be modified onthe-fly 

Yes. The Query Engine can be accessed by 

the Composition Studio at design-time, or 

by the Execution Engine at run-time. 

Locus excercised service discovery only at 

design time. Medisystem made use of the 

dynamic discovery feature too. 

Yes. 

Yes. All SODIUM tools provide support for 

standard SOAP Web services, JXTA P2P 

services and WSRF-compliant Grid 

services. 

Locus tested this requirement by executing 

compositions containing web and grid 

services. The additional use of p2p services 

was tested by Medisystem. 

Yes.




Audit Be able to monitor the execution of a composition. Yes. 

Platform independence The composition should be able to be run on any platform Yes 

Security 

Must be able to support Secure/closed environment for some 

parts of the application. This means that the platform will be part 

of the closed environment, i.e. installed on site. 

Availability Preferably 24/7 with 98.5% reliability Yes 

Extensible 

When new technologies (e.g. service types) emerge, then the 

SODIUM platform should be able to incorporate these 

technologies. 

Modularity Should be possible to install and run SODIUM components as 

individual modules . 

Security Username/password should not be part of composition but 

should be passed as parameters to the composition. Must 

therefore be encrypted. Must be able to run on secure 

connection (https). 

Robustness If a service fails, then the system should try an alternative 

service (if available, and configured). If no alternative service 

Yes 

Yes 

Yes 

Yes. An encrypted password can be sent as 

the value through to the engine as long as 

the service receiving it will be able to 

decrypt it. In addition HTTPS could be used. 

Within the scope of SODIUM, Locus does 

not have any services running over HTTPS. 

However, the underlying communication 

protocol is kept transparent by the SODIUM 

tools. 

Partly. If service fails, then alternative 

service is selected, but if the alternative




has been configured, the system should search for alternative 

services, pick the ‘best’ automatically and run it. The system 

must log that the original service failed, and log which service 

was used instead. The application should be notified, so that it is 

possible to inform the user that an alternative service has been 

selected. This should be done with no involvement from the 

users. 

Scalability/Expandability Must be able to scale and expand the SODIUM platform to be 

able to handle an increasing traffic. 

Maintainability If a service has been upgraded, then the old version of the 

service must be available for some time (e.g. a month) in order 

for the IT personnel to upgrade the software to use the new 

version of the service. This means that the system should log 

any attempt to use an out-of-date service and send a message 

to the responsible personnel about this. 

service fails, a search is not performed 

automatically. 

Yes. 

No. The Execution Engine does no such 

logging. This feature would have to be 

implemented in the actual services. 

This is beyond the scope of the SODIUM 

platform functionality

4.4.3 Meeting Key Business Requirements for LOCUS 



In this section we summarise how the key business requirements are met for LOCUS through the use of the SODIUM platform and tools 

Business requirement Req. 

met 

Comment 

Encapsulate application logic in services Yes In addition to just running services it is possible to create decision nodes and 

transformation of data. 

Be able to create compositions consisting of Yes 

services. 

A composition contains tasks, and each task can invoke one or more services. 

Compositions should be stored outside the 

application so that a composition might be 

modified without having to modify the application 

Be able to reuse compositions from an existing 

application 

Discover services either at design-time or at runtime. 

Be able to integrate services of different 

standards, including but not limited to web 

services, grid services and p2p services. 

Yes The composition is translated into a USCL file which is deployed in the Execution 

Engine. The composition can be modified and redeployed in the Execution Engine 

without the client application’s “knowledge”. 

Yes Deployed USCL files can be used by any client. 

Yes Services can be discovered by using the integrated USQL dialog in the Visual 

Composition Studio or directly through the USCL Engine at runtime, provided that a 

USQL query has been assigned to a task in the composition. 

Locus tested discovery only at design time. Runtime service discovery was 

successfully tested by Medisystem. 

Yes There is support for web services, grid and p2p in the Visual Composition Studio, 

Query Engine and the Execution Engine. New types of services can be implemented 

by creating plug-ins to the USQL Query Engine and the USCL Execution Engine. 

Locus tested this requirement by executing compositions containing web and grid 

services. The additional use of p2p services was tested by Medisystem.


4.4.4 Qualitative Benefits from using the SODIUM Approach 

Locus is the Norwegian market leader in IT solutions for logistics, fleet management, 

communication, registration and geographic decision tools. Locus develops mobile 

applications and has a very strong position within its market areas. Its goal is to be the 

leading supplier of mobile applications in the Scandinavian markets for transportation, 

emergency, security and the military. 

The Key Business Benefits from Using the SODIUM Platform are described in Section 5.4.3 

above. 

The Assessment of whether these benefits are indeed obtained by using SODIUM in the 

environment of LOCUS will be ascertained in a Qualitative manner by recording the 

experiences of different functions in LOCUS that were involved in the Pilots and by also 

obtaining feedback from the Management. 

The Qualitative feedback was based on a presentation/discussion/brainstorming method 

approach. 

A preliminary assessment up to M24 of the project revealed the following: 

Locus has during the last 10 years entered into mainly two business areas: 

• Public Safety including 

o Governmental Emergency centres and life saving activities 

o Private Assistance companies 

o Private security and safety companies 

• Transportation industry 

o Distributors of goods 

o Transport companies 

o Waste handling companies 

These customers are mainly situated in Norway, but an increasing number of customers 

are now also coming from the other Nordic countries Sweden, Denmark and Finland. In 

all these markets there are needs and acceptance of offering services of various kinds. 

Locus therefore has built up a service platform which will host reusable services. This also 

fits very well into the company’s SOA strategy in addition to the SOA strategy we see our 

customers have. 

The possible services to be developed may be primitive services or services composed of 

other services. In addition to opening a new market in the service domain, this way of 

working will improve the development process of Locus software products by integrating 



re-useable, and possibly also adaptable, services in them. The SODIUM platform will 

ease the development of new services by offering the possibility of composing, 

discovering and executing re-useable and adaptable compositions consisting of 

heterogeneous services in a unified way. This is a great advantage compared to having to 

write the compositions and the peculiarities of each service type in the application code. 

Also, by encapsulating the composition content, the internal structure of the composition 

may change over time without affecting the application in any significant way as long as 

the signature doesn’t change of course. The usage of high level tools would make it 

possible to very efficiently produce and maintain existing and new services. The expected 

increase in efficiency would be between 25 – 50% of normal workload. 

The SODIUM project will enhance the focus on service provisioning internally within 

Locus as a service constructor and externally as a service provider in wider and 

expanded future market which more and more are focused on SOA. 

Assessment till end of the project revealed the following: 

The expected increase in efficiency is below 25-50% of normal workload. Mainly because 

using the VSCL/USCL language introduces the need to create transformations between 

all tasks in the composition. Standard transformation can easily be done using an Xml 

tool (for instance Stylus Studio), but transformations involving 2-to-1 transformation 

introduces the need for doing some hand-coded transformation and this can be quite 

tiresome. In addition, the XSLT will depend upon the names given to the output tags that 

act as input to the transformation, meaning that if the names are changed, the XSLT 

must also be changed. 

The quality of the platform must be increased in terms of giving more detailed error 

messages in the Execution Engine. In the present version, some error messages lack 

detailed information making it hard to figure out what the problem is. Thus a good deal of 

time is spent figuring out what the actual problem is. 

In addition the Eclipse platform is using a substantial deal of memory and the platform 

therefore has to be rebooted from time to time. 

More details regarding these issues can be found in section 4.5 Lessons Learned, 

Recommendations and Suggestions for improvement for commercialization. 

An estimate of the efficiency increase is therefore closer to the low range of 20-25%. 

4.4.5 Cost of Using the SODIUM Approach 

The Costs associated with introducing SODIUM into a business environment will be studied 

and quantified: 

Such costs will include: 

a) Thorough Training of all Personnel involved and probably third parties that 

participate in Software Development 


) Acquisition of Tools etc. 


c) Development of Quality Procedures 

d) Minor adaptations of Technical Documentation 

Further Costs may be spotted during the operation of the pilots and will reported in 

subsequent versions of this document (M30). 

These Costs will be quantified with respect to both the size of the Software Project where 

SODIUM will be used and the degree of third party involvement. The results will be used in 

order to quantify the size of benefits that an industry should expect in order that using 

SODIUM becomes profitable. 

Of course, the effects of diversification, i.e. the ability to offer services that cannot be 

effectively and efficiently composed in another manner will not be subject of a quantitative 

analysis. 

Below we present related costs in term of effort. It should be noted that these are all initial 

costs, that is the cost the first time a user performs the activity. 

Activity Cost (p-days) 

Training in using the tools 1 

Training for supporting the tools 2 

Installation of tools 1 

Customization of tools 

Involving setting up the correct Java version 

1 

Create composition 

Create a medium complex composition with sub compositions, alternative 

services on at least one task, use of decision node, split/merge. 

Query for services 1 

Execute compositions 

This assumes that the execution is not successful at first try, and therefore 

needs some debugging. 

Integration 

Including transforming from VSCL to USCL, using the embedded query 

engine in the Composition Studio, and deploying the USCL file in the 

execution engine. 

Transformation 

Meaning the work needed when transforming output from one task to input to 

another task in the Visual Composition Editor 

Integration with client application 

Includes the coding that needs to be done to start the execution engine, and 

retrieving the results. 


3 

2 

1 

1 

1

4.4.6 Cost Benefit Analysis 


Working with the SODIUM pilot, Locus is focusing on crisis management in the Pubic Safety 

market. In this market there is a need and acceptance of services of various kinds. 

Locus therefore sees the possibilities and considers development of reusable services as a 

promising future market place. The possible services to be developed may be primitive 

services or services composed of other services. 

In addition to opening a new market in the service domain, this way of working will improve 

the development process of Locus software products by integrating re-useable, service 

compositions in them. 

The SODIUM platform will ease the development of new services by offering the possibility of 

composing, discovering and executing re-useable and adaptable compositions consisting of 

heterogeneous services in a unified way. This is a great advantage compared to the 

traditional method of having to write the compositions and the peculiarities of each service 

type in the application code. Also, by encapsulating the composition content, the internal 

structure of the composition may evolve over time without affecting the application in any 

significant way as long as the composite service’s signature does not change. 

The SODIUM platform will internally in Locus enhance the focus on service provisioning and 

externally enhance Locus as a service provider in a market which is more and more focused 

on SOA. 

Cost: Hours Rate One time cost Yearly cost 

Equipment 

1 new server for the Execution engine 3 000,00 € 0,00 € 

1 new server for the Query engine 3 000,00 € 0,00 € 

Installation of the SODIUM platform 3 150 €/hour 450,00 € 0,00 € 

Training: 

10 employees trained in using the platform 75 150 €/hour 11 250,00 € 0,00 € 

2 employees trained in supporting the 

platform 10 150 €/hour 1 500,00 € 0,00 € 

Other costs: 

Lost time caused by less efficiency during 

startup 58 500,00 € 0,00 € 

Lost time caused by less efficiency during 

startup 57 000,00 € 0,00 € 



Cost: Hours Rate One time cost Yearly cost 

Change in existing code 40 150 €/hour 6 000,00 € 

Total cost: 140 700,00 € 

Benefit: 

20% improvement of efficiency 20% of 

1700hours 150 €/hour 51 000,00 € 

Improved possibility of differentiating services 

for the customers 10 000,00 € 

Re-use of code across platform boundaries 10 000,00 € 

Cost reduction caused by maintenance only 

performed at central site 5 150 €/hour 750,00 € 

Cost reduction caused by central update of 

basic data 5 150 €/hour 750,00 € 

Cost reduction caused by reduced number of 

local installations. 3 150 €/hour 450,00 € 

Total benefit 72 950,00 € 

Payback time: 140 700,00 € / 72 950,00 € = 1.93 of a year = approx. 1 year 11 months 




4.5 Lessons Learned, Recommendations and Suggestions for improvement for commercialization 

The following table summarises lessons learned in the context of the LOCUS pilot with respect to organisational changes introduced by 

SODIUM and training needed related to the use of SODIUM platform and tools 

Issue Comment 

Organizational 

changes 

The SODIUM approach will not imply organizational changes. 

Quality procedures are affected, because the person that creates the compositions must be aware of all uses of the 

composition so that nothing is compromised when a new version is created. 

Training There are two types of users: the composition designers and the client application developers. They will both need at least 

one day of training in order to master the platform. 

The following table summarises lessons learned in the context of the LOCUS pilot with respect to the use of the SODIUM platform and 

tools 

Tool Issue Comment/Solution 

Composition 

Studio 

Usability The Composition Studio is easy to use. 

Composition 

Studio 

Composition 

Studio 

Transformation of data. Between each task in a composition we need to have transformations because the output format from one task does 

not match the input format to the other task. Creating all these transformations are quite tiresome and is not 

something that needs to be done when using traditional .NET application development tools. The transformation is 

set up in the Composition Studio, but the user needs an Xml tool to be able to create the transformations. 

When creating transformations that have two inputs, additional code for handling xalan has to be included in the 

XSLT, and the transformation requires that the name of the input tags are used in the XSLT, meaning that if the name 

is changed on a tag, the transformation will not work. 

Automation Transformation of data. This is done using an external XML tool. Transformations from 2 to 1 would be simpler to 

handle if the Composition Studio was able to set up the transformation.


Composition 

Studio 

Composition 

Studio 

Composition 

Studio 



Task execution. In the Composition Studio one has the opportunity of selecting to execute the task or the sub-composition, but if a 

sub-composition exists, it will always be executed no matter what is selected. 

Defined types. Input to the overall composition needs to be specified in the local dictionary in the Composition Studio,and therefore 

the user has to create a file containing this information and import it into the local dictionary. It would be better to be 

able to define types within the Composition Studio instead of having to import them. 

Transformation on a 

service within a task. 

The Composition Studio gives error messages when the user wants to perform a transformation for a service on a 

specific task: 

The reason is that the language is set to Java. If this was set to XSLT then the errors would disappear.




The Error view should be removed – it is not displayed when performing transformation between tasks. 

Composition 

Studio 

Composition 

Studio 

Composition 

Studio 

Transformation. Deleting a service on a task containing transformations: Seems like the XSLT remains in the VSCL file – it should be 

deleted. 

Import of service 

descriptions. 

Showing types. 

Problems when a service description imported into the local dictionary is deleted: 

This question is given each time the Composition Studio is started, even when Yes has been selected. 

The update procedure is not optimized, and it is not simple to update a WSDL reference in the Local Dictionary 

because of error messages given from the Studio. 

In the first versions of the Composition Studio, the developer was not able to see which service description the 

different types came from:




This made matters complicated if several services had the same types. 

This has been improved in the latest version of the Composition Studio by setting the name of the service description 

in brackets after the type name:


Composition 

Studio 

Service operation 

timeout. 



In the Composition Studio the user can set the timeout for services when running alternatives in series or parallel:


Composition 

Repository 



This feature would also be useful when only running one service. The feature does not work in the current version; 

the timeout is always 5 minutes. 

Usability and integration The Composition Repository is easy to use. It is an additional tool (not included in the SODIUM description of work) 

that has been conceived to work in a standalone manner. In the future, tighter integration with the Composition Studio


would bring additional value. 

Execution 

Engine 

Execution 

Engine 

Execution 

Engine 

Execution 

Engine 



Execution log The Execution Engine gives a good overview of what happens when the composition is executed, mostly with 

detailed error messages. 

Delivery of results 

during execution. 

When executing the composition in the execution engine, results are delivered back to the client as soon as they are 

available. This means that the client can start processing the results before the complete composition has been 

executed. 

Parallel execution Parallel execution did not work in the first versions of the USCL so everything had to be run in series. The current 

version handles this requirement. 

Display of compositions 

in the execution engine. 

The generated USCL file has a lot of ”entry” points, and they mess up the information when asking the Execution 

Engine to show which compositions are available: 

{Demonstration}Demonstration[1.0] 

{Demonstration}Proc_N65914_Alt_1[1.0] 

{Demonstration}Proc_Transform_input_N65914[1.0] 

{Demonstration}GetCallerPosition[1.0] 

{Demonstration}GetCallerInfo[1.0] 

{Demonstration}Proc_Transform_output_N65914[1.0] 

{Demonstration}GetSubscriberAddress[1.0] 

{Demonstration}Proc_Transform_input_N66299[1.0] 

{Demonstration}GetSubscriberName[1.0] 

{Demonstration}Proc_N66299_Alt_1[1.0] 

{Demonstration}Proc_Transform_output_N66299[1.0] 

The only information that should have been displayed was: 

{Demonstration}Demonstration[1.0] 

Execution Deployment. When deploying a composition in the Execution Engine all services must be available. This will not always be the




Engine case, so it should be possible to deploy a composition at any time. 

Query Engine Usability and integration The query engine is well integrated in the Composition Studio and is easy to use. 

Query Engine Automation of tasks A query has to be generated from scratch each time a new task is created. Some of the parameters in the query will 

be default parameters (Ontology to use, provider etc), and it should be possible to store these parameters for later 

usage.


Query Engine Display origin of 

services 



When returning the query result, the URL to the wsdl is displayed. It would also be feasible to display the URL to the




actual service, especially since the wsdl URL resides in a UDDI register which gives no indication to where the actual 

service is. 

4.5.1 Recommendations for future enhancement 

The following table summarises recommendations from the LOCUS pilot for future enhancement with respect to the SODIUM platform 

and tools. 

Tool Issue Issue, Comment/Solution 

Composition 

Repository 

Composition 

Studio 

Composition 

Studio 

Composition 

Studio 

Composition 

Studio 

Composition 

Studio 

Integration Although an additional tool conceived to work in a standalone manner, there should be tighter integration of the 

Composition Repository with the Visual Composition Studio. 

VSCL to USCL 

transformation. 

If possible implement more error checking when performing the transformation. Should not be able to create the 

USCL file if there are errors in the composition. This is possible in the current version. 

Copy composition. It would improve the Composition Studio if it was possible to copy a composition. It can be done manually today, but 

references in the uml2 file still point to the old composition which leads to transformation to USCL begin ruined. 

Transformations. Transformation of data, especially 2-to-1 transformations should be handled by the Composition Studio. 

Initial and final node. When creating a composition, the ”Initial” and “Final” node should be added to the composition as a default. 

Combination of 

services. 

The scenario is as follows: 

We would like to run either the method (GetMapMethod1), (GetMapMethod2) OR (ConvertData + GetMapMethod3). 

The services should be run in serial mode, if GetMapMethod1 does not reply, then GetMapMethod2 is started, and if 

GetMapMethod 2 does not reply ConvertData and GetMapMethod3 is started. 

The requirement is to be able to have more than one service being viewed as an autonomous service by the



Composition 

Studio 

Selecting a service on 

a task. 



When creating a task manually in the Composition Studio the service name is not displayed in the same manner as in 

the local dictionary: 

The Local dictionary uses the name that was given to the description when it was imported. When selecting services 

only the service name is given:


Composition 

Studio 



This makes it hard to see which service is selected because we might have the same name for several services (the 

name Service is the default name given when creating a .Net Web Service). 

It would be better to use the same display value as the one used in the local dictionary. 

Naming of task Name of composition and task cannot be the same. 

If the same name is given both to the composition and the task as in the figure below, the composition will fail in the 

execution engine.


Composition 

Studio/Execution 

Engine 

Input parameters 

missing 



There is no error message in the execution engine, so it’s hard to know why the execution failed. 

The composition studio should therefore not allow the same name used by both composition and task. 

When a web service does not have any input parameters, then the composition can not be executed in the Execution 

Engine. Therefore when importing service descriptions in the Composition Studio, it should be checked if the service 

has input parameters, and the Execution Engine should be able to execute a service with no input parameters.


Execution Engine Deployment. 

Execution Engine Error messages in 

execution engine. 

Execution Engine Eclipse/Java resource 

usage. 



If a (web) service used in a composition is not available when the composition is deployed, an error message like this 

is displayed: 

It would be better if the engine could tell the user the reason why it failed. 

Most of the error messages are descriptive, but some especially the ones related to transformations should have 

more detail. E.g.: when there is an error in a XSLT file, this is reported, but the contents of the XSLT is not displayed, 

so therefore it’s not always easy to find error. 

Running the Execution engine in Eclipse/Java seems to consume a good deal of memory when the engine has been 

running for a while. 

When redeployment occurs frequently the OutOfMemoryException is thrown. 

It should be possible to do frequent redeployment without having these problems. 

Execution Engine Composition does not When a client calls the execution engine and asks it to run a non-existing this error message is returned to the client:


exist. 

Exception while Starting Process. 

Query engine 

Query engine 

Query engine 

Query engine 



It would be better if the message explained why there was an exception. This is logged on the Execution Engine side, 

and should therefore be passed to the client. 

Display registries In the current version it is not possible to see which UDDI (and other registries) that will be used when searching. 

They are configured in the Tomcat server. It would be feasible to see the registries. 

Available registries It would be feasible to see which of the registries are available, and in addition be able to select in the USQL Dialog 

which registries to use when searching. 

UDDI details When the result from the query is returned, then information about which registry (UDDI, etc) the service was found in 

should be displayed. 

Selection of services When the result from the query is returned, then it should be possible to select which services to use in the 

composition by selecting the appropriate rows and select Save. I the current version all services not of interest have 

to be deleted before the user can press Save.


5. Evaluation of the Results of the MEDISYSTEM pilot 

5.1 Scope of the Pilot 

5.1.1 Business Requirements 

As described in D5 Part II [4], Medisystem (S.C. Medisystem HOSPITAL S.A) is the first 

private hospital in Romania and it is licensed to perform medical and hospital services. 

Information Technology is at present the means to provide the backbone for business 

support and leveraging of various systems information and also a key factor to realizing 

future benefits for the Hospital. 

As a Private Healthcare organization and as a company committed to technology evolution, 

Medisystem is constantly looking to Improve existing capability by integrating heterogeneous 

information systems with existing business partners and then extending resulting solutions 

with future business partners; Make publicly available part of internal information to be 

accessed by our patients; Improve health service provided by the hospital by facilitating 

medical and clinical information exchange with and between our doctors; Develop and test 

tools as to be use in very near future for similar and growing business needs; Assist in 

formulating a roadmap for the introduction of new technologies in the Hospital environment 

In this context Medisystem is investigating the opportunities offered by service oriented 

development. As a direct consequence, the main objectives of MEDISYSTEM in the 

SODIUM project have been: 

- Use or develop different types of available services such as Web, P2P, and Grid 

services 

- Explore the ability to combine “internal services or private services” with publicly 

available services. This will be important for a Company within a large Multinational 

Group as it may have access to software and services from all members of the Group 

and their providers; this will lead to either a maximization of capabilities or a reduction 

of cost or both 

- Experiment, test and adopt solutions that will enable Medisystem Hospital to efficiently 

and effectively develop applications from heterogeneous services in order to respond 

to requirements that are specific to a fast evolving and very dynamic environment as 

the Healthcare. 

- Prepare for the new developing market of IT services and test the capabilities to easy 

use and integrate the emerging services with existing capabilities. 

- SODIUM is expected to accommodate simple discovery of new services and fast use 

of them in respect with our specific needs 

The SODIUM platform has been: 



• used for composing domain specific service compositions 

• used for executing heterogeneous services in a homogenous, unified manner 

• operated within a controlled environment as most the service providers are trusted 

partners (business contractual agreements have been signed) 

Why use SODIUM? 

• Allows to dynamically discover new services 

• Allows to easy create new compositions and change existing ones 

• Allows to use different type of services (WEB, P2P, GRID) (publicly available or 

private) and be prepared for new types 

• Permit reuse of a composition into new one 

• Allows the monitoring of the execution of compositions through provided logs 

• Use of graphical (UML) composition tools permits to more accurately reflect the 

business needs into compositions 

• Perfectly fitting the medical environment described as having increased demands of 

exchanging various types of data and having a fast changing rate of the business 

requests. 

5.1.2 Technical Requirements 

5.1.2.1 Functional requirements 

• Permit unified service discovery of heterogeneous types of services (i.e. Web, P2P, 

and Grid services) 

• Enable dynamic discovery of the services to be used both at design-time and at runtime 

• Enable the reuse of a composition into a new one. Need for storage of the 

composition 

• Enable simple and suggestive implementation of workflows into composition by 

use of state of the art composition tools 

• Enable fast changes of a composition and deployment 

• Support tracking of the execution of a composition 

• The composition should be able to run on most common platforms 

5.1.2.2 Non functional requirements 

• Outside the platform security: the platform is to be secured by installing it on a 

secured/controlled environment 

• Platform security: 

• Log on information to be externally passed as parameters to the composition 

• Provide use of external methods of data encryption 

• Secure the data transfer on secure connection (HTTPs). 

• Availability: as of 99 % from 24/7 

• Reliability: as of 98% 



• Extensibility: the platform should be extensible in order to easily accommodate new 

service types and their related technologies, as they emerge. 

• Modularity: Should be able to install and run SODIUM components as individual 

modules 

• Performance: Response time of the platform shall be within 10 to 30 seconds 

• Scalability/Expandability: SODIUM platform should be able to handle increased 

traffic and number of services 

• Maintainability: The SODIUM platform should support older versions of services by 

allowing parallel availability of both versions for a chosen time period 

5.1.3 Pilot Description 

As detailed in Deliverable D5 Part II [4], the pilot is focused on servicing various actors such 

as internal or external doctors, receptionists, private or insured patients. This is usually done 

by the hospital web pages that are static and contains sections for patients and for doctors. 

The pilot provides a new dynamic web page containing sections that can provide for them up 

to date information stored in local databases and unavailable for them or new facilities such 

as online appointment or checking the status of an insurance plan etc. 

In the doctor section the pilot can provide information on the medical procedures and 

medication for each of doctor’s patients and for each patient’s episode. Also the doctor can 

request medical information on drugs or request for a second opinion to a remote doctor that 

is available on line. 

In the patient section someone can request for an appointment for a specialty or a doctor at a 

desired date and time, after consulting the page presenting in real time the doctor availability. 

After making online appointments the process is ended by a confirmation made by 

receptionist. For patients that have been previously registered in the hospital database with 

at least one medical episode, the pilot can provide medical information of each of his/hers 

episode. 

In the section reserved for the personnel of the hospital the pilot provides the possibility of 

confirming or canceling a request for an appointment together with checking with the 

insurance company the status of the insurance plan for an insured patient and also sending 

for approval a request containing specific medical procedures for the same patient. 

The SODIUM platform and tools are used in the context of the pilot to: 

• Develop and test compositions corresponding to each of the identified business 

processes 

• Reuse existing web, grid and P2P services owned by Medisystem or business 

partners 

• Specify QoS requirements (optional when these are available) 

• Identify which of required tasks cannot be executed by services and move them at the 

application level 

• Redesign quickly the tasks to reflect new requirements and resources 

• Locate and use suitable services or optionally associate a query with that task 

• Execute compositions to include multiple calls 



• Upload, update, reuse, delete compositions in composition repository 


5.2 SODIUM Features tested (MEDISYSTEM) 



The following table presents the main SODIUM platform features tested and validated in the context of the SODIUM pilot as described in 

deliverable D5 Part II [4]. Each of these features is related to one or more specific requirements that have been formulated in D3 part I 

[1]. 

Medisy 

stem 

Testing 

Code 

SODIUM platform feature To be validated in the context 

of the pilot 

M01 Use of the Visual Editor to 

create the visual graph of the 

composite service by the pilot 

team. 

M02 Access the repository to retrieve 

stored services (if any) by the 

pilot team 

M03 Access the USQL engine to 

retrieve available services 



Yes RP05, RM01 RM03, 

RM17, RM19, RM09, 

RM21 

Yes RP08, RF01, RF02, 

RF06, RF05 

Yes RP04, RM13, RM14, 

RD01, RD05, RD06, 

RD07, RD08, RD09, 

RD10, RD11, RD12, 

RD13, RD14, RD16, 

RD17 RD18, RD20, 

RD23 


Yes 

Yes The repository is available as a web page 

that can be accessed remotely. 

Yes The USQL engine is available as a web 

service that can be accessed remotely

Medisy 

stem 

Testing 

Code 



M04 Run query engine, return 

service of type WEB Service. 



service of type P2P. Invoke the 

service. 


service of type GRID Service. 


Done by running the following 

compositions: 

• Online Appointment 

• Access patient file 

Personal Doctor accessing patient 

file 


compositions: 

• Doctor consulting specialists 

for second opinion 


compositions: 

• Search & retrieve drug related 

statistics 





RE04, RE05, RE07, 

RE12, RE13, RE14 

RP17, RD07, RD12, 

RD01 


Yes Tested both at design time and runtime 

Yes Tested only at design time 

RP18 , Yes Tested only at design time

Medisy 

stem 

Testing 

Code 



M07 Use basic control pattern 

Sequence. (Execute activities in 

sequence) 

M08 Use basic control pattern 

Parallel Split. (Execute activities 

in parallel) 

M09 Use basic control pattern Simple 

Merge. (Merge two alternative 

execution paths) 


compositions: 

• Online appointment 

• Access patient file 

• Personal doctor accessing 

patient file 


compositions: 

� Personal Doctor accessing 

patient file 


compositions: 

� Personal Doctor accessing 

patient file 

M10 Translate VSCL file to USCL file Performed while producing the 

USCL file out of the composition 

graph that will be developed with 

the Visual Composition Suite 






RM03 Yes Done at design time and in the pilot 

RM03 Yes Used at design time 

RM03 Yes Done at design time and in the pilot 

RM23 Yes Attention need to be paid when mixing 

local dictionaries

Medisy 

stem 

Testing 

Code 



M11 Open and save compositions 

both in the local file system and 

in the composition repository 

M12 Access the USCL engine to 

execute resulting composition 

Done by running the all 

compositions 

Done by running the compositions 

created through the steps 

described above 






RM02, RM32 Yes Attention need to be paid to save the vscl, 

uml2 files together with the local 

dictionary 

RE05 Yes The USCL engine presents two interfaces 

of accessing and running the 

compositions at the API and Web level. 

The API interface is working properly. 

Error when accessing the web interface. 

Table 10: SODIUM platform features tested at MEDISYSTEM pilot 

The following table summarises validation of the following important features of SODIUM in the context of the MEDISYSTEM pilot (as 

described in deliverable D5 Part II [4].): QoS, trust & security, fault handling/tolerance, dynamic discovery of services and performance 


QoS • Special attention was paid in annotating the service descriptions with the use of the WS-QoS schema 

• The QoS parameters were manually annotated in the service descriptions, as there is a lack of external broker tools in this 

area. 

• The Query Engine provides easy to use mechanisms to query and select services based on QoS search criteria. 

• The result of running a query based on QoS was as expected.




Trust & Security • The process of importing services into Local Dictionary is a manual process. The user decides if a service from a provider 

is to be trusted or not 

• The USQL dialog provides user-friendly and powerful mechanism to filter services according to provider name. 

• Search for services can be directed toward trusted registries through manual configuration of the USQL Engine. 

• The USQL Engine provides elementary support in searching for secure services. 

• Security was ensured by using the Execution engine behind the local firewall. 

Fault handling/tolerance • Exceptions- Execution Engine returns an error code when exceptions occurred 

• Timeouts – The Composition Studio allows to set Timeout and the Execution Engine take into consideration this parameter 

when executing the composition 

Dynamic discovery of services • The Composition Studio allows to associate a USQL query with a task. 

• The Execution Engine forwards the query the USQL Engine. From the list of services returned by the USQL Engine the 

Execution Engine will invoke the first one in the list 

Performance • The Execution Engine logs execution times (start and stop) for all processes 

• The Execution Engine has been heavily loaded with multiple requests from 4 users at the same time. No decrease in 

performance was noticed 

Table 11: Important features tested at MEDISYSTEM pilot

5.3 Evaluation checklists used 


Checklists used in the context of the MEDISYSTEM pilot for evaluating the SODIUM tools 

and methodology can be found in Appendix III - Evaluation checklists for the SODIUM tools 

and Appendix IV - Evaluation checklists for the SODIUM methodology. 


5.4.1 Preliminary Assessment –Installation Phase 

This section provides a first assessment of the installation phase of the SODIUM tools at 

MEDISYSTEM premises up to Month 24 of the project. 

Details of the Medisystem environment including Operating System, Application Server(s), 

other required software and hardware where SODIUM platform is installed are included. 

The assessment addresses the installation of the SODIUM components Visual Composition 

Suite, USQL engine and USCL engine. Encountered problems with installation of these are 

described as well as the resolution approach followed where applicable. 

5.4.1.1 Description of Medisystem environment in the context of the pilot 

Equipment & internet services 

The following table contains the equipment and services located in Euroclinic Hospital that 

are used for the Medisystem Pilot and for the installation of the SODIUM platform. 


Operating 

System 

Role 

Status 

Server Dell PowerEdge 

2600 Dual Processor 

Medtrak-srv 

MS Windows 

Server 2003 

Store Medtrak medical 

application, its DB and 

medical related files 

Operational 

Server Dell PowerEdge 

2600 Dual Processor 

Platinum-srv 

MS Windows 

Server 2003 

Store SQL Server and DB for 

the Web services 

Operational 

Store IIS Server, UDDI Operational 

Server HP ProLiant 

ML350 Single Processor 

Websrv 

MS Windows 

Server 2003 

Server, TomCat Server to act 

as Web Server for the 

Medisystem’s Web Services 

and compositions. 

PC Dell Optiplex GX270 Isarom 

MS Windows 

Server 2000 

Firewall Operational 

Laptop Computer HP 

NC6120 

LaptopIT 

MS Windows 

XP Professional 

Acts as client computer and 

for development of new 

compositions. 

Operational 


Operational 


Owned by 

Medisystem 

Connections from Local 

ISPs. Is the main access to 

our web server to store the 

services 


Owned by 

MedCenter 


Connections from Local 

Operational 



Internet Connection RDS 


Operating 

System 

Owned by 

Interamerican 

Role 

ISPs. It will provide external 

access to MedCenter Web 

Services. 

VPN through Fiber Optic 

Internet Connections from 

Local ISPs. It will provide 

external access to 

Interamerican Web Services. 


Status 

Operational 

Table 12: MEDISYSTEM equipment and internet services used in the context of the 

pilot 

Required software 

The following table contains the software and applications that are used in conjunction with 

the Medisystem Pilot and with the SODIUM platform 

Software / Application 

DB Cache Server 

Medtrak Application 

DB MS SQL Server 

2000 

Transfer Meddata VB 

application 

Installed 

on 

MedtraksrvMedtraksrv 

Platinum 

-srv 

Medtraksrv 

MS IIS Server 6.0 Websrv 

MS UDDI Server 

ver.5.2.3790 

Related 

databases / files 

Meddata & 

Medtrak 

Meddata & 

Medtrak 

Medtrak, 

Canamed & 

SODIUM 

Cache Medtrak & 

SQL Medtrak 

InternalWS, 

ExternalWS, 

UDDI, UDDIpublic 

Websrv UDDI 

MS ISA 2000 Server Isarom NA 

MS .Net Framework 2.0 

ver.2.0.507727.42 


Engine (UDDI) 

Websrv NA 

Websrv 

UDDI,Sodiumrep 

o 

Role 

Store in Cache type of DBs patient, 

care provider and hospital data 

Interfaces and routines to get limited 

access to Cache type of DBs 

Store in intermediary SQL DBs data 

that is used for the Web services 

Application developed to 

automatically or manually transfer 

data from the Cache Medtrak DB to 

SQL Medtrak DB 

Store and publish web pages 

Status 

Operationa 

l 

Operationa 

l 

Operationa 

l 

Operationa 

l 

Operationa 

l 

Publish UDDI information Operationa 

l 

Provide controlled access to and Operationa 

from the web server 

l 

Allows to configure remoting 

services and code access security 

policy 

Operationa 

l 

Store in SQL DBs data that is used Operationa 

for the UDDI publisher 

l 

Table 13: Required software for the MEDISYSTEM pilot


5.4.1.2 SODIUM platform tools installation : problems and solutions 

Server environment installation (all on Websrv): 


the Medisystem Pilot and in order to deploy the SODIUM platform on the server side. 

Problems encountered during installation and solutions to these are also included. 

Software / component Status Problem encountered Solution 

Eclipse 3.2.1 IDE Operational Versioning of Java None. 


Engine 


Tomcat 4.1 

Operational 

Operational 

Initial choice was to install MS 

MySQL 4.1 which was not fully 

suitable for MS UDDI Server 

The web server does not start. 

Server unavailable outside the 

firewall. 


SODIUM: USQL Engine Operational None NA 

SODIUM: USCL Engine Operational None NA 


Repository 

Operational 


Repository DB (MySQL) Operational 

JXTA plug-in 

The composition repository 

(tomcat application) couldn’t 

connect to the database server. 

Although the related web page is 

functional, the DB User does not 

authenticate. 

Install and configure the 

appropriate Java version by 

using the VM command and 

Preferences/Java/Installed 

JREs 

Remove MySQL and install 

MS SQL Desktop Engine 

Make appropriate changes in 

the Tomcat configuration file. 

Change the default port of 

the web server in the 

configuration file. Publish the 

server in the Firewall. 

Solve the Repository DB 

issue 

Added localhost to the list of 

machines from which this 

database user can connect 

from (MySql Server) and 

manually grant access to the 

DB. 

Table 14: MEDISYSTEM: Installation of SODIUM tools / server side: problems and 

solutions 

Client environment installation (all on LaptopIT): 


the Medisystem Pilot and in order to deploy the SODIUM platform on the client side: 

Problems encountered during installation and solutions to these are also included where 

applicable. 



Software / component Status Problem Solution 

Versioning Install the latest version of Eclipse 

Eclipse 3.1.2 IDE Operational 

and of Jena, UML2 and Web Tools 

Project Plug-ins 


SODIUM: Visual Editor 


Operational 

Versioning. Install manually different 

components and reinstall the Visual 

Editor plug-in. 

SODIUM: USQL Client 


Operational 

Do not return any service Change the version of Java and 

make use of VM switch and 

Preferences/Java/Installed JREs 

JXTA Network Operational 

Peers didn’t always find 

each other 

Made the appropriate peer 

configuration. 

Table 15: MEDISYSTEM : Installation of SODIUM tools / client side: problems and 

solutions 

5.4.1.3 Evaluation of platform-level requirements during the installation 

The following table summarizes the evaluation of SODIUM platform level requirements as per 

D3 Part I during the installation of the SODIUM platform components at MEDISYSTEM: 


installation 

RP03: Platform 

independence 

Details 

YES All installed OK All components were installed 

without issues related to the 

platform 

RP10: Scalability YES All installed OK At the installation phase no 

scalability issues were 

encountered 

RP11: Security YES All installed OK All the security issues were 

managed by other means outside 

the SODIUM platform such as 

firewall, use trusted sites and 

sources 

RP16: Modularity YES All installed OK Excellent example of modularity. 

Each component can be installed 

and run on its own. 

Table 16: Evaluation of platform level requirements: installation phase at 

MEDISYSTEM 


5.4.2 Assessment related to the use of tools and methodology till end of project 

5.4.2.1 Evaluation of the Visual Editor 

Criterion/Indicator Requirements Measurement 

tool 

Heterogeneous 

service types 

Ability to use services of 

types Web, Grid and P2P 

services 

Basic file handling Support for create, open, edit 

save and print 


patterns 


parallel split, synchronization, 

exclusive choice, multiple 

choice, simple merge and 

discriminator 

Documentation Support for basic annotation 

and commenting functionality 

QoS Characteristics The ability to specify QoS 

properties of specific services 

as well as the QoS 

requirements of specific tasks 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 



Data collection 

method 

Result Comment 

Operational tests, trials OK The P2P invocation has been 

tested with difficulty as the P2P 

network technology use was not 

reliable. The configuration of the 

plug-ins needed to invoke 

compositions with P2P services is 

complex and can easily induce 

errors. 

Operational tests, trials OK Includes drag and drop feature 

Operational tests, trials OK Has the ability to model the basic 

workflows. More advance 

workflows can be implemented by 

use of the XSLT and XPath 

languages 

Operational tests OK All panes, views and components 

have been presented in detail. 

Separate 

available. 

installation steps are 

Operational tests, trials OK QoS criteria can be specified for 

each task.


tool 


constructs 

Support for task modeling, 

service operation modeling, 

input/output parameters and 

data transformations, start 


Parameter types Support for defining syntactic 

and semantic types for 

input/output parameters. 

Timeouts Ability to specify maximum 

response time for a service 

Task hierarchy Support for specifying 


Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Graphical symbols Should be standards-based Manual 

inspection 

Basic editing 

functions 

Support for 

enabling/disabling sticky 

selection 

Manual 

inspection 



Data collection 

method 

Result Comment 

Operational tests, trials OK All have been implemented. 

Operational tests OK All basic types of parameters are 

provided. 

Operational tests, trials OK The maximum response time for 

each task can be set. 

Operational tests, trials OK Sub compositions/task can be 

used. 

Operational tests, trials OK The available symbols are 

standard. 

Operational tests, trials OK Sticky selection is available.

5.4.2.2 Evaluation of the USQL Engine 


tool 

Access both private 

& public registries 

Unified access of 

heterogeneous 

registries 

Support operation- 

and message-level 

search criteria 

Semantically 

enhanced service 

discovery 

QoS-aware service 

discovery and 

selection 

Should be able to access and 

query against both public and 

private registries, in a 

seamless manner. 

Should be able to access and 

query against various 

heterogeneous service 

registries and networks in a 

transparent way. 

Should provide for the users 

the appropriate means for 

expressing search criteria at 

the operation level and 

message level, addition to 

service-level requirements. 

Should be able to support 

semantic matchmaking. 

Should enable users to 

specify QoS-based search 

criteria. 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 



Data collection method Result Comment 

Operational tests, trials OK The way of accessing public and 

private registries is quite 

complicated 

Operational tests OK The manner of supporting this 

feature is very user friendly 

Operational tests OK It covers very well all the 

requirements 

Operational tests OK All the basic requirements are 

covered 

Operational tests OK QoS criteria are simple to use in a 

USQL query and they effectively 

improve service selection.


tool 

Up-to-date 

application of 

service discovery 

over P2P networks 

User-friendly 

interface 

Should allow retrieving up-todate 

service advertisements 

from highly volatile 

environments, such as P2P 

networks. 

Should facilitate users in 

constructing service requests 

and submitting them for 

execution 

Performance Should respond in service 

requests at a reasonable time 

< 60 seconds) 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Exception handling Transparency, effectiveness Manual 

inspection, Log 

files 

Availability 24/7 Manual 

inspection 

Expandability Extensions must be easily 

accommodated 

Manual 

inspection 




Trials Partially 

OK 

Due to the asynchronous, volatile 

nature of P2P networks and the 

lack of a caching mechanism for 

the USQL Engine, it is not always 

feasible to discover all available 

P2P services with a single query 

execution. Thus, recall is reduced, 

as opposed to the case of Web 

service discovery and Grid service 

discovery. 

Operational tests, trials OK The interface is well organized 

allowing developing complex 

queries in a simple manner. 

Operational tests, trials OK Response time is affected by the 

connection state to USQL engine. 

However, timeout can be modified. 

Operational tests, trials OK Exceptions are logged in the 

Tomcat Server log. 

Operational tests, trials OK The Query Engine is available as 

long the web server is running. 

Operational tests OK The Engine is able to 

accommodate different types of 

registries such as UDDI, JXTA and 

service description protocols such 

as WSDL, SAWSDL or WS-QoS .


tool 

Maintainability On request or when updates 

are available 

Manual 

inspection 

Scalability 2 registries have been tested Manual 

inspection, logs 

Portability Install on windows platform Manual 

inspection 




Operational tests, trials OK Updates and regular check have 

been performed with ease. 

Trials OK Response within required time 

scale 

Operational tests OK Running with no problem on 

Windows platform. No tests on 

other platform have been 

performed.

5.4.2.3 Evaluation of the USCL Engine 


tool 

Extensibility Should accommodate 

services of different kinds. 

Abstraction Should be based on a unified 

model, which does not 

require any extension when it 

is applied to compose 

services of different kinds. 

Modularity Should provide a modular 

architecture to permit dealing 

with issues such as security 

and reliable message 

delivery. 

Flexible Deployment Should be flexible in 

deployment, in order to tackle 

specific security and 

performance issues. 

Exception handling Should provide support to 

exception handling 

Manual 


Manual 


Manual 

inspection 

Manual 

inspection 

Manual 





Operational tests, trials OK Web and Grid services are quite 

simple to deploy. Taking in the 

consideration the nature of P2P 

services some more issues 

emerged, but were solved. 

Operational tests, trials OK Same approach no matter the kind 

of services used in compositions. 

Operational tests, trials OK Various mechanisms are in place 

to allow dealing with these issues. 

Operational tests, trials OK Same as above. 

Operational tests, trials OK The available system outputs that 

are the mechanisms to deal with 

exception handling can be used 

both at deployment time and at run 

time.


tool 

Reliable Execution Mechanisms for reliable 

execution should be in place 

so that faults within the 

execution engine itself do not 

affect the execution of its 

compositions. 

Persistent storage 

independence 

Publishing of 

service 

compositions 

The reliable execution 

mechanism should be 

independent of the underlying 

data storage technology. 

Should enables clients to 

invoke service compositions 

as services, by utilizing well 

known industry standards, 

such as WSDL and SOAP 

Manual 


Manual 


Manual 

inspection 




Operational tests, trials OK The available mechanisms have 

been evaluated on different 

occasions not on as a main load 

task. On these occasions the 

engine did notify the user. 

Operational tests, trials OK Requirements have been achieved 

Operational tests, trials OK Some issues have been reported 

on the Web Services API interface. 

The main API interface performed 

well.

5.4.2.4 Evaluation of the Composition repository 


tool 

Versioning The ability to store different 

versions of the same file. 

Manual 

inspection 

Remote access Should be remotely accessible. Manual 

inspection 

Search capability Files should be easily located 

and retrieved, based on specific 

criteria 

Availability Should be highly available 

(24/7). 

Scalability Should be scalable to support 

multiple user access. 

Security It is important that any file 

storage and versioning system 

provides access control by 

assigning specific privileges to 

users. 

File sharing It should be possible for a file to 

be shared among multiple 

projects. 

File Branching It should be possible for a 

shared file to be broken into two 

or more independent files, for 

each project. 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 




Operational tests, trials OK Simple to use and good visibility of 

versions 

Operational tests, trials OK Is accessible as a web page. 


Operational tests, trials OK This feature depends primarily on 

the availability of the web server 

hosting the repository 



Operational tests, trials OK The repository allows easy sharing 

of the same file among multiple 

projects 

Operational tests, trials OK Only on manual basis

5.4.2.5 Evaluation of the overall methodology 


tool 


concrete 

compositions 

Bottom-up 

composition 

development 


services 


discovery 

Data 



compositions of tasks without 

knowledge of existing 

services, and to select 

specific services for the 

tasks, and the ability to 

maintain this information in 

the same model 


compositions when the user 

knows exactly which services 

to use 

The ability to search for 

services 

The ability to define run-time 

queries, meaning that the 

search for a matching service 

is performed as part of the 

execution 

Support for defining data 

transformations between data 

objects 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 

Manual 

inspection 



Data collection method Req. met. 


Tasks inside composition can also not be 

assigned to a specific service or subtask if 

needed. The execution engine will treat the 

task as a black box that if this does not 

return any output. 


This is done very easy and also 

automatically includes the input and output 

parameters of the used service. 


This is done very easy by using the USQL 

Query from inside the Visual Composition 

Studio. 


This is done very easy in the Visual 

Composition Studio as a query can be 

included and run in the composition. The 

Execution Engine has the ability to execute 

the query at run-time. 


Both simple and more complex data 

transformations can be used. The process 

is not simple, even for the simplest


tool 


task 



Support to select several 

candidate services for a task 


strategy for final selection. 

Manual 

inspection 

Support for transformation Manual 

inspection 



Data collection method Req. met. 

transformations and likely to induce errors. 


A task can have more than one service that 

can be run in parallel or in series. 


The compositions are compiled into USCL 

files. These files are then deployed and 

executed in the Execution Engine.

5.4.3 Meeting Key Business Requirements for MEDISYSTEM 



In this section we summarise how the key business requirements are met for MEDISYSTEM through the use of the SODIUM platform 

and tools. 

Business requirement Req. 

met 

Use different types of available services such 

as Web, P2P, and Grid services 

Explore the ability to combine “internal 

services or private services” with publicly 

available services. 

Experiment, test and adopt solutions to 

efficiently and effectively develop applications 

from heterogeneous services. 

Test the capabilities to easy use and integrate 

the emerging services with existing 

capabilities. 

Accommodate simple discovery of new 

services and fast use. 

Comments 

Yes The use of each different type of service is quite simple as long as the services are 

available and the appropriate plug-in components have been set up. 

Yes A composition may contain internal or external services in a seamless manner. 

Yes The solution provided by the compositions that simply can include heterogeneous 

services proved to be efficient. 

Yes The resulting service of a composition can be integrated with the existing applications. 

Two interfaces are available: API and Web 

Yes Services can be discovered by using the integrated USQL Dialog in the Visual 

Composition Studio.


5.4.4 Qualitative benefits from using the SODIUM approach 

Medisystem (S.C. MEDISYSTEM HOSPITAL S.A) belongs to the Eureko Group 

(www.Eureko.net), one of the leading financial services firms in Europe with significant 

financial resources and internationally recognized credit ratings. Medisystem operates 

Euroclinic Bucharest, the first private hospital in Romania, and the flagship facility of the 

Medisystem project in Romania. The Hospital, a brand new facility built next to the most 

modern public hospital in Romania – Floreasca Emergency Hospital, is licensed to perform 

medical and hospital services. 

The principal benefits from using the SODIUM Platform that are relevant to an end user with 

the characteristics of MEDISYSTEM are summarized in Section 5.1.1. above and relate both 

to the functionality and capabilities offered by the SODIUM Methodology and Platform and 

the fact that MEDISYSTEM is a member of an international Group with access to assets and 

expertise of far larger companies 

The assessment of whether these benefits are indeed obtained by using SODIUM will be 

carried out in the environment of MEDISYSTEM, a company which 

a) Belongs to a large multinational Group 

b) Has a small IT unit, though heavily relies on procurement 

c) Has the ability to form an International Private Network for publishing services along 

with IT departments of sister/mother/daughter/associated companies, some of which 

are of a rather considerable size and capability (especially those of Insurance 

Companies) 

d) Has strategic procurement priorities and constraints will be ascertained in a qualitative 

manner by recording the experiences of different functions in MEDISYSTEM that were 

involved in the Pilots and by also obtaining feedback from the Management. 

Qualitative feedback has been collected in the context of presentations, discussions and 

brainstorming sessions conducted within MEDISYSTEM. 

In providing such an assessment, MEDISYSTEM has decided to “codify” perceived business 

benefits as per following SOA benefits reported in [9] as follows: 

• Business Effectiveness 

� Be1. Agility, responsiveness to market and competitive dynamics 

� Be2. Greater process efficiencies 

� Be3. Deployment of resources based on business needs 

• Cost Efficiency 

� Be4. Reduced maintenance costs 



� Be5. Reduced skills and effort to support business change 

� Be6. Price/performance optimization based on freedom to select 

platform, technology, and location independently 

• Reduced Risk 

� Be7. Higher level of IT quality 

� Be8. Incremental deployment 

� Be9. Improved payback times 

Furthermore, the assessment process will also look for deficiencies that are to fall in one of 

the areas: 

• Df1. Inability to properly manage and monitor services 

• Df2. Inadequate security measures 

• Df3. Inconsistent performance and reliability (quality of service) 

• Df4. Issues resulting from a lack of discipline and control in the development 

and operations management areas 

• Df5. The need for middleware functionality to handle orchestration, 

transformation etc 

For a small IT team in charge with deploying new developments to support the business it is 

important and some time crucial to asses the benefits and especially the risks related not 

only with the deployed solution but with all the related activities including the installation. 

The following table summarizes qualitative assessment up to M30 where the codes for 

benefits and deficiencies are depicted above: 

Pilot activity Assessed 

benefits 

MPA1. Installing basic 

software components to 

support the platform 

MPA2. Installing the Visual 

Editor 

Be4, Be5,Be6, 

Be7, Be8, Be9 

Assessed 

deficiencies 

Issues /Notes 

Df4,Df5 Fast installation. 

Versioning issues 

can be important. 

Be5, Be8 Df4, Df5 Easy to install. 

MPA3. Installing the repository Be5, Be8 Df4,Df5 Easy to install. 

MPA4. Installing the USCL 

engine 

Be5, Be8 Df4,Df5 Easy to install. 

MPA5. Installing the query Be5, Be8 Df4, Df5 Easy to install. 


Pilot activity Assessed 

benefits 

engine 

MPA6. General use of the 

Visual Editor 


Be1, Be2, Be3, 

Be5, Be8, Be9 

MPA7. Access the repository Be1, Be2, Be3, 


MPA8. Access the USQL 

engine to retrieve available 

services 

MPA9. Run query engine, 

return service of type WEB 

Service 

MPA10. Run compositions 

invoking WEB services 


return service of type P2P 


invoking P2P services 


return service of type GRID 

service 


invoking GRID service 


Be5, Be8, Be9 


Be5, Be8, Be9 

Assessed 

deficiencies 

Issues /Notes 

Df1, DF5 It covers well all 

main needs. Intuitive 

and easy to use 

tools. Main issues 

related with data 

transformations. 

Df1 Easy to install. 

none It covers well all 

main needs. Intuitive 

and easy to use 

tools. Effective 

response. 

none Easy to use and 

effective response. 

Be4, Be5, Be6 none Easy to use 


Be5, Be8, Be9 

Be4, Be5, Be6 



Be9 

Effective response. 

none Easy to use and 

effective response. 

Be4, Be5, Be6 none Easy to use 

Table 17: MEDISYSTEM Preliminary qualitative assessment 

Summarizing the assessment revealed the following: 

• The estimated increase in efficiency is in the range of 30-65% of normal workload. The 

development and testing of a medium size composition requires 45% of the total 

development time while the transformations and decision nodes and their testing require 

the remaining of 55%. 



• Even simple standard transformation can induce errors although can easily be done and 

testing by using an available XML tool (Stylus Studio). 2-to-1 transformation requires 

more hand-coding and this is very time consuming and induce errors. 

• The decision node requires knowledge of XSLT and all the changes affecting the node 

need to be done manually. 

• Error messages related with transformation and decision nodes are visible at run time on 

Execution Engine not at design time on Visual Studio 

• The Eclipse platform is using important amount of memory that can affect the 

performance of other running application. 

5.4.5 Cost of Using the SODIUM Approach 

The costs associated with introducing and making full use of SODIUM into a business 

environment of a large group is studied and quantified: 

Such costs can include: 

a) Set up of infrastructures and procedures for publishing and maintaining services in 

a private network 

b) Set up of infrastructures for discovering, selecting, acquiring and introducing 

services into the group private network 

c) Particular measures to be taken for security 

d) Adaptation of procurement procedures and agreements 

e) Thorough training of all personnel involved and probably third parties that 

participate in software development 

f) Acquisition of tools etc. 

g) Development of quality procedures 

h) Major adaptations of technical documentation and quality documentation 

Further costs have not been spotted during the operation of the pilots. 

The following quantitative analysis is focused on most common activities and does not 

include complex or special cases. 

Activity Cost (pers.-days) 

Training in using the tools 2 

Training for supporting the tools 1 



Activity Cost (pers.-days) 

Installation of tools 2 

Customization of tools; involving setting up Java, Tomcat, MySQL etc 2 

Create composition 

Create a medium complex composition with sub compositions, alternative 

services on at least one task, use of decision node, split/merge. 

Query for services 0.5 

Execute composition 

Assuming that the execution requires debugging. 

Integration 

Including transforming from VSCL to USCL, using the embedded query 

engine in the Composition Studio, deploying the USCL file in the execution 

engine and storing the associated file into Repository. 

Transformation 

Assuming that at least 2 transformations of output from one task to input to 

another task is to be done in the Visual Composition Editor 

Integration with client application 

Including the coding needed to use the result from the execution engine and 

to process this result according to the type of the output data. 

5.4.6 Cost Benefit Analysis 

Cost: 

Hours 

Rate 

(€/hour) 


1 

0.5 

0.5 

1 

1.5 

One time 

cost 

(€) 

Yearly 

cost 

(€) 

Equipment 

1 new server for the Execution engine 2000 0 

1 new PC for the Visual Studio 1550 0 

Setup the equipment hardware and OS 24 30 480 0 

Installation of the SODIUM platform 16 30 720 0 

0 0 

Training: 0 0 

5 employees trained in using the platform 20 30 600 0 

3 employees trained in supporting the platform 80 30 2400 0 

0 0 

Other costs: 0 0 

Change existing code 80 30 2400 0 

Total cost: 10150 0 

Benefit: 

35% improvement of efficiency 1700 30 17850 

Possibility of terminate outsourcing contracts 5000

Cost: 


Hours 

Rate 

(€/hour) 

One time 

cost 

(€) 


Yearly 

cost 

(€) 

Re-use of code 160 30 4800 

Cost reduction as maintenance performed locally 16 30 480 

Cost reduction caused by central update of data 16 30 480 

Cost reduction caused by faster local installations 24 30 720 

Total benefit 29330 

Payback time: 10150 € / 29330 € = 0.34 of a year = approx. 1 year 11 months



5.5 Lessons Learned, Recommendations and Suggestions for improvement for commercialization 

The following table summarises lessons learned in the context of the MEDISYSTEM pilot with respect to Organisational changes 

introduced by SODIUM and training needed related to the use of SODIUM platform and tools 

Issue Comment 

Organizational 

changes 

The SODIUM approach does not imply organizational changes. Quality of the procedures can be affected as the user 

changing or using the composition needs comprehensive knowledge when a new version is created. 

Training The designers of the compositions require 2 days of training, while the developers for the client application require 1 day of 

training. 

The following table summarises lessons learned in the context of the MEDISYSTEM pilot with respect to the use of the SODIUM platform 

and tools 


Composition Studio Usability It is very user friendly and tools are intuitive. The logic and data flows can well cover complex scenarios. 

Composition Studio Changes in Local Changes to a service description from a service in Local Dictionary are not successfully reloaded and 

Dictionary links to the service/task in the composition need to be done manually. 

Composition Studio Basic data type Basic data type such as string, int, Boolean etc are difficult or impossible to be used as most of data 

available in Local provided by a service in a task need to be transformed as it is wrapped by its SOAP. No transformation to 

Dictionary basic data is possible and user needs to define this data into a file, publish on a web server and then 

import into local dictionary. 

Composition Studio Versioning of the A couple of issues have been encountered do to the version of Eclipse, Java or other auxiliary plug-ins or 

Eclipse, Java etc third party software.




Composition Studio Suggestions for 

possible 

• Simple data transformation of common output and input parameters 

automations of 

common but very 

• Basic decision nodes 

used task 

• Simple mechanism to verify data transformation available inside the Visual Studio 

Execution Engine 




Usability 

Multiple ”entry” 

points of the 

composition in 

the execution 

engine 

The Web access 

interface to 

access the 


the Execution 

Engine 

Versioning of the 

Eclipse, Java etc 

• Wizard for 2 to 1 transformations 

• Possible improvements: 

• Local dictionary to allow imports of all the services with descriptions available at a single URL 

• Possibility to allow remapping of a task components from a service to a new, similar or updated 

service that has identical parameters with the previous service used in the composition. 

• The Execution Engine is easy to use for the most common tasks, can handle very well a large amount 

of processes and is very robust. The information system that also includes the error message system 

gives a large amount of information about the processes. 

The Execution Engine generates couple of ”entry” points into a running composition. This is very useful 

when need to access subtasks but can very confusing for developers. Suggestion for the engine to 

provide mechanism in a form a check box to present subtask or only the main task. 

When a composition is deployed a specific web service interface is created (based on the composition) for 

invocation. It was found to be difficult to integrate this web service, so the web service API of the USCL engine was 

used instead.. 

A couple of issues have been encountered do to the version of Eclipse, Java or other auxiliary plug-ins or


third party software. 

Execution Engine Suggestions for 

possible 

improvements 

USQL Dialog and 

Engine 

USQL Dialog and 

Engine 

Composition 

Repository 

Composition 

Repository 

• Simplify the error message mechanism 



• Clearly separate the error messages from the output messages 

• Make the access to the web interface of a composition to behave identical as any web service 

• Locating the current issue in the editor is available but can be simplified and improved to speed up 

the debugging process 

Usability It is very user friendly, with search tabs well organized and intuitive. The USQL Dialog is well integrated 

in the Composition Studio. 

Possible 

improvements 

• Support for publication of services 

• Enable update of the ontologies being used. 

• Be able to simply include the Local Dictionary present in the Composition Studio when executing 

queries 

Usability The Composition Repository is simple to use and can store different version of the same project. 

Possible 

improvements 

5.5.1 Recommendations for future enhancement: 

Needs to be more tightly integrated with the Visual Composition Studio. 

The following table summarises recommendations from the MEDISYSTEM pilot for future enhancement with respect to the SODIUM 

platform and tools


Composition Studio Basic data 


Composition Studio 2-to-1 


Composition Studio More error 

messages 

present in the 

Composition 

Studio 

Composition Studio Copy and rename 


Composition 

Studio. 

Execution Engine Error messages 

in Execution 

Engine 

Execution Engine Separate screen 

for results in 


USQL Dialog & 

Query Engine 

Updating the 

USQL Engine’s 

configuration 

files. 



Transformation of basic data and data types present in Local Dictionary should be facilitated by the 


2-to-1 transformations should also be made in the Composition Studio by a specialized module or tools. 

A wizard for 2-to-1 transformation will be of great help. 

Some errors related with the transformations should be also available in Composition Studio not only at 

run time in Execution Engine 

By copying or renaming a composition the reference points to the same initial uml2. This is making the 

copied or renamed file difficult to be later reused. 

The errors during run time are presented in the same screen with the results and other information. 

These types of information should be categorized and presented in different screens. 

It is time consuming to locate the result of a process. A separate screen eventually with improved graphic 

interface will help. To retrieve information of a process or the result of it now someone need to type 

commands. 

In the current version the process of updating the configuration files of the USQL Engine hosted by 

Tomcat server is time consuming.


USQL Dialog & 

Query Engine 

USQL Dialog & 

Query Engine 

Composition 

Repository 

Multiple 

ontologies 

Multiple selection 

of results 

Improve 

integration 



It would be useful to simultaneously access more than one ontology at the same time and to enable 

updating the ontologies being used.. 

The screen presenting the results of a query allow in the current version only to delete a single service. 

More facilities such as multiple selection of result entries, or a context menu should be present here to 

facilitate the selection of the appropriate service before the user can press “Save Results”. 

The Composition Repository should be integrated with the Visual Composition Studio.


6. Evaluation as per the feedback from external user forums 

As described in Deliverable D13 - Plan for the dissemination and use of knowledge [6] : 

The SODIUM user forums have been established at a national level with the aim to present 

the SODIUM results and obtain feedback which is considered valuable in refining project 

outcome. 

� In Norway, SINTEF and Locus has taken the initiative to establish a SOA User working 

group, under the umbrella of the Norwegian Computer Society. The group is led by Arne 

J. Berre of SINTEF, and currently counts around 100 active members. During the spring 

2006 monthly events around topics related to service-oriented architectures were held. 

The SODIUM toolset has been presented and demonstrated for an industrial audience in 

this context. 

� In Greece, ATC presented the SODIUM results to organisations that form its customer 

base in key business areas (banking and media). Related activities (organisation of group 

meetings and demonstration of SODIUM platform) have taken place in July 2006 and 

November 2006. 

� In Switzerland, ETHZ has been actively involved in the recent Swiss Grid Initiative, where 

the SODIUM platform has been successfully presented to the Swiss Scientific community 

and key components are currently being deployed at several universities and at the Swiss 

National Supercomputing Center. ETHZ is also involved in promoting the use of the 

composition engine for Grid computing and large scale scientific computations. 

6.1 Feedback from user forums 

Feedback from user forums with participants beyond the Consortium is considered important 

in refining the SODIUM platform and tools. For each event involving users the following 

information is being reported: 

� Country 

� Date and Venue 

� SODIUM partner in charge of event 

� Subject of event / workshop 

� Number of participants 

� Details on participants (company names and line of business) 

� Means of collecting feedback (e.g. questionnaires, open format brainstorming 

session) 

� Evaluation feedback – main points 



In this version of the deliverable, this section presents feedback received in the main relevant 

events held in Norway during the reporting period as well as the first event in Greece. 

Similarly related activities in Switzerland are planned for September and will be reported 

once completed. 

6.1.1.1 Norwegian User Forum 

Activities involving presentations of SODIUM results to user forums were held in Norway 

during 2006 as presented in the table below: 

Date 

and 

Venue 

Feb 8 

2006 

March 

15 

2006 

April 3- 

4 2006 


partner 

in 

charge 

of event 

Subject of 

event / 

worksh. 

SINTEF SOA – 

Best 

practises 

SINTEF SOA 

interest 

group 

SINTEF 


LOCUS 

No. 

of att. 

Details on participants 

(company names and 

line of business) 

20 End users, consultants 

and suppliers using or 

promoting SOA strategy. 

10 Users: Selvaag (Building 

construction), Aeat 

(Gorvemental) 

Suppliers: IBM, Sun, 

Locus. 

Consultants: Bekk 

Research: Sintef, 

University of Oslo 

SOA 50 Users: Aftenposten 

(media), Ullevål 

University Hospital 

(Medical - hospital), Aeat 

(Governmental), IFI 

(Governmental), Selvaag 

(Building construction), 

Telenor 

(Telecommunications), 

Suppliers: IBM;, SUN, 

Simula Research Lab., 

Norsk Regnesentral, Det 

Norske Veritas 

Research: Sintef, 

University of Oslo 

Consulting: Bekk, Mesan, 

Software Innovation, 

Ivanor 

Means of 

collecting 

feedback 

Evaluation feedback – 

main points 

Discussion No specific feedback was 

taken. There was an open 

discussion around SOA 

topics. SODIUM is brought 

in here as an element to be 

considered. 

Questionnaire The overall rating for the 

SODIUM presentation was 

given a score of 4 (1 – 6 

(best) both on presentation 

and content. 


The main feedback was 

taken from demonstrations 

of the SODIUM Visual 

Composition Suite : 

Main feedback points: 

The feedback on the GUI 

and functionality was in line 

with what the developers in 

the SODIUM consortium has 

experienced. This feedback 

has been provided to 

responsible partner. 

Questions have been raised 

concerning if it is possible to 

exchange information by 

UML alone. As the UML

Date 


Venue 

June 7 

2006 

Sept. 

20, 

2006 

Oct. 

18, 

2006 

Nov 

15, 

2006 

Dec. 

12, 

2006 


partner 

in 

charge 



event / 

worksh. 

SINTEF SOA – 

Best 

practises 

follow up 

SINTEF Semantic 

Web and 

Technologi 

es 

SINTEF SOA for 

Application 

integration 

SINTEF BPM and 

SOA 

SINTEF Web 2.0 

and SOA 

2.0 and 

evolution 

towards 

3.0 


No. 


Details on participants 

(company names and 

line of business) 

10 A subset of the 

representatives from the 

April session. 

80 Additional organisations 

also with an interest in 

semantic technologies 

45 Core partners in the SOA 

special interest group 

40 Organisations with an 

interest in the relationship 

between business 

models and SOA 

50 Extended set of partners 

in the SOA special 

interest group 


collecting 

feedback 

Table 18: Norwegian User Forum Activities 

Evaluation feedback – 

main points 


language has no complete 

functionality to exchange all 

information the solution used 

in SODIUM got acceptance. 

The need for the SODIUM 

tools to work with .Net 

development tools has been 

raised. The SODIUM 

partners are evaluating the 

consequences for having 

implemented better .Net 

support. 

Brainstorming Brainstorming around setting 

up a set of rules for “Best 

practice for SOA” as part of 

the Norwegian Computer 

Society user groups. 

Discussion Semantic aspects need to 

be integrated with SOA 

technologies like Web 

services, P2P and Grid 

Discussion It is a general problem that 

the availability of real 

services to search for is so 

limited. The initial approach 

of UDDI has been a market 

failure. 

Discussion UML activity diagrams 

should be related to BPMN 

evolution. 

Discussion It is foreseen a merge of 

trends from the user 

involvement with usability 

(AJAX) and Folksonomies, 

and semantic technologies 

on top of a heterogeneous 

platform of Web services, 

P2P and Grid – enhanced 

with Agent technologies and 

sensor technologies


Note : The questionnaire used in the context of the session held on April 3-4 2006by SINTEF 

and LOCUS (and related quantitative results) are presented in Appendix II - Norwegian User 

Forum Questionnaire and related results 

6.1.1.2 Greek User Forum 

Presentations of SODIUM results to user forums held in Greece during 2006 are presented in 

the table below: 

Date 


Venue 

June 

30, 

2006 

Novem 

ber 27, 

2006 

Novem 

ber 30, 

2006 


partner 

in 

charge 


Subject 


/ 

worksh. 

ATC Introducti 

on to 

SOA and 

the 


approach 

ATC Presentat 

tion of 


project, 


results 

ATC Presentat 



project, 


results 

No. 

of 

att. 

Details on 

participants 

(company names 

and line of 

business) 

6 CIOS of the Fourlis 

Group 

4 Representatives of 

ATC banking 

customers : Alpha 

Bank, Eurobank, Post 

bank Bulgaria 

5 Representatives of 

ATC media 

customers : ANA 

(News Agency), 

KERDOS, Nafteboriki 

(Newspapers), 

Antenna (TV station), 

Liberis (Publishing 

House) 


collecting 

feedback 

Discussion, 

Questionna 

ire 

Discussion, 

Questionna 

ire 

Discussion, 

Questionna 

ire 

Table 19: Greek User Forum Activities 

Evaluation feedback – main points 

To a large extent, respondents confirmed 

importance of SODIUM features (vs 

desirability) as initially identified by project 

partners. “Compatibility with services 

developed by different development tools”, 

“Modularity” and “Standards compliance” 

was considered the most important 

features and selling points for the SODIUM 

platform. 

SODIUM fits well in the banking 

environment where there is a strong need 

to develop applications that respond to 

changing customer needs, regulatory 

requirements and business evolutions and 

support reuse of services in the context of 

the bank’s multi-channel approach through 

a variety of access devices 

(PC,PDA,mobile) to support customer selfservicing. 

The media industry faces challenges 

related to inefficiency of processes for 

creating, managing and distributing digital 

assets. Service oriented development with 

SODIUM can potentially improve process 

workflows in content delivery enabling 

integration of content and billing systems. 

Note: The questionnaires used in the context of the sessions and related results can be 

found in Appendix I –Questionnaires used in the sessions held in Athens & relevant results 

(Greek User forum). 



7. Evaluation at the IST Event 2006 

SODIUM participated in the IST Event 2006 2 , held in Helsinki in 21-23 November 2006 with 

an Exhibition stand. The Exhibition was open to the general public and aimed at presenting 

concrete results of research in and around Europe within the field of Information and 

Communications Technologies. 

The SODIUM stand was a “Research and Technology” Stand within the Exhibition zone for 

“Novel solutions for business and industry”. The theme of the SODIUM stand was 

“Demonstrating user-friendly graphical tools in to discover web, peer-to-peer and GRID 

services” 

During the three days event, a presentation of the SODIUM results with real-time 

demonstration of the LOCUS pilot was effected. Flyers describing the project, its results as 

well as the two pilots were also distributed. 

Feedback from visitors is presented below 

Date 


Venue 

21-23 

Nov 

2006, 

IST 

event 

2006, 

Helsinki 

SODIU 

M 

partner 

in 

charge 


event 

NKUA, 

LOCUS 

, ATC, 

SINTE 

F also 

present 


event / 

workshop. 

Exhibition 

stand – 

Demonstra 



results and 

No. 


Appro 

x 100 

Details on 

participants 



business) 

The majority of the 

visitors represented 

Universities and / or 

other research 

institutions. 

2 http://ec.europa.eu/information_society/istevent/2006/index_en.htm 


collecting 

feedback 


Discussion We received positive comments, both for the 

tools and the pilot application. 

People were particularly interested in the 

open-source license of the SODIUM tools 

and kept asking when the tools will be 

available as open-source. Also, they seemed 

to like the fact that we had tools covering the 

whole development phase, and that all of 

them were integrated in Eclipse. Another 

feature that made good impression was the 

platform's independence from the various 

service types and standards. 

Finally, we received questions on whether 

there is a plan for continuation / expansion of 

our research results in future projects or not. 

Regarding the pilot demo performed by 

Locus: 

- visitors were impressed that this was a realtime 

application. 

- the majority of the visitors has used either 


Date 


Venue 

SODIU 

M 

partner 

in 

charge 


event 


event / 

workshop. 


No. 


Details on 

participants 



business) 


collecting 

feedback 


grid or web services and was very interested 

in our work in making such services 

transparent to the user. 

- It was interesting to visitors to be able to 

withdraw the composition from the 

application so that the composition could be 

used on several platforms. 

- All seemed very interested in the Query 

Engine and the possibility of searching for 

services in the development phase. 

- The Composition Studio which was the 

main focus of the pilot demonstration 

received credit for its user friendliness in 

creating compositions. 



8. Evaluation of Results with Respect to Business Plan 

Requirements 

8.1 Summary of SODIUM Assets 

As described in the SODIUM D16-Business Plan [7], the main tangible SODIUM assets are 

as follows: 

Result Description 

SODIUM Unified 

Service Composition 

Methodology 

Methods and techniques for composing heterogeneous services (web, p2p, Grid) 

Generic Service Model Specification of a generic service model supporting the description of 

heterogeneous services (web, p2p, grid) 

Visual Service 

Composition Language 

(VSCL) 

Specification for graphical descriptions of service compositions at multiple levels of 

details 

Unified Service Specification for lexical representation of service composition 

Composition Language 

(USCL) 

Unified Service Query Specification of a unified service query language facilitating the discovery of 

Language (USQL) heterogeneous services (i.e. web, p2p and grid services) 

SODIUM Visual Support for designing and analysing composition graphs, translation of graphical to 

Composition Suite lexical representations 

SODIUM USQL Engine Mechanism for discovering various types of services that can be used in a 

composition, based on syntactic, semantic and QoS search criteria 

SODIUM USCL Engine Mechanism used for executing lexical descriptions of composition graphs 

SODIUM Composition 

Repository 

Mechanism for storing / reusing service compositions 

SODIUM Platform Environment comprising of integrated tools described above supporting the unified 

composition, discovery and execution of heterogeneous services 

Table 20: SODIUM tangible assets 

Further to the above tangible assets, intangible assets are expected to stem from the overall 

project, and especially from the conduction of pilots. These assets will help the future 

exploiters of the technology, make its best use. Such assets are: 

• An increase in the know-how, methodologies, supporting tools and runtime 

middleware in order to facilitate RTD developers in composing heterogeneous 

types of services through an open, middleware development platform 

• The ability to provide consulting services and know how in the state of the art in 

service discovery and composition 



The task of exploiting tangible assets from a pre-competitive Research and Development 

activity efficiently is always a tricky issue that requires that certain measures are taken during 

the project in order to minimize the adverse effects of any weaknesses and threats 

encountered and in order to make optimal use of the strengths of the solution/ products and 

the evolving market opportunities. 

Thus, it is necessary to assess the outcome of the project from this scope as well, so as to 

take measures, even in the last stages of the project that will ensure that productisation / 

commercialisation after project end does not become another similar or larger in size, project. 

8.2 Summary of SWOT Analysis Findings 

The SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis for the SODIUM 

solution has been discussed in the respective of the SODIUM Business Plan [7]. In this 

section we will provide a summary of the analysis finding in order to assess the effectiveness 

of the SODIUM methodology, platform and tools in exploiting the opportunities present as 

well as in order to assess the provisions and measures taken to minimize weaknesses. 

The main opportunities for the SODIUM solution lie in the combination of the effects of two 

trends: 

• First, a trend towards “industrializing” or automating software development which is 

becoming a key issue as new software development is becoming increasingly more 

expensive. This trend was evident in the nineties and was partially addressed then by 

software re-use, but more recent developments in Software Architecture, now permit 

more far-reaching approaches involving Service Oriented Architectures that can 

drastically reduce the cost of Software development at the same time increasing its 

quality, by offering state-of-the-art applications in several domains as Services. The 

Morgan Stanley Research Report of April 2006 on Enterprise Software Platform [10] 

views “migration to Service Oriented Architectures (SOA) as the primary technology 

trend”. 

• Second, a trend towards “inventing” novel architectures that are either driven by 

specific functional needs of certain types of users or which permit to exploit at 

maximum computer power and data dispersed over several user sites. This trend is by 

nature endless and brings the need for solutions that can cope with heterogeneous 

services. At this time GRID Services and Peer- to – Peer Services are two dominant 

types of emerging architectures that need to be taken into account in designing a 

platform for service composition. 

Weaknesses of the SODIUM Solution lie in the facts that 

a) it is the result of a Research and Development activity, rather than a product resulting from 

straight-through-production activities. This must be taken into account as it may “strengthen” 

the importance of certain inhibiting factors regarding the acceptance of SOA Solutions by 

Enterprises. As reported in D16-SODIUM Business Plan [7], “Limited visibility of Business 

Value and lack of skills remain the principal inhibitors for SOA adoption by Enterprises, 

accompanied by the natural resistance to change” [11]. To overcome this, SODIUM must 



present a paradigm that will convince decision makers that the Platform and Methodology are 

capable of supporting real-life industrial applications and that Services which are reliable, 

scaleable, secure and available do exist. 

b) it is a new product with overlapping functionality with existing products, a fact that may be 

a weakness that may hinder SODIUM from gaining sufficiently high market penetration. 

Slower penetration than the levels sought will lead to a difficulty in strengthening the solution 

and in increasing paradigm available, as well as in building a competent team of SODIUM 

specialists within the exploiting partner. 

8.2.1 Effectiveness of SODIUM Methodology, platform and Tools in Exploiting 

Opportunities 

SODIUM will be practically introduced into the SOA solutions in mid – to - late 2007, a period 

which the Consortium considers as rather favorable because successful paradigm from other 

solution providers will have already significantly increased the SOA solutions and services 

market. As Information Technology focuses more on getting more out of existing systems 

(rather continuously embarking in ventures for new system development) SODIUM appears 

promising in getting “the most” out of combining three types of heterogeneous services (web, 

p2p, grid). 

SODIUM will be offered, as described in SODIUM deliverable D13- Exploitation Agreement 

[8] with an Open Source Policy based on the LGPL model 3 which is fully suitable for 

licensing or for distribution via already existing networks, once the SODIUM Methodology and 

Tools have been strengthened enough in the course of Commercial Contracts in Phase II of 

exploitation 4 . 

Hence, current possible competitors (in particular actors which focus almost exclusively on 

SOA) could become promoters of the SODIUM technology 5 . 

Thus SODIUM Offer could benefit from the anticipated fast growth of the SOA market by 

positioning itself as a provider for a specific part of this market which focuses on discovery 

and composition of heterogeneous services in a unified manner. It can target specific user 

communities which require specific GRID and P2P services. 

In this manner, future SOA developers will be able to exploit fully the Business (Efficiency, 

Responsiveness, Adaptability) and Technical Benefits (Reduced Complexity, Increased 

Reuse and Legacy Integration) that SODIUM partners claim to be the principal Strengths of 

3 http://www.opensource.org/licenses/lgpl-license.php 

4 M24-36 post project end as per the SODIUM Business Plan (Deliverable D16) 

5 

A typical commercial example of an organization which offers a platform where SOA solution providers can reach wider markets in the 

JBOSS Service. : http://www.jboss.com/services/index 



the SODIUM Solution as per the relevant SWOT Analysis in Deliverable D16 Business Plan 

[7]. 

8.2.2 Provisions and Measures taken to minimize weaknesses and their effects 

The Provisions and Measures taken to minimize weaknesses are in two distinct directions: 

ensuring that pilots to be conducted are representative of the future commercial contracts 

and that the main Industrial Partner adopts a Business Plan that help overcome weaknesses. 

• Provisions related to selection of suitable pilot applications for developing 

specifications, designing the system and validating the results 

The first provision relates to the pilots and services chosen. The pilots cover two potential 

types of SODIUM assets users: 

First, a typical end User (such as MEDISYSTEM) which employ Web, P2P and Grid 

Services for building an industrial strength application in a hospital environment where 

reliability and availability are very important; in this pilot the ability of an average-skilled 

industrial IT department to integrate SODIUM assets in their standard development and 

maintenance work will be tested. 

Second, a typical integrator which composes applications from existing services (such as 

LOCUS) where Web, P2P and Grid Services are composed in order to develop an everyday 

use application which forms part of a crisis management application, where again 

availability and reliability are very important; in this pilot, the ability of a highly skilled 

development team of a commercial IT company to integrate SODIUM assets in their 

standard development, service provision and maintenance work will be tested. 

The ability to handle efficiently the different sets of User Requirements for each of the 

pilots, and hence to provide evidence of ability to support industry standard software 

development by composing services using the SODIUM methodology, platform and tools 

have been discussed in the relevant sections 5 and 6 in this report. 

• Provisions related to adoption of a Business Plan that caters for increasing 

awareness and building gradually an industrial strength solution 

The second provision relates to the structure of the Exploitation Phases and the Method 

of “building” competent SODIUM consultants and engineers as explained in D16-SODIUM 

Business Plan [7]. A phased approach is selected for the Exploitation, where solution 

strengthening in the course of early commercial contracts has a high importance in 

subsequent exploitation efforts, leading to a solution that can be provided for use by third 

parties (franchisees etc.) 

Phase I of exploitation focuses on increasing awareness, and on gaining a small number 

of contracts (exclusively from existing ATC clientele) in order to strengthen the solution 

offered by SODIUM by subjecting to the criticism of further end-users. 

Phase II of exploitation aims at further strengthening the solution by gaining contracts 

from the open market (rather than from existing clients). To do so, the initial strengthening 



during Phase I will be very positive. Furthermore, this Phase aims at employing a stepped 

“generation” approach for building competent SODIUM experts through both conventional 

and in-the-job training. 

The above provisions work together towards permitting just the introduction of SODIUM to 

the market and towards building a name for it. Real provision for the existing weaknesses 

can only be achieved during the course of actual implementation of project exploitation. 

8.3 Recommendations and Suggestions for Commercialization 

As per the current status of development, SODIUM assets have been put under the strain of 

testing in two specific, though complementary applications. 

In the first case, (LOCUS), SODIUM technology enables a services provider to improve the 

quality and financial efficiency of a specific service provided by the Company, composing 

services known to the User. 

In the second case (MEDISYSTEM), SODIUM technology is used by an end-user directly, in 

order to maximize the benefits from belonging to several Groups, whether sectorial or 

Business –related in order to maximize the effectiveness of their systems at a minimum 

degree of investment and uncertainty regarding the quality of Services. 

Beyond project end, and in order to enhance exploitability of the solution, it will be necessary 

that it is strengthened and tested along the following directions: 

a) testing for service provision by a service provider at real-life complexity and 

pressure of operation 

b) Testing under real-life industrial conditions in at least two or three different sectorial 

domains (i.e. banking, media) in small, well defined commercial projects 

c) Development of procedural mechanisms for training SODIUM experts in the course 

of on-going commercial projects in order to develop a mechanism that can serve 

the “generations of experts” scheme proposed as methodology for developing 

SODIUM implementation teams. 



9. Conclusions and Suggestions for further work / Guidelines for 

Productisation 

9.1 Recommendations from the Industrial User 

In the context of the project and as reported in previous sections, an assessment of the 

degree that the SODIUM Outcome satisfies the Top-level Business, Functional and non- 

Functional Requirements of ATC as the main industrial partner of the project has been 

performed. 

In terms of enhancements to the SODIUM platform and tools, the following suggestions are 

provided by ATC, 

� The ability to store and retrieve compositions so as to reuse in different applications is 

considered an important feature, thus post project end the role of the Composition 

repository could be extended to provide additional relevant functionality 

� The graphical support in the area of transformations of messages between services in 

the Composition Studio, could be enhanced 

� The ability of storing query results from the USQL engine to the Local Dictionary of the 

Composition Studio is seen as an additional feature that can facilitate the developer 

� In terms of using the USCL engine in a commercial environment issues related to load 

balancing and fail over should be addressed 

� Furthermore, automatic code generation to support the integration of the compositions 

into applications would provided additional value to the solution 

� Support for p2p services should be extended (beyond JXTA) 

In addition to the above, the SODIUM methodology is also seen as an asset that should be 

exploited when selling the SODIUM solution in addition to the provision of the platform and 

tools 

In terms of supporting service oriented development, SODIUM contribution to increased 

developer productivity, reduction of development cost and reuse of services should be 

considered as important selling points. At the same time, as in all adoption lifecycles, it is 

expected that initial projects will be characterized by increased complexity and cost. Pilot 

projects in an organisation can pace the way for more extensive use of the approach and the 

tools. Training and support in the initial stages of application are considered an important 

factor for successful project completion. 


9.2 Recommendations from LOCUS 


The SODIUM solution is after initial training has been completed fairly easy to use. Some 

improvements are necessary if the solution is to be used by professional developers. 

The Composition Repository should be integrated with the Composition Studio for easy 

access to compositions. 

In order to simplify development, it should be possible to make a copy of a composition and 

then refine the copy. This would facilitate a refined development approach where one single 

step at a time is added to a composition. 

All the SOAP transformations should be handled by the Composition Studio, especially since 

the Execution Engine needs transformation on a specific format when we are dealing with 

transformation from 2 sources. In addition the VSCL to USCL transformation should check 

that the composition is correct. 

The Execution Engine should have improved error handling logging, this would facilitate 

debugging of the composition. In addition the VSCL to USCL transformation 

The Query Engine is working according to the expectations, but after using the tool for a 

while the need for deleting multiple service alternative simultaneously has occurred. This 

would make the service selection process much simpler. It would also be feasible to be able 

to see which UDDI (and other) registries that is used for the search. 

On-line documentation of the tools is preferable. Then the latest version of the documentation 

is always at hand. 

9.3 Recommendations from MEDISYSTEM 

The SODIUM solution is user-friendly, easy to deploy, and does not require many resources 

for installation and usage. The results provided by the SODIUM solution are reliable and the 

general performance of the components is in good accordance with the needs of a medium 

size company. The time needed for training to develop compositions with basic control and 

data flows, even with not so qualified users, is small. The SODIUM solution also provides 

means to deal with more complex control and data flows. 

Several improvements have been noticeable during the installation, configuration and testing 

of the solution. 

All the SOAP transformations, or at least the basic and more frequent ones, should be 

facilitated by the Visual Composition Studio. 

The process of building the USCL file should be accompanied by a syntax error checking 

especially for the manually created SOAP transformations. 

The Execution Engine provides extensive logging of the processes. The information 

presented needs to be grouped and presented separately, according to different categories 

of information, so as to facilitate both the debugging process and the monitoring. 



The Execution Engine provides two interfaces for its output. The API interface performs very 

well, while the Web interface could be further improved. 

The Query Engine is very well organized and easy to use but the process of configuring the 

target registries and annotating the service descriptions with semantics and QoS is time 

consuming. However, the task of semantic and QoS annotations goes beyond the scope of 

the Query Engine. 

The Composition Repository should be accessible from within the Composition Studio. 

The deployment of the platform components and the documentation needs also to be more 

integrated. 

9.4 Recommendations from the User Forums 

Based on feedback, received from the Greek Forum 6 : 

The SODIUM solution fits well in the banking environment where there is a strong need to 

develop applications that respond to changing customer needs, regulatory requirements, 

address integration challenges, and support reuse of services in the context of the bank’s 

multi-channel approach to support customer self-servicing. 

In the context of media, SOA’s perceived impact lies in support of integration which is 

currently lacking in the sector. Service oriented development with SODIUM can potentially 

improve process workflows in content delivery enabling integration of their systems. Finally 

as is the case with the Banking sector, multi-channel delivery is also considered critical and is 

expected to be facilitated by SOA. 

The key selling points of SODIUM to be used for promoting the results post project end 

include modularity, compatibility with services developed by different development tools and 

standards compliance. 

Last but not least, to further support exploitation and adoption of SODIUM, key factors 

include training for potential users of the SODIUM platform and tools that should be provided 

by a team of qualified SODIUM experts, the provision of documentation and support for the 

tools. 

6 Further relevant comments can be found in section 6.1.1.1 


10. References 


[1] D3 Part I - Requirements Specification for Service Composition, Feb 2006 

[2] D3 Part II - Architecture of the SODIUM Platform, Feb 2006 

[3] D5 Part I – Requirements specification for the Locus Pilot, June 2006 

[4] D5 Part II - Requirements specification for the Medisystem Pilot, June 2006 

[5] DI4.1 – Evaluation Plan, June 2005 

[6] D13- Plan for the dissemination and use of knowledge 

[7] D16-Business Plan, June 2006 

[8] D17-Exploitation Agreement, June 2006 

[9] The Business Case for SOA Rationalizing the Benefits of Service-Oriented Architecture, 

January 2005, webMethods 

[10] Morgan Stanley Research, Industry View In-line, Enterprise Software, April 2006 

[11] InfoWorld Market Research, An Overview of the SOA Market, Conducted by IDG 

Research Services, March 2005 



11. Appendix I –Questionnaires used in the sessions held in 

Athens & relevant results (Greek User forum) 

Session held in Athens 30/6/2006 & relevant results 

List of participants 

Takis Karabourniotis, Group CIO 

Em.Vithoris, House Market (IKEA) Greece CIO 

A,.Frantzeskos, Intersport Hellas CIO 

G.Ghristakeas Intarget CIO 

G. Karagiannitis Fourlis Trade CIO 

G. Afentoulis, Euroelectronics (SAMSUNG Greece) CTO 

Questionnaire 

SODIUM features 

Below you may find a list of features provided/supported by the SODIUM platform. Please rate these features 

by marking them as Important or Desirable. Where needed please ask for a clarification. 

SODIUM platform Feature 

Quick & easy discovery of 

heterogeneous services 

Visual design of compositions 

Reuse of existing solutions 

Audit trails 

Composition storage & management 

Standards compliance 

Compatibility with services developed 

by different development tools 

Platform independence 

Open source 

Secure sharing of source files 

This 

feature is 

important 

This 

feature is 

desirable 

Do no 

know 



Availability 

Scalability 

Security 

RAD 

Extensibility 

Modularity 

Support of JXTA P2P services 

Support of the WSRF specification 


This 

feature is 

important 

This 

feature is 

desirable 

Do no 

know 

Of the features presented above, please identify below the 3 most important in your opinion: 

1. ___________________________________________ 

2. ___________________________________________ 

3. ___________________________________________ 

Comments: 

Thank you! 


Results 



Rating (nr of responses) 

Feature Considered Considered Do no know 

important desirable 

Quick & easy 

discovery of 

heterogeneous 

services 

6 

Visual design of 

compositions 

6 

Reuse of existing 

solutions 

6 

Audit trails 6 

Composition storage & 

management 

Standards compliance 6 

Compatibility with 

services developed by 

different development 

tools 

Platform independence 4 

Open source 1 

2 

5 

Secure sharing of 

source files 

6 

Availability 6 

Scalability 6 

Security 

RAD 4 2 

Extensibility 5 1 

Modularity 6 

Support of JXTA P2P 

services 

Support of the WSRF 

specification 

6 

6 

I 

I 

SODIUM Platform Feature Nr of respondents rating it as most 

important 

Compatibility with services developed by 

different development tools 

5 out of 6 

Standards compliance 4 out of 6 

Modularity 4 out of 6 


1 

1 

5 

5




Representatives of ATC banking customers: 

Dr. D.Stamoulis, (Alpha Bank) 

Ms E. Paleologou, Mr. N.Mazos (Eurobank) 

Mrs C.Petkova, Post bank Bulgaria (Bulgaria) 

Questionnaire 

SOA and the Banking sector 

What are the main drivers for SOA in your environment? 

What are the main challenges/risks with respect to implementation of SOA in your environment? 

What is the expected impact of SOA in your environment? 








This 

feature is 

important 

This 

feature is 

desirable 

Do no 

know 




Audit trails 






Open source 


Availability 

Scalability 

Security 

RAD 

Extensibility 

Modularity 




This 

feature is 

important 

This 

feature is 

desirable 

Do no 

know 

Of the features presented above, please identify below the most important in your opinion: 

___________________________________________ 

___________________________________________ 

___________________________________________ 

Comments: 

Thank you! 


Results 






Quick & easy 


heterogeneous 

services 

4 


compositions 

4 


solutions 

4 



management 





tools 


Open source 4 


source files 

4 

Availability 3 1 

Scalability 4 

Security 4 

RAD 4 


Modularity 4 


services 


specification 

4 

4 


important 

Standards compliance 4 out of 4 

Compatibility with services developed by 

different development tools 3 out of 4 


4 

4




Representatives of ATC media customers: 

Mr. P.Mantis ANA (News Agency) 

Mr. V. Antonopoulos, KERDOS (Newspaper) 

Mr. G. Zafolias, Nafteboriki (Newspaper) 

Mr. V. Moulakakis, Antenna (TV station), 

Mrs. I. Makrinaki, Liberis (Publishing House) 

Questionnaire 

SOA and the Media sector 

What are the main drivers for SOA in your environment? 

What are the main challenges/risks with respect to implementation of SOA in your environment? 

What is the expected impact of SOA in your environment? 









This 

feature is 

important 

This 

feature is 

desirable 

Do no 

know 



Audit trails 






Open source 


Availability 

Scalability 

Security 

RAD 

Extensibility 

Modularity 




This 

feature is 

important 

This 

feature is 

desirable 

Do no 

know 

Of the features presented above, please identify below the most important in your opinion: 

___________________________________________ 

___________________________________________ 

___________________________________________ 

Comments: 

Thank you! 


Results 






Quick & easy 


heterogeneous 

services 

5 


compositions 

5 


solutions 

5 



management 





tools 


Open source 3 2 


4 

source files 

1 

Availability 5 

Scalability 5 

Security 4 1 

RAD 5 


Modularity 5 


services 


specification 

5 

5 


important 

Modularity 4 out of 5 

Quick & easy discovery of heterogeneous 

services 3 out of 5 


2 

2 

3 

3


12. Appendix II - Norwegian User Forum Questionnaire and 

related results 

Please see attachment D21-Appendix II. 



13. Appendix III - Evaluation checklists for the SODIUM tools 

As per the internal SODIUM evaluation plan [5], a set of evaluation checklists will be provided 

for the pilot users in order to perform a technical and user acceptance evaluation for the main 

SODIUM tools. 

13.1 Visual Editor 


Criterion/Indicator Requirements Measurement tool Data collection method 

Heterogeneous 

service types 

Ability to model 

service operation calls 

to Web, Grid and P2P 

services 

Basic file handling Support for create, 

open, edit and print 


patterns 


parallel split, 

synchronization, 

exclusive choice, 

multiple choice, 

simple merge and 

discriminator 

Documentation Support for basic 

annotation and 

commenting 

functionality 

Standardized 

modeling language 

Should be based on a 

standard modeling 

language 

QoS Characteristics The ability to specify 

QoS properties of 

specific services as 

well as the QoS 

requirements of 

specific tasks 


constructs 

Support for task 

modeling, service 

operation modeling, 

input/output 

parameters and data 

transformations, start 


Parameter types Support for defining 

both syntactic and 

semantic types for 

Manual inspection Operational tests, trials 




Manual inspection Comparison with UML2 







Criterion/Indicator Requirements 

input/output 

parameters. 

Measurement tool Data collection method 

Timeouts Ability to specify Manual inspection Operational tests, trials 

maximum response 

time for a service 

Task hierarchy Support for specifying 


Graphical symbols Should be standardsbased 

Authentication 

constraints 

Basic editing 

functions 

13.2 USQL engine 



distinct 

authentications 

requirements for 

different service 

operations within the 

same composition 

Support for 

enabling/disabling 

sticky selection 


Compare with UML2 Comparison with UML2 





Response time < 20 seconds Log files Operational tests, trials 

Exception handling Transparency, 

effectiveness 

Security Authentication for 

administrators 

Interviews, Log files Operational tests, trials 

Interviews Operational tests 

Availability 24/7 Interviews Operational tests, trials 

Expandability Extensions must be 

easily accommodated 

Interviews Trials 

Maintainability On a monthly basis Interviews Trials 

Scalability 3 registries per query 

within accepted 

response time 

Log files Operational tests, trials 

Portability Install anywhere Interviews Operational tests 

User acceptance and impact analysis evaluation 


Usefulness Use of the engine Questionnaires Post-surveys 

within the development 

lifecycle 




Ease of 

understanding 

Novice users must be 

able to use the engine 

for service discovery 

Willingness to use Users must be willing 

to use the query engine 

during service 

composition 

Willingness to pay Users must be willing 

to pay in order to use 

the query engine 

Questionnaires Trials 

Interviews Pre-survey, Trials 

Interviews Post-surveys 



14. Appendix IV - Evaluation checklists for the SODIUM 

methodology 

As per the internal SODIUM evaluation plan [5], a checklist will be provided for the pilot users 

in order to perform an evaluation of the SODIUM methodology as follows: 



concrete 

compositions 

Bottom-up 

composition 

development 


services 


discovery 

Data 



task 




compositions of tasks 

without knowledge of 

existing services, and 

to select specific 

services for the tasks, 

and the ability to 

maintain this 

information in the 

same model 


compositions when 

the user knows 

exactly which services 

to use 

The ability to search 

for services 

The ability to define 

run-time queries, 

meaning that the 

search for a matching 

service is performed 

as part of the 

execution 

Support for defining 

data transformations 

between data objects 

Support to select 

several candidate 

services for a task 


strategy for final 

selection. 

Support for 

transformation 







Run, the transformation, 

deploy the result in 

USCL engine and 

execute it 

Operational tests, trials

D21 Evaluation and Assessment of the SODIUM Platform ... - ATC

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?