axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lilantha Darshana" <>
Subject RE: Platform abstraction layer thoughts
Date Fri, 20 May 2005 18:16:43 GMT
I think this is what we discussed when we were originally discussing
this idea - PAL

I believe, object oriented model is the way to go.


Additionally layered architecture simplifies the design. As if we follow
the following model of layering.

Here, zero-th layer is the platform abstraction layer.




Axis engine etc



General - broadest applicability that helps Axis engine e.g. XML parsing



Code that effectively extends C/C++ (e.g. extending string operation
functions or way to handle introspection in C++ etc.).



Environment or platform

Per environment/configuration (PAL - Platform Abstraction Layer) 

e.g. specializations to support: 

mutexes, library loading, socket/stream, memory management, error/signal
handling, threading etc.







From: John Hawkins [] 
Sent: Thursday, May 19, 2005 5:45 AM
To: Apache AXIS C Developers List
Subject: Re: Platform abstraction layer thoughts


Ohh - hadn't thought of creating classes for the functions. 

I'd thought that we'd have classes for each platform and those classes
would have methods for the function e.g. 

        # getErrorMessage() 


Then we would have a hierarchy of PlatformSpecific classes as in the
attached file. 

This would mean that if all Unix platforms are the same then only the
base UnixPlatformSpecific class has to implement it. 

This model still gives the ability to override the methods with APR or
non-APR versions. 

I think we've fundamentally got the same idea but you're making
functions the classes whereas I'm putting the function into platform
specific classes (which happens to be more like what we have today). 

Nadir Amra <> 

18/05/2005 22:33 

Please respond to
"Apache AXIS C Developers List"





Platform abstraction layer thoughts




My thoughts on the platform abstractions layer is as follows.  Note that
will initially focus on the client-side of things, but I hope to also 
eventually get to the server side to see what needs to be abstracted.

Just to level-set, the goal is to attempt to concentrate as much as 
possible any platform differences in one area - code will be located in 
the platforms/ directory.  There occasionally will be times when this 
cannot be done, but hopefully those occasions will be few and any 
platform-specific code changes required outside of platforms/ directory 
will be minimal. 

I have initially identified several areas that need to be abstracted:
loading, mutex, socket, and obtaining OS errors.  There may be more
as event log for FFDC kinds of stuff - on Unix maybe syslog() will be 
used, on windows to the event log), but that will be identified and done


The idea is to have classes for the various platform-specific stuff.
header files and default implementation would be in platforms/ directory

as follows:


The default implementation of these classes will be patterned after Unix

and packaged in a DLL/share library called, for lack of a better name,   The AXIS engine will need to link to this 
DLL/shared library and thus it will need to be created first prior to 
creating any other DLLs/shared libraries.

The implementation code for other platforms will be in each platform 
directory.  For example, OS/400 will need to have its own 
AxisPsLibraryLoader.cpp file so one will be located as follows:


When building the  axis_platformservices DLL/shared library, which files

are build is dependent on the platform.  For example, OS/400 would build

everything in platforms/os400/ and would also build 
platforms/AxisPsMutex.cpp, platforms/AxisPsSocket.cpp and 

The creation of the classes and implementation will be done as part of 
stage one.  I will also attempt to modify the ant build scripts to build

the DLL/shared library.  However, I have no expertise with makefiles so 
someone would need to do that.  Stage one would just be putting the
in CVS and for all of you to look at and comment on.  Everything should 
still build as it does now.

Stage two would be to change the Axis engine to use the above classes
link to the service program.  Again, someone would need to volunteer to 
update makefiles.  At this point in time the ant build would work but
make would fail unless someone updates the makefile.

For stage three, if we still want to go to APR, the default
can be changed to use the APR APIs, and if a platform wants to go that
they can, otherwise, a platform can still have its own implementation of

the classes.  This will protect platforms that may not have all the APR 
APIs, or do not have APR at all.

So what do you think? 

Nadir K. Amra


This e-mail message is for the sole use of the intended recipient(s) and contains confidential
and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners.
Any unauthorized review, use, copying, disclosure or distribution of this message is strictly
prohibited. If you are not an intended recipient of this message, please contact the sender
by reply e-mail and destroy all soft and hard copies of the message and any attachments. Thank
you for your cooperation.

View raw message