Stub and Skeleton Generation for a Single-Sign-On Webservice supporting dynamic Objects

Transcription

1 Stub and Skeleton Generation for a Single-Sign-On Webservice supporting dynamic Objects Jörg Ritter and Christian Stussak Martin-Luther-University Halle-Wittenberg, Halle 06120, Germany, joerg.ritter@informatik.uni-halle.de, christian.stussak@informatik.uni-halle.de, WWW home page: Abstract. In this paper we present a stub and skeleton generator supporting dynamic objects for a single-sign-on webservice. This generator could produce stubs and skeletons for PHP as well as Java clients. In the case of a java client the generator provides an almost transparent view as working with a local copy of the single-sign-on solution. The situation for PHP clients is almost transparent as well providing features like function overloading, inheritance, and comfortable exception handling. 1 Introduction In cooperation with a local radio station we develop a single-sign-on solution for their website. The radio station SPUTNIK[1] offers their listeners web-based tools to communicate with each other, like forum, chat, and image galleries. Furthermore one may subscribe to receive newsletters and playlists via SMS and/or . Therefore the listener has to register in order to use the provided services. After a successful registration process the radio station provides singlesign-on for all offered services. On the other hand each of the named services has its own user management and is written in different languages like PHP and Java. The conglomeration of services is a subject of change, so the integration of new services should be as easy as possible. For a complete single-sign-on solution we have to provide a central user management and have to modify the implementation of these services, replacing their built-in user management. We decided to use the webservice technology based on XML and the SOAP protocol. The single-sign-on webservice is served by the application server Tomcat[2] in conjunction with the Apache SOAP implementation Axis[3]. Under these premises a client may call procedures of the webservice with simple data types as formal parameters and receives those simple data types as well. Our contribution is the generation of stubs and skeletons in order to support dynamic objects as formal parameters and return values. The paper is organized as follows. In Section 2 we motivate why we use an object-oriented approach in conjunction with webservices. In Section 3 the gen-

2 2 erator for PHP and Java stubs and skeletons is described in detail. We conclude our contribution in Section 4. 2 Motivation We will motivate the need for the object oriented paradigm in combination with webservices using the following simple scenario. One of the elementary requests to a single-sign-on service is querying if an user is already logged in or not. A typical example for PHP using the built-in SOAP extension is shown in Figure 1. The main drawback of this solution is the absence of a hierarchical and object- $handle=new SoapClient( ); $user=$handle->find( username=foo ); $session=$handle->get_session($user); $login_state=$handle->get_state_of_session($session); Fig. 1. A simple example to obtain the login state of a registered user foo oriented structure. After each statement we must check for valid results which is error-prone and complicates the client integration (error and validity checks are omitted in the example due to simplicity). Furthermore we are restricted to simple data types and arrays of these simple types (classes and, respectively, structures could be used too, if appropriate serializer/deserializers are provided). The exchange of dynamic objects is not supported by the SOAP protocol. A first attempt to overcome this issue was the introduction of a dispatcher to handle the dynamic creation of remote objects. Such a dispatcher has to modify each method (and each constructor) of the API of the webservice if it contains a formal parameter which is not of type string nor a simple data type. The same holds for methods if their return value is not of type string nor a simple data type. In these cases we substitute the type of the formal parameter or the return value, respectively, with an integer which acts as an unique identifier. As an example, suppose our webservice provides access to the member function find() of a class ALV_user_factory 1 : class ALV_user { class ALV_user_factory { public ALV_user[] find( String search_string ) { ; The modified signature of this method will be: 1 ALV is the abbreviation of the german project name Anmelde-, Login- und Verwaltungssystem, a synonym for the single-sign-on solution developed in cooperation with the radio station SPUTNIK

3 3 public int[] find(int ALV_user_factory_id, String search_string ); The type of the return value is replaced by an array of integers representing unique identifiers to each object in the array. The additional parameter of type int identifies the instance of the class ALV_user_factory. If the function find is called via SOAP the dispatcher has to instantiate an object of the class ALV_user_factory, then call the member function find() with the given string parameter, store each of the resulting ALV_user objects in a hashtable, and return the corresponding array of identifiers. In Figure 2 the PHP code using such a dispatcher to obtain the information about the login state of user foo is shown. For simplicity reasons we omitted the error handling which is quite complex in that case. $handle = new SoapClient( ); $ALV_main_id = $handle->new( Alv ); $ALV_user_factory_id = $handle->get_user_factory($alv_main_id); $ALV_user_ids=$handle->find(ALV_user_factory_id, username=foo ); $ALV_session_factory_id=$handle->get_session_factory($ALV_main_id); $ALV_session_id= $handle->session_of_user($alv_session_factory_id, $ALV_user_ids[0]); $loginstate=$handle->get_state($alv_session_id); Fig. 2. An example to obtain the login state of a registered user foo using a dispatcher for dynamic objects. Note that the function new in line 2 creates a remote object of type Alv and return the corresponding identifier. The usage of such a dispatcher allows us to deal with dynamic objects but still has a lot of drawbacks. At first there will be naming conflicts, if two classes have methods with the same name. At second the support of dynamic objects requires the introduction of the object identifiers in each method, which complicates the client code and make it error-prone. To overcome this situation we will hide this code in a generated stub and skeleton. The user is provided with a common object-oriented API while the necessary details dealing with dynamic objects in conjunction with webservices are encapsulated and thus hidden. As a consequence we deliver a transparent solution in which the clients are able to interact with the webservice based on the underlying server-sided API. Figure 3 shows the client code using a generated PHP stub. The generation of those stubs and the corresponding skeletons is addressed in the following section in detail. 3 Stub and Skeleton Generator In order to generate stubs and skeletons one has to analyze the code of the given webservice. We have focused on webservices implemented in Java and are

4 4 try{ $handle = new SoapClient( ); $ALV_main = new Alv( $handle, config_file ); $ALV_user=$ALV_main->get_user_factory()->find( username=foo ); $ALV_session= $ALV_main->get_session_factory()->session_of_user($ALV_user); $loginstate=$alv_session->get_state(); catch(soapfault $fault) { trigger_error((faultcode: {$fault->faultcode, faultstring: {$fault->faultstring)", E_USER_ERROR); exit(); catch( ALV_Failure $failure ) { trigger_error((faultcode: {$fault->faultcode, faultstring: {$fault->faultstring)", E_USER_ERROR); exit(); Fig. 3. Obtaining the login state of a registered user foo using a generated stub for PHP clients. The object-orient approach keeps the code simple and easy to understand. utilizing the Java Reflection API[5]. The Java Reflection API allows us to retreive all the necessary information about the specific webservice implementation. The generator itself is written in Java, too. Before we explain the particularities in case of PHP and Java we give some universal statements which hold for both. The generator starts its analysis with a given list of super classes or interfaces (in our example the class Alv). For each such class or interface a corresponding class is generated for each stub. All constructors and methods are encapsulated in one single class which represents the skeleton. Naming conflicts are solved automatically by the generator. This skeleton is used for all the different stubs. If the generator finds a method where one of the parameters or the return value is not of simple type, the analyzing process is started recursively if the type belongs to the given list of packages. As a consequence we will support only dynamic objects of the Java packages from this list. Inheritance, Classes and Interfaces The generator is capable of generating PHP and Java stubs with the same class hierarchy as that of the webservice. A problem arises if formal parameters or the return values of methods are interfaces. At compile time we do not know, which class of those who implement this interface are returned or given as parameter. We consider the function find() once again as example: public ALV_user[] find( String search_string ) { ; Let us further assume that ALV_user is an interface or an abstract class. The implementation of find at the remote side will create several instances of objects

5 5 which implements the interface ALV_user. The dispatcher delivers only identifiers to those objects but the stub has to create an instance of ALV_user which is an interface or an abstract class, too. Since we can not instantiate interfaces nor abstract classes we convert them to classes in the stub implementation. Data types Another issue we have to deal with is the different data types provided by Java, PHP, and the SOAP protocol. In particular, the simple data type char is not supported by the SOAP protocol. Another example is the type byte and short which are not defined in PHP. A generalized approach would be a data type mapping between the webservice, the SOAP protocol, and the programming languages of the stubs[7]. For simplicity reasons we currently stop the generation process if the webservice under consideration makes use of data types which have no counterpart in the target language or in the SOAP protocol. Exception Handling Exception handling is another important aspect in conjunction with webservices. If we are able to use the built-in exception model of the stub programming language we avoid complicated error code handling. In the case that an exception is thrown within the remote service it is encoded as SOAP fault exception and transfered to the corresponding stub. The stub catches this exception itself. The error message of the exception is parsed for an embedded string, specifically encoded by the skeleton. If there is no such embedded string or we detect an exception of unknown type, the SOAP fault exception is thrown. Otherwise the embedded string is decoded and an exception of equal type and properties as on the remote side is thrown. 3.1 Java Stub Generation The generation of the stub for Java clients is based on the tool WSDL2Java[6]. It allows us to produce the Java stub code out of the WSDL description of the skeleton. The output generated by WSDL2Java is extended with the dispatcher functionality. With respect to the limitations described above the Java stub gives an almost transparent view to the webservice while dealing with dynamic objects. 3.2 PHP Stub Generation Function Overloading The PHP-SOAP extension does currently not support overloading of functions and methods. Nevertheless we can provide overloading since it is supported by PHP (PHP version > 5). If we detect overloaded functions in the webservice, we resolve those cases by generating unique names for each of the overloaded function while incorporating the formal parameters in the function name. The PHP stub can detect which function was called by using the built-in utilities is_int, is_string and so on. It then calls the generated function for the corresponding formal parameters. At the remote side the skeleton translates it back to the original function call. Figure 4 illustrates the basic idea.

6 6 class OL { function call( $method_name, $arg_list ) { if ($method_name == f and count( $arg_list ) == 1) { $p=$arg_list[0]; if (is_int($p)) { // formal parameter is int else if (is_string($p)) { // formal parameter is string else { // error, function f called with wrong paramter type else { // error, unknown function called Fig. 4. A simple example of solving overloading within PHP stubs. 4 Conclusion We have proposed a stub and skeleton generator for Java and PHP clients of a single-sign-on webservice supporting dynamic objects. Using automatically generated stubs we simplify the integration of client applications and provide an object-oriented approach. As shown above, exception handling facilities can be used transparently as well. Based on our approach the documentation of the single-sign-on service API could be used for all clients with minor restrictions, too. The modular structure of the generator allows us to support other client languages, as long as they communicate via the SOAP protocol. References 1. MDR SPUTNIK, Website of the radio station SPUTNIK, contact reimar.schmidtke@mdr.de. (last access: October, 23rd 2005) 2. The Apache Jakarta Project, Apache Tomcat - a servlet container. (last access: October 23rd 2005) 3. The Apache Webservices Project, Axis, an implementation of the SOAP ( Simple Object Access Protocol ) submission to W3C. (last access: October 23rd 2005) 4. Sun Microsystem, Java 2 Platform. (last access: October 23rd 2005) 5. Sun Microsystem, The Reflection API. (last access: October 23rd 2005) 6. The Apache Webservices Project, WSDL2Java: Building stubs, skeletons, and data types from WSDL. (last access: October 23rd 2005) 7. Markus L. Noga and Welf Löwe, Mapping Data Types of Programming Language and Web Services, 2nd Nordic Conference on Web Services, NCWS2003, Proceedings.