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.
|
3
|
Service
|
Axis engine etc
|
|
2
|
common
|
General - broadest
applicability that helps Axis engine e.g. XML parsing
|
|
1
|
Language
|
Code that effectively
extends C/C++ (e.g. extending string operation functions or way to handle
introspection in C++ etc.).
|
|
0
|
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
[mailto:[EMAIL PROTECTED]
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.
PlatformSpecificWindowsUtils
#doMutexStuff()
# getErrorMessage()
etc.
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
<[EMAIL PROTECTED]>
18/05/2005 22:33
|
Please
respond to
"Apache AXIS C Developers List"
|
|
|
My
thoughts on the platform abstractions layer is as follows. Note that I
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: DLL
loading, mutex, socket, and obtaining OS errors.
There may be more (such
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
later.
The idea is to have classes for the various
platform-specific stuff. The
header files and default implementation would be
in platforms/ directory
as follows:
platforms/AxisPsLibraryLoader.hpp
platforms/AxisPsLibraryLoader.cpp
platforms/AxisPsMutex.hpp
platforms/AxisPsMutex.cpp
platforms/AxisPsSocket.hpp
platforms/AxisPsSocket.cpp
platforms/AxisPsOSError.hpp
platforms/AxisPsOSError.cpp
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,
axis_platformservices.so. 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:
platforms/os400/AxisPsLibraryLoader.cpp
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
platforms/AxisPsOSError.cpp.
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 stuff
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 and
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 the
make would fail unless someone updates the
makefile.
For stage three, if we still want to go to APR,
the default implementation
can be changed to use the APR APIs, and if a
platform wants to go that way
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
