New client configuration API

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

New client configuration API

hawkeye

Hi Folks,

we'd like to implement a new API for configuration of the client-side.

I've written a vrief synopsis of what is there to day and what we'd like to do..........


The environment variable is AXISCPP_DEPLOY. This variable is used by the configuration system to look up a file called axiscpp.conf. This file consists of the following:

#ClientLogPath:                 The path to the axis client log
#ClientWSDDFilePath:         The path to the client wsdd
#XMLParser:                 The xml parser library
#Transport_http:                 The HTTP transport library
#Channel_HTTP:                 The HTTP transport channel library
#Channel_HTTP_SSL:         The HTTP transport secure channel library

This data can be placed in a new configuration Object with the following signature (Pseudo)

AxisCPP_Configuration
{
        get/set ClientLog(String);
        get/set ClientWSDDFile(String);
get/set XMLParserLibrary(String);
get/set TransportLibrary(String);
get/set HTTPChannelLibrary(String);
get/set HTTPSSLChannelLibrary(String);
}

A new Web Service constructor will be created that takes in an AxisCPP_Configuration object. This constructor will be in addition to the current range of constructors that are created for each service.

The user may create a web service using the constructor. However, if they attempt to use the constructor with a configuration object more than once in any given process the configuration object will be ignored i.e. the engine can only be configured once per process.


Client WSDD files will still be required and no new API will be introduced for them.


thoughts please?


thanks,
john.
Reply | Threaded
Open this post in threaded view
|

Re: New client configuration API

John Kelly




John,

A couple of minor suggestions

a) ClientLogPath

Might be nice if you could pass a file_handle so the output could go to
places like sdtout or stderr

b) ClientWSDDFile

Might be nice if you could pass a file_handle so the input could come
places like stdin

Might also be nice if one could optionally pass the equivalent of the file
contents in as a string, rather than just a file name. The program could
then build up the configuration programmatically removing the need for
deploying a separate file.

c) Library names

Might be nice if all the library names on the different platforms had a
standardised naming convention like
HTTP_channel.dll and libHTTP_channel.so, then you could have the
axiscpp.conf and the api take a short form of the shared library name, so
the method setHTTPChannelLibrary("HTTP_channel"); would be platform neutral
and the client would look for HTTP_channel.dll on the PATH on Windows or
libHTTP_channel.so on the LD_LIBRARY_PATH on Linux.

regards
John


                                                                           
             John                                                          
             Hawkins/UK/IBM@IB                                            
             MGB                                                        To
                                       [hidden email]            
             06/05/2005 14:39                                           cc
                                                                           
                                                                   Subject
             Please respond to         New client configuration API        
              "Apache AXIS C                                              
             Developers List"                                              
                                                                           
                                                                           
                                                                           
                                                                           





Hi Folks,

we'd like to implement a new API for configuration of the client-side.

I've written a vrief synopsis of what is there to day and what we'd like to
do..........


The environment variable is AXISCPP_DEPLOY. This variable is used by the
configuration system to look up a file called axiscpp.conf. This file
consists of the following:

#ClientLogPath:                 The path to the axis client log
#ClientWSDDFilePath:         The path to the client wsdd
#XMLParser:                 The xml parser library
#Transport_http:                 The HTTP transport library
#Channel_HTTP:                 The HTTP transport channel library
#Channel_HTTP_SSL:         The HTTP transport secure channel library

This data can be placed in a new configuration Object with the following
signature (Pseudo)

AxisCPP_Configuration
{
        get/set ClientLog(String);
        get/set ClientWSDDFile(String);
get/set XMLParserLibrary(String);
get/set TransportLibrary(String);
get/set HTTPChannelLibrary(String);
get/set HTTPSSLChannelLibrary(String);
}

A new Web Service constructor will be created that takes in an
AxisCPP_Configuration object. This constructor will be in addition to the
current range of constructors that are created for each service.

The user may create a web service using the constructor. However, if they
attempt to use the constructor with a configuration object more than once
in any given process the configuration object will be ignored i.e. the
engine can only be configured once per process.


Client WSDD files will still be required and no new API will be introduced
for them.


thoughts please?


thanks,
john.

Reply | Threaded
Open this post in threaded view
|

RE: New client configuration API

Carsten Blecken
In reply to this post by hawkeye
Excellent idea! +1
 
The only suggestion I have is that would be hesitant to set the configuration per service
constructor. The configuration is typically done globally on a per process basis and there should
be an option to do it globally and programmatically.
For example adding a method to Axis.cpp:
 
static void Axis::setConfig(AxisCPP_Configuration conf);
 
which sets g_pConfig.
 
My 2c,
 
Carsten
 
 
 
-----Original Message-----
From: John Hawkins [mailto:[hidden email]]
Sent: Friday, May 06, 2005 6:40 AM
To: [hidden email]
Subject: New client configuration API


Hi Folks,

we'd like to implement a new API for configuration of the client-side.

I've written a vrief synopsis of what is there to day and what we'd like to do..........


The environment variable is AXISCPP_DEPLOY. This variable is used by the configuration system to look up a file called axiscpp.conf. This file consists of the following:

#ClientLogPath:                 The path to the axis client log
#ClientWSDDFilePath:         The path to the client wsdd
#XMLParser:                 The xml parser library
#Transport_http:                 The HTTP transport library
#Channel_HTTP:                 The HTTP transport channel library
#Channel_HTTP_SSL:         The HTTP transport secure channel library

This data can be placed in a new configuration Object with the following signature (Pseudo)

AxisCPP_Configuration
{
        get/set ClientLog(String);
        get/set ClientWSDDFile(String);
get/set XMLParserLibrary(String);
get/set TransportLibrary(String);
get/set HTTPChannelLibrary(String);
get/set HTTPSSLChannelLibrary(String);
}

A new Web Service constructor will be created that takes in an AxisCPP_Configuration object. This constructor will be in addition to the current range of constructors that are created for each service.

The user may create a web service using the constructor. However, if they attempt to use the constructor with a configuration object more than once in any given process the configuration object will be ignored i.e. the engine can only be configured once per process.


Client WSDD files will still be required and no new API will be introduced for them.


thoughts please?


thanks,
john.
Reply | Threaded
Open this post in threaded view
|

Re: New client configuration API

TimBartley
In reply to this post by hawkeye

I would really like to see this implemented in conjunction with solving the multiple instances per process problem.

i.e have I guess something like:

class Axis;

Axis* Axis::initialize(AxisCPP_Configuration*  config, bool isServer);

and then have the Web service constructors accept an "Axis" object rather than just an AxisCPP_Configuration object to their constructors.

The Axis object would encapsulate all of the current global variables - it should be opaque.

In order to avoid having to pass an Axis* everywhere, maybe a first approximation of this would be to set an Axis* as thread-local-storage. Yuck but may be quicker implementation - the top level interfaces could be set up to have the final interface including an Axis* and this would allow a more gradual propagation of the change.

Regards,

Tim
--
IBM Tivoli Access Manager Development
Gold Coast Development Lab, Australia
+61-7-5552-4001 phone
+61-7-5571-0420 fax



John Hawkins <[hidden email]>

06/05/2005 23:39

Please respond to
"Apache AXIS C Developers List"

To
[hidden email]
cc
Subject
New client configuration API






Hi Folks,


we'd like to implement a new API for configuration of the client-side.


I've written a vrief synopsis of what is there to day and what we'd like to do..........



The environment variable is AXISCPP_DEPLOY. This variable is used by the configuration system to look up a file called axiscpp.conf. This file consists of the following:


#ClientLogPath:                 The path to the axis client log

#ClientWSDDFilePath:         The path to the client wsdd

#XMLParser:                 The xml parser library

#Transport_http:                 The HTTP transport library

#Channel_HTTP:                 The HTTP transport channel library

#Channel_HTTP_SSL:         The HTTP transport secure channel library


This data can be placed in a new configuration Object with the following signature (Pseudo)


AxisCPP_Configuration

{

       get/set ClientLog(String);

       get/set ClientWSDDFile(String);

get/set XMLParserLibrary(String);

get/set TransportLibrary(String);

get/set HTTPChannelLibrary(String);

get/set HTTPSSLChannelLibrary(String);

}


A new Web Service constructor will be created that takes in an AxisCPP_Configuration object. This constructor will be in addition to the current range of constructors that are created for each service.


The user may create a web service using the constructor. However, if they attempt to use the constructor with a configuration object more than once in any given process the configuration object will be ignored i.e. the engine can only be configured once per process.



Client WSDD files will still be required and no new API will be introduced for them.



thoughts please?



thanks,

john.

Reply | Threaded
Open this post in threaded view
|

Re: New client configuration API

TimBartley
In reply to this post by John Kelly

I agree with all of these points.

Regards,

Tim
--
IBM Tivoli Access Manager Development
Gold Coast Development Lab, Australia
+61-7-5552-4001 phone
+61-7-5571-0420 fax



John Kelly <[hidden email]>

07/05/2005 00:17

Please respond to
"Apache AXIS C Developers List"

To
"Apache AXIS C Developers List" <[hidden email]>
cc
Subject
Re: New client configuration API









John,

A couple of minor suggestions

a) ClientLogPath

Might be nice if you could pass a file_handle so the output could go to
places like sdtout or stderr

b) ClientWSDDFile

Might be nice if you could pass a file_handle so the input could come
places like stdin

Might also be nice if one could optionally pass the equivalent of the file
contents in as a string, rather than just a file name. The program could
then build up the configuration programmatically removing the need for
deploying a separate file.

c) Library names

Might be nice if all the library names on the different platforms had a
standardised naming convention like
HTTP_channel.dll and libHTTP_channel.so, then you could have the
axiscpp.conf and the api take a short form of the shared library name, so
the method setHTTPChannelLibrary("HTTP_channel"); would be platform neutral
and the client would look for HTTP_channel.dll on the PATH on Windows or
libHTTP_channel.so on the LD_LIBRARY_PATH on Linux.

regards
John


                                                                         
            John                                                          
            Hawkins/UK/IBM@IB                                            
            MGB                                                        To
                                      [hidden email]            
            06/05/2005 14:39                                           cc
                                                                         
                                                                  Subject
            Please respond to         New client configuration API        
             "Apache AXIS C                                              
            Developers List"                                              
                                                                         
                                                                         
                                                                         
                                                                         





Hi Folks,

we'd like to implement a new API for configuration of the client-side.

I've written a vrief synopsis of what is there to day and what we'd like to
do..........


The environment variable is AXISCPP_DEPLOY. This variable is used by the
configuration system to look up a file called axiscpp.conf. This file
consists of the following:

#ClientLogPath:                 The path to the axis client log
#ClientWSDDFilePath:         The path to the client wsdd
#XMLParser:                 The xml parser library
#Transport_http:                 The HTTP transport library
#Channel_HTTP:                 The HTTP transport channel library
#Channel_HTTP_SSL:         The HTTP transport secure channel library

This data can be placed in a new configuration Object with the following
signature (Pseudo)

AxisCPP_Configuration
{
       get/set ClientLog(String);
       get/set ClientWSDDFile(String);
get/set XMLParserLibrary(String);
get/set TransportLibrary(String);
get/set HTTPChannelLibrary(String);
get/set HTTPSSLChannelLibrary(String);
}

A new Web Service constructor will be created that takes in an
AxisCPP_Configuration object. This constructor will be in addition to the
current range of constructors that are created for each service.

The user may create a web service using the constructor. However, if they
attempt to use the constructor with a configuration object more than once
in any given process the configuration object will be ignored i.e. the
engine can only be configured once per process.


Client WSDD files will still be required and no new API will be introduced
for them.


thoughts please?


thanks,
john.


Reply | Threaded
Open this post in threaded view
|

Re: New client configuration API

hawkeye
In reply to this post by TimBartley

Hi Tim,

I'm a little confused you seem to be adressing a slightly different issue?

I understand that it's beneficial to create a system without globals (static objects). What are the issues today - is it just the config that's static and causing us not to have this model?

Why have the isServer boolean? What is it you're trying to achieve?

cheers,
John.





Tim Bartley <[hidden email]> wrote on 09/05/2005 00:43:00:

>
> I would really like to see this implemented in conjunction with
> solving the multiple instances per process problem.
>
> i.e have I guess something like:
>
> class Axis;
>
> Axis* Axis::initialize(AxisCPP_Configuration*  config, bool isServer);
>
> and then have the Web service constructors accept an "Axis" object
> rather than just an AxisCPP_Configuration object to their constructors.
>
> The Axis object would encapsulate all of the current global
> variables - it should be opaque.
>
> In order to avoid having to pass an Axis* everywhere, maybe a first
> approximation of this would be to set an Axis* as thread-local-
> storage. Yuck but may be quicker implementation - the top level
> interfaces could be set up to have the final interface including an
> Axis* and this would allow a more gradual propagation of the change.
>
> Regards,
>
> Tim
> --
> IBM Tivoli Access Manager Development
> Gold Coast Development Lab, Australia
> +61-7-5552-4001 phone
> +61-7-5571-0420 fax
>

>
> John Hawkins <[hidden email]>

> 06/05/2005 23:39
>
> Please respond to
> "Apache AXIS C Developers List"

>
> To

>
> [hidden email]

>
> cc

>
> Subject

>
> New client configuration API

>
>
>
>
>
> Hi Folks,
>
> we'd like to implement a new API for configuration of the client-side.
>
> I've written a vrief synopsis of what is there to day and what we'd
> like to do..........
>
>
> The environment variable is AXISCPP_DEPLOY. This variable is used by
> the configuration system to look up a file called axiscpp.conf. This
> file consists of the following:
>
> #ClientLogPath:                 The path to the axis client log
> #ClientWSDDFilePath:         The path to the client wsdd
> #XMLParser:                 The xml parser library
> #Transport_http:                 The HTTP transport library
> #Channel_HTTP:                 The HTTP transport channel library
> #Channel_HTTP_SSL:         The HTTP transport secure channel library
>
> This data can be placed in a new configuration Object with the
> following signature (Pseudo)
>
> AxisCPP_Configuration
> {
>        get/set ClientLog(String);
>        get/set ClientWSDDFile(String);
> get/set XMLParserLibrary(String);
> get/set TransportLibrary(String);
> get/set HTTPChannelLibrary(String);
> get/set HTTPSSLChannelLibrary(String);
> }
>
> A new Web Service constructor will be created that takes in an
> AxisCPP_Configuration object. This constructor will be in addition
> to the current range of constructors that are created for each service.
>
> The user may create a web service using the constructor. However, if
> they attempt to use the constructor with a configuration object more
> than once in any given process the configuration object will be
> ignored i.e. the engine can only be configured once per process.
>
>
> Client WSDD files will still be required and no new API will be
> introduced for them.
>
>
> thoughts please?
>
>
> thanks,
> john.
Reply | Threaded
Open this post in threaded view
|

RE: New client configuration API

Samisa Abeysinghe
In reply to this post by hawkeye

+1. Excellent design

 

BTW, what is the rationale for “the engine can only be configured once per process”?

 

Also, in addition to the current settings supported by the conf file, there has been some Jira issues raised for setting proxy, username/password etc. in the conf file, so hopefully they too will be supported by AxisCPP_Configuration

 

Also it looks to me as if “AxisCPP_Configuration” is designed for client side – what about the server side? Could server side use the same? (I think we could possibly extend it – may be we should have a class hierarchy here, where the base would have common conf items and derived ounces have server/client specific stuff. E.g. XML parser setting is common, HTTP channel is not)

 

     AxisCPPConfiguration

                                             |

                                             |

                                            / \

                                          /     \

AxisCPPClientConfiguration          AxisCPPServerConfiguration

 

 

Thanks,

Samisa…

 

-----Original Message-----
From: John Hawkins [mailto:[hidden email]]
Sent
:
Friday, May 06, 2005 7:40 PM
To: [hidden email]
Subject: New client configuration API

 


Hi Folks,

we'd like to implement a new API for configuration of the client-side.

I've written a vrief synopsis of what is there to day and what we'd like to do..........


The environment variable is AXISCPP_DEPLOY. This variable is used by the configuration system to look up a file called axiscpp.conf. This file consists of the following:

#ClientLogPath:                 The path to the axis client log
#ClientWSDDFilePath:         The path to the client wsdd
#XMLParser:                 The xml parser library
#Transport_http:                 The HTTP transport library
#Channel_HTTP:                 The HTTP transport channel library
#Channel_HTTP_SSL:         The HTTP transport secure channel library

This data can be placed in a new configuration Object with the following signature (Pseudo)

AxisCPP_Configuration
{
        get/set ClientLog(String);
        get/set ClientWSDDFile(String);
get/set XMLParserLibrary(String);
get/set TransportLibrary(String);
get/set HTTPChannelLibrary(String);
get/set HTTPSSLChannelLibrary(String);
}

A new Web Service constructor will be created that takes in an AxisCPP_Configuration object. This constructor will be in addition to the current range of constructors that are created for each service.

The user may create a web service using the constructor. However, if they attempt to use the constructor with a configuration object more than once in any given process the configuration object will be ignored i.e. the engine can only be configured once per process.


Client WSDD files will still be required and no new API will be introduced for them.


thoughts please?


thanks,
john.