Hi Jonathan:
1. portability windows/linux
""I agree that this is important. While the remoting issue with binary
serialization prevents portability between the Mono and .NET, perhaps
XML serialization could be used as an option. If so, Mono/Linux and
.NET/Windows should work together.""
:: There is still however the problem of actual OS "binaries", i.e existing
pre-compiled legacy apps
which really wont run on both kinds of OS-es (Win/Linux), at the same time;
(unless we use a virtual machine of some sort... cygwin/wine etc..). This is important since a lot of
people are still planning to grid-ify their existing code/programs before thinking of designing
a program for the grid...ground up.
2. Web-services : really cross-platform: I dont think so.
""Another option is to take the web services route using SOAP. While
this *obviously* guarantees cross-platform execution, and happens to
be the way Globus is implemented, it seems to me that Alchemi will
take a serious performance hit from this approach.""
:: We , at GRIDS lab, Melb. Uni. work a lot on Globus and many other related distributed technologies and middleware, and
DO NOT find Globus to be that quick at all. Actually, Globus Toolkit 4 (the one which implements WSRF), a standard which brings
grids and web-services together, is really NOT entirely "web-services" based as
you noted:
i) Globus 4, does not have a Windows-based execution service/program.
That is, you can only run *nix programs on Globus, even with v.4
ii) The daemons which actually manage jobs on Linux are all still
compiled in C, and there is a lot of C code under those Java web-services
which are exposed via WSRF.
iii) Due to (i) and (ii) above, it is NOT cross-platform, in any way.
-- I can say, having worked with Globus v. 2,3,4 for more than an year and half, that the current web-services interface (not implementation: just external interface), only helps programmers using languages other than Java / C, to integrate a Globus grid into their programs. (For Java /C programmers, specific Globus APIs have been (and still are) available.
Having said that, Alchemi will ,in the future, implement a full WSRF
interface externally, so theoritically programs written "any"language
can access coarse-grained (GJob and file-based) execution using Alchemi
on Windows.
3. Alchemi's potential on *nix:
""However, getting Alchemi to run on the *nixes has huge potential, and
basically helps future-proof things. Microsoft's share of the desktop
platform has only one direction to go, and
popularity/user-friendliness of KDE/Gnome/OSX are steadily increasing.
Ideally we'd be able to get the Alchemi Executors running as daemons
on these machines, much as a service on Windows. ""
While it may be a good idea to have a single middleware which runs on (almost) "all" OS
platforms, it really may not be practical to have that. If you see the existing stuff available for
*nix, in terms of clustering /grids / distributed systems, you will see that they are quite
advanced. Globus, Unicore, PBS, SGE ...there's many production level products available. However,
we dont have a "thread"-programming model concept in any of these products, and that is
one area where Alchemi can help. Ideally, we would need to work out which is the best way to have
cross-platform compatibility using Alchemi, and perhaps plugging into one (or more) of these
existing technologies.
I am not sure about Microsoft's market share going down anytime soon, if at
all... One important area where the numbers of Linux PCs may matter in the
future is the corporate/enterprise: which is what Alchemi is aimed for anyway.
Expecting that we will have a lot of home desktops hooked up is not very
reasonable, I think. So, in the end, yes Linux compatibility is important. But,
again: it is not the first thing that needs to be done to improve / advance
Alchemi, according to me anyway...
Cheers
Krishna.
Message: 1
Date: Thu, 19 Jan 2006 23:14:16 -0600
From: Jonathan Mitchem <[EMAIL PROTECTED]>
To: metasharp <[EMAIL PROTECTED]>
Subject: Re: [Alchemi-developers] it is monday
Cc: [email protected]
MetaSharp -
Regarding your list of features:
- 1. running win32 c++ dlls on the grid too
This is already possible if they're ported to Managed C++, and use
GThread. However, without thread synchronization, not everything
ported will be able to work on the grid yet.
- 2. portability windows/linux
I agree that this is important. While the remoting issue with binary
serialization prevents portability between the Mono and .NET, perhaps
XML serialization could be used as an option. If so, Mono/Linux and
.NET/Windows should work together.
Another option is to take the web services route using SOAP. While
this *obviously* guarantees cross-platform execution, and happens to
be the way Globus is implemented, it seems to me that Alchemi will
take a serious performance hit from this approach.
However, getting Alchemi to run on the *nixes has huge potential, and
basically helps future-proof things. Microsoft's share of the desktop
platform has only one direction to go, and
popularity/user-friendliness of KDE/Gnome/OSX are steadily increasing.
Ideally we'd be able to get the Alchemi Executors running as daemons
on these machines, much as a service on Windows.
(At some point in time, I'll have a second dedicated Linux machine
that I can use for cross-platform development and testing.)
- 3. bug fixing
When you come across a bug, or bugs, please document them in email, or
better yet, put them on Sourceforge:
https://sourceforge.net/tracker/?func=3Dbrowse&group_id=3D66729&atid=3D5155=
36
Working from a known bug list, and checking off items as they complete
helps guarantee that things are visible and can be taken care of. It
also helps reduce duplication of errors. People can add comments and
more details to existing bugs.
- 4. architecture (re)design
How would you like to see things redesigned?
- 5. new features
Such as?
Jonathan Mitchem
On 1/16/06, metasharp <[EMAIL PROTECTED]> wrote:
hello friends,
it's monday, the sun is shining and so on.
1. could mailing list admin prevent the spam related to bank and other
non alchemi mails we receive please?
2. about windows 2003 issue i can't tell much more than this:
- alchemi 1.0 was downloaded from the web site friday
- same day i installed it both executor + manager on the same computer
running win2003
- i could start the manager that successfully connected to the
MSDE2000A sql server running also on the same computer
- i started the executor but it could connect to the manager giving
immediately a message: "can't connect the executor" or something
without any wait between the moment you push the button and the error
message (making me think it's not network protocol related)
- computers with windows 2003 have been removed from my company today
so i can't go into further investigation at the moment
3. about mono and why i think it's important:
- companies wanting to build grids deeply desire in that matter to
minimize the costs
- in that matter they have 2 approaches: using existing park and/or
bring new resources
- using the existing park will run on like 90% windows / 10% free os (lin=
ux)
- bringing new resources will be 99% free os (linux) / 1% windows
- mono makes dotnet running on windows/linux/mac/(bsd?)/...
- this is the only way to have a free os + free soft running in dotnet
- this is why companies would give a try to alchemi
- is it important? depends. my company wants a free os + free grid
system for example that could run our libraries (win32 c++ actually)
- i don't think it's actually possible with alchemi at the moment
4. new subject: the remoting
- while it's certainly usefull for anything related to dotnet dlls, do
you think as it to be the fastest network option we have (i don't know
myself)?
- wouldn't it nice to have alchemi only using c# fonctionnalities 100%
compatible with both microsoft dotnet framework and mono so that we
could build it with any on them?
5. win32 dlls:
- is there any way to run win32 (c++) dlls on alchemi?
- maybe we could write a dotnet wrapper or a c++ api? do you think it's w=
ise?
6. things that are important to me for alchemi's future:
- 1. running win32 c++ dlls on the grid too
- 2. portability windows/linux
- 3. bug fixing
- 4. architecture (re)design
- 5. new features
Well these were my morning thoughts. Have a nice day.
--
MetaSharp
Message: 2 Date: Fri, 20 Jan 2006 00:51:58 -0600
From: Jonathan Mitchem <[EMAIL PROTECTED]>
To: [email protected],
[email protected]
Subject: [Alchemi-developers] ASP.NET with Alchemi
Anyone tried making an ASP.NET application using Alchemi?
A neat example would be to port the Mandelbrot example to be web
based, where each processing piece would be a separate image and
written to a file, and the resulting image is a composite of all these
smaller images put together with an html table.
But really, I'm really just curious if it [ASP.NET w/Alchemi] works.
Jonathan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Alchemi-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/alchemi-developers
