adequate
adequate
adequate
adequate
 

JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net
JPPF

The open source
grid computing
solution

 Home   About   Features   Download   Documentation   Forums 
October 23, 2018, 11:28:10 AM *
Welcome,
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: Some OGSA ideas  (Read 6152 times)

dcreado

  • Guest
Some OGSA ideas
« on: July 05, 2006, 12:43:08 AM »

After reading some specs and papers about OGSA and Globus, I was thinking if we could be compatible with OGSA.
The force that drives me towards OGSA is to open the possibility of reusing some components developt to this model to run it in JPPF "grid", like Coherence (as they say they are compliant with that) or OGSA-DAI (a very powerfull distributed query processor) and other ones...
Also the integration of Legion and Globus seems to me as the way to get JPPF running in really big grid...
I'm not sure about how far the concepts are away from OGSA, but your deploy strategy is far from that...
Please let me know what you are thinking...
Cheers
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2241
    • JPPF Web site
Some OGSA ideas
« Reply #1 on: July 05, 2006, 01:26:51 AM »

Hmmm, I'm not sure about this.
I believe that what makes JPPF far from the Globus model is also what makes it attractive and interesting.
My fear is that if we perform that kind of integration, JPPF will lose most of its flexibility and ease of use, so what's the point, what's going to distinguish it from any other grid toolkit?
Sure, JPPF doesn't implement many standards (if any) for parallel processing, like MPI, OGSA, etc... JPPF does not even implement the traditional notion of "job".
Instead, what we have is the concept of task, which can be made as coarse as a job, or as granular as we want them.
Another difference: JPPF is for Java only, which makes it language dependant, but platform independant. The same task can run on Linux, Windows, zOS, Macintosh without a single change or recompilation. Traditional "jobs" generally involve some executable + shell script combination, plus at least one deployment step (like uploading to an ftp folder). No suchg thing with JPPF, and that's what I want to preserve.

Yet another thing, JPPF addresses a community of users and developers that's generally treated as "second rate" in the grid computing area, namely the Java community. Well, last I heard, it was still a huge number of people and organizations.
So what, not everyone is going to use JPPF? That's fine with me, as long as not everyone is using Globus, or Sun's Grid Engine, or Condor, or any single toolkit.
To me, that's the true meaning of the freedom of open source: the freedom of choice.

That's why at home, when I work on JPPF, I can choose to do it on Windows, or on one of many flavors of Linux, however I feel at the moment. I like having a choice.

So, it may seem like a narrow vision of what we're trying to accomplish, but I believe otherwise. I believe it is always good to look for new ways, to try to think outside the box, to try to do something better some way, rather than just apply standards and patterns. I do prefer a user-oriented product over a standard-oriented one every time. To me, JPPF is more a research project than a commercial venture, but one does not exclude the other, and none prevents us from using sound engineering principles.
Logged

dcreado

  • Guest
Some OGSA ideas
« Reply #2 on: July 05, 2006, 03:34:20 AM »

Quote from: "lolocohen"

I believe that what makes JPPF far from the Globus model is also what makes it attractive and interesting.
My fear is that if we perform that kind of integration, JPPF will lose most of its flexibility and ease of use, so what's the point, what's going to distinguish it from any other grid toolkit?

Just what you had already said: the easy of use.
But did you have already thought that JPPF is easy to use for just very simple things?

Quote from: "lolocohen"

Sure, JPPF doesn't implement many standards (if any) for parallel processing, like MPI, OGSA, etc... JPPF does not even implement the traditional notion of "job".
Instead, what we have is the concept of task, which can be made as coarse as a job, or as granular as we want them.

We could use a Wrapper task around any submission that other domains send to a JPPF cluster.

Quote from: "lolocohen"

Another difference: JPPF is for Java only, which makes it language dependant, but platform independant. The same task can run on Linux, Windows, zOS, Macintosh without a single change or recompilation. Traditional "jobs" generally involve some executable + shell script combination, plus at least one deployment step (like uploading to an ftp folder). No suchg thing with JPPF, and that's what I want to preserve.

That's the point... we don't have to drop this simplicity. Having a task that wraps a running process at OS could be nice.
We can have a descriptor for each machine submitted to Driver, stating the capabilities of it like: running OS processes, having X Mb of disk available, running Linux, and so on.
Quote from: "lolocohen"

Yet another thing, JPPF addresses a community of users and developers that's generally treated as "second rate" in the grid computing area, namely the Java community. Well, last I heard, it was still a huge number of people and organizations.


That is pointless... the GT4 is almost entire wrote in java, so is ourgrid (http://www.ourgrid.org), Integrade (http://www.integrade.org), and AppLes (http://apples.ucsd.edu/) for example.

Quote from: "lolocohen"

So what, not everyone is going to use JPPF? That's fine with me, as long as not everyone is using Globus, or Sun's Grid Engine, or Condor, or any single toolkit.
To me, that's the true meaning of the freedom of open source: the freedom of choice.

That's why at home, when I work on JPPF, I can choose to do it on Windows, or on one of many flavors of Linux, however I feel at the moment. I like having a choice.

So, it may seem like a narrow vision of what we're trying to accomplish, but I believe otherwise. I believe it is always good to look for new ways, to try to think outside the box, to try to do something better some way, rather than just apply standards and patterns. I do prefer a user-oriented product over a standard-oriented one every time.

I'm not asking to make the Reference Implementation of OGSA ;-)
Quote from: "lolocohen"

To me, JPPF is more a research project than a commercial venture, but one does not exclude the other, and none prevents us from using sound engineering principles.

Does not implementing OGSA seems to be a research?
If this if not a research topic we might create a list of topics to better split the job and make the develop more agile.
Logged

lolo

  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2241
    • JPPF Web site
Some OGSA ideas
« Reply #3 on: July 05, 2006, 10:18:14 AM »

Quote from: "dcreado"
But did you have already thought that JPPF is easy to use for just very simple things?

That's a good question. Personally, I use JPPF to evolve populations of neural nets, and that doesn't seem simple to me. I like the fact that the complexity of my AI code stays there, and doesn't bleed on how to use JPPF to make it run. Am I being naive?
It is true that JPPF doesn't yet do things like processing tasks with inter-dependencies. That qualifIes a class of problems, not necessarily their complexity.
So, I agree, let's work on that. I'm well aware there's a lot of things JPPF doesn't do, and I'm always glad when there's more coming on the horizon.

Quote from: "dcreado"
We could use a Wrapper task around any submission that other domains send to a JPPF cluste

Excellent! I'd been thinking along these lines as well. Let's make it an additional capability for JPPF, not the only one.

Quote from: "dcreado"
That is pointless... the GT4 is almost entire wrote in java, so is ourgrid (http://www.ourgrid.org), Integrade (http://www.integrade.org), and AppLes (http://apples.ucsd.edu/) for example.

A few precisions: all of these toolkits perform submission at the process level.
The URL for integrade is http://integrade.incubadora.fapesp.br, and as far as I know, their core toolkit is a C++/Corba combination.
My point is, none of these have  a deployment-less submission at the API level. That's the one thing JPPF has that the others don't, and that's only possible because we use the dynamic class loading capabilities of Java. We could probably achieve the same capability with any other language that runs within a VM-like execution environment, like .NET based ones (but .NET is hardly platform-independant).
So what's the use of this? It's all about ease of maintenance. What if your application has bugs? What if you need to refine your simulations, but only know how after the previous one has finished running? I like not having to worry whether my code changes will be taken into account for my next submission. To me, that's simplicity.
Logged
Pages: [1]   Go Up
 
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at SourceForge.net. Fast, secure and Free Open Source software downloads