Yes, that’s what I thought as well.
We can use Factory methods to
instantiate objects for the platform and work with interfaces.
e.g. Something like:
Mutex mutx = MutexAbstractionFactory.create();
//we do not specify the platform as a argument to create, but it’s
implicit.
And for each platform Mutex can be
implemented using OS kernel APIs.
From: John Hawkins
[mailto:[EMAIL PROTECTED]
Sent: Monday, May 23, 2005 3:00 AM
To: Apache
AXIS C Developers List
Subject: RE: Platform abstraction
layer thoughts
I think you're possibly more right than me ;-) I guess
one does say "get me a Mutex" rather than saying "Get me a
platform object and then get the mutex for that platform".
|
Nadir Amra
<[EMAIL PROTECTED]>
21/05/2005 21:44
|
Please
respond to
"Apache AXIS C Developers List"
|
|
|
To
|
"Apache AXIS C
Developers List" <[email protected]>
|
|
cc
|
|
|
Subject
|
RE: Platform abstraction layer thoughts
|
|
Lilantha,
I assume you are agreeing with me? That is,
these should all be objects
with methods, not one big class with single calls.
John,
I prefer my implementation since these mutexes,
threads, sockets, are
classes with methods. Each should be
self-contained. The implementation
does not preclude you from inheriting from the
default implementation and
implementing or extending a class. More
in-line with object oriented
coding. I would agree with your method if it
was simply one-time function
calls to achieve something. But that is not
the case for mutexes,
sockets, etc.
Nadir K. Amra
"Lilantha Darshana"
<[EMAIL PROTECTED]> wrote on 05/20/2005
01:16:43 PM:
> 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.
>
>
>
>
> thanks
> -Lilantha
>
> 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"
>
> To
>
> [email protected]
>
> cc
>
>
>
> Subject
>
> Platform abstraction layer thoughts
>
>
>
>
>
>
>
>
>
>
> 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
> _______________
> Siebel
> IT'S ALL ABOUT THE CUSTOMER
> Visit www.siebel.com
>
> 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.
