I managed to fix a few bugs and do a few deployments with grid viewer over the past few days, and it looks like the next thing I get to play with is the GIPSEPoison service... but GIPSEPoison has been built in introduce, and I need to play more with introduce to figure out how those services work and are built and can be modified.
But it will be about the third time I have started to learn introduce. The other two times priorities shifted and I started working on other things... So, perhaps third time is the charm.
I am also going to play a bit with graphics and see if I can plan out concurrent load items.
Cheers!
Showing posts with label introduce. Show all posts
Showing posts with label introduce. Show all posts
Wednesday, July 15, 2009
Thursday, April 9, 2009
GAARDS Whitepaper
A new draft whitepaper which provides a primer of the GAARDS toolset has been posted to the Wiki. It is located at http://sites.google.com/site/phgrid/Publications/GAARDingtheGrid.doc?attredirects=0. I would love to get your comments on this as we continue to refine the ideas and messaging behind the usage of these critical grid security components.
This is a the first draft ready for public comment. Special thanks to those who provided pre-public comment feedback initially. I look forward to further feedback from all!
This is a the first draft ready for public comment. Special thanks to those who provided pre-public comment feedback initially. I look forward to further feedback from all!
Tuesday, April 7, 2009
Whether introduce helps...
So, I have Introduce on my development box, but whenever I try and run the tutorial, it blew up in the very first step with an odd error bubbled up from ant about some method not working properly.
I subscribed to the introduce user group mailing list, asked my question and posted my error, and the response was "You must have used Introduce in the past and are now trying to use a new version of introduce, since introduce modifies the Globus libraries when it runs, you will need a fresh copy of Globus to use a new version of introduce or you get library conflicts"
That is kind of a dealbreaker for me. I am trying to use Introduce for something other than it's intended purpose: to build regular grid services and not caGrid specific services... so it appears that some of the changes that Introduce makes for caGrid (like mutating a Globus installation) are more than I bargained for. Also, introduce is supposed to be something that simplifies the tedious process of populating all the nooks and crannies of a given grid service, and little is more tedious than scrubbing a Globus install.
Vaughn is currently working with a different Eclipse based tool, so another thing I am batting my head against is trying to make something that he, too, will be making: An AMDS service shell. Vaughn is a bit further ahead than me and has already made the Java interface and converted all of the XSDs into Java objects, so if he gets a Grid service that matches that interface with security, I'll probably use that and implement the interface for Poison Data while he implements it for RODS data.... and then start making the client that looks like quicksilver but in fact pulls AMDS data rather than NPDS data.
The other thing that Vaughn has been talking about is maintaining that firefox/apple/google model of easy to install-ness with easily pluggable extensions. Thus, we want to make sure that our service is easily installable or even included on our default grid node we hand out... which makes me start wondering about whether we even want multiple AMDS services or just one AMDS service with multiple return options. (IE, instead of having Poison-AMDS and Rods-AMDS as I am envisioning it, do we want to just have one AMDS that returns two sets of metadata, one for Poison and one for Rods, and then however many extra sets depending on how many other data services are networked behind the scenes, and these questions might have been answered already and I just missed it).
Either way, I am sort of a mass of ambivalences right now. Introduce probably won't work for me, so I am wondering whether I want to try and modify a service from scratch (using the interface that Vaughn already created), do I want to play with the system Vaughn is using (or watch over his shoulder and help) or do I want to start refactoring npdsgmaps and npdsgmaps-web to deal with AMDS style metadata and queries. Or do I just want to just focus on getting rodsadai and the old AMDS client running on the same jboss without tripping over each other since there will probably be multiple clients and they'll need to behave.
It's not unpleasant, but it is a bit frantic. Oh well, ambivalence means I have lots of ideas, and the next step is figuring out which are best or most appealing.
Cheers.
I subscribed to the introduce user group mailing list, asked my question and posted my error, and the response was "You must have used Introduce in the past and are now trying to use a new version of introduce, since introduce modifies the Globus libraries when it runs, you will need a fresh copy of Globus to use a new version of introduce or you get library conflicts"
That is kind of a dealbreaker for me. I am trying to use Introduce for something other than it's intended purpose: to build regular grid services and not caGrid specific services... so it appears that some of the changes that Introduce makes for caGrid (like mutating a Globus installation) are more than I bargained for. Also, introduce is supposed to be something that simplifies the tedious process of populating all the nooks and crannies of a given grid service, and little is more tedious than scrubbing a Globus install.
Vaughn is currently working with a different Eclipse based tool, so another thing I am batting my head against is trying to make something that he, too, will be making: An AMDS service shell. Vaughn is a bit further ahead than me and has already made the Java interface and converted all of the XSDs into Java objects, so if he gets a Grid service that matches that interface with security, I'll probably use that and implement the interface for Poison Data while he implements it for RODS data.... and then start making the client that looks like quicksilver but in fact pulls AMDS data rather than NPDS data.
The other thing that Vaughn has been talking about is maintaining that firefox/apple/google model of easy to install-ness with easily pluggable extensions. Thus, we want to make sure that our service is easily installable or even included on our default grid node we hand out... which makes me start wondering about whether we even want multiple AMDS services or just one AMDS service with multiple return options. (IE, instead of having Poison-AMDS and Rods-AMDS as I am envisioning it, do we want to just have one AMDS that returns two sets of metadata, one for Poison and one for Rods, and then however many extra sets depending on how many other data services are networked behind the scenes, and these questions might have been answered already and I just missed it).
Either way, I am sort of a mass of ambivalences right now. Introduce probably won't work for me, so I am wondering whether I want to try and modify a service from scratch (using the interface that Vaughn already created), do I want to play with the system Vaughn is using (or watch over his shoulder and help) or do I want to start refactoring npdsgmaps and npdsgmaps-web to deal with AMDS style metadata and queries. Or do I just want to just focus on getting rodsadai and the old AMDS client running on the same jboss without tripping over each other since there will probably be multiple clients and they'll need to behave.
It's not unpleasant, but it is a bit frantic. Oh well, ambivalence means I have lots of ideas, and the next step is figuring out which are best or most appealing.
Cheers.
Monday, April 6, 2009
Introduction to Introduce
So, I read much more about Globus and got introduce up and running, more importantly I figured out what I want to try and do with it in the coming weeks: Make a service that will comply with latest AMDS Spec and a client that will allow me to ping it.
The part of converting Poison Center data into AMDS Responses and AMDS Queries into Poison Center queries, while tedious, is something I can envision doing. I can also envision doing the skeleton from scratch, but that would be absolutely horrible to try and do if I don't have any really powerful tools like XML-spy... or Introduce.
The only problems with Introduce for what we need to do is that it is a bit geared towards caGrid, and likes to package up a few special libraries that end up causing some interesting deploy behaviors using globus tools when it is NOT part of caGrid. It also doesn't produce particularly maven-able results from the get go, so there is some footwork to be done playing with packaging and building and deploy tools.
There is also some work to be done with the client and making sure that it's security libraries don't conflict with existing secure clients (like RODSAdai) or how to place libraries so they don't interfere.
Thus, this week will be devoted to getting the service skeleton set up for a secure globus service.
The other cool thing might be that once this is done, it can be saved off as a shell for any given skeleton that needs to wrap other services, since AMDS is supposed to be a repeatable standard.
The part of converting Poison Center data into AMDS Responses and AMDS Queries into Poison Center queries, while tedious, is something I can envision doing. I can also envision doing the skeleton from scratch, but that would be absolutely horrible to try and do if I don't have any really powerful tools like XML-spy... or Introduce.
The only problems with Introduce for what we need to do is that it is a bit geared towards caGrid, and likes to package up a few special libraries that end up causing some interesting deploy behaviors using globus tools when it is NOT part of caGrid. It also doesn't produce particularly maven-able results from the get go, so there is some footwork to be done playing with packaging and building and deploy tools.
There is also some work to be done with the client and making sure that it's security libraries don't conflict with existing secure clients (like RODSAdai) or how to place libraries so they don't interfere.
Thus, this week will be devoted to getting the service skeleton set up for a secure globus service.
The other cool thing might be that once this is done, it can be saved off as a shell for any given skeleton that needs to wrap other services, since AMDS is supposed to be a repeatable standard.
Thursday, April 2, 2009
Minor deploy, and Introduce
So, the next step for Quicksilver is to make an AMDS-intermediary layer that is a secure Globus service. Thus, tonight I am going to be going over some of the GRID/Globus books again and tomorrow I will probably install introduce and run the tutorial.
The reason I want to read the grid books is so I can see what goes into creating a grid service so that I can see what the introduce client will do for me. Then, I can start better understanding the heuristics of making an intermediary layer for poison data showing up in AMDS web.
Oh yeah, I have to go over the AMDS schema as well.
The end result is that the viewer part of Quicksilver, will end up becoming more of a generic AMDS viewer. Thus, one picks (a) secure service(s) that return(s) AMDS data, fills out the form that it/they require(s) (based on retrieved metadata for selected services), compiles the results into some sort of mappable data, and displays it in the map... and one of those secure AMDS services will be poison data.
One of the concerns I had was that making the NPDS->AMDS converter secure would be completely heuristic... then I remembered that people have to be given logins to be able to access poison data, and it would be much easier if they just were able to access it if they had a node on the grid.
So yeah, big context switch over the next couple of days, expect flagellating expectations as I realize the can, can't, and how.
Also, I ported a bunch of the improvements I made to npdsgmaps-web (the viewer part of quicksilver) back to gmap-poly-web (a demonstration library made on top of Gmap-Polygon). That should be deployed to training tomorrow so the two apps act the same (and because the version currently on training doesn't use encoded polygons, and is therefore much slower and error prone).
Cheers!
The reason I want to read the grid books is so I can see what goes into creating a grid service so that I can see what the introduce client will do for me. Then, I can start better understanding the heuristics of making an intermediary layer for poison data showing up in AMDS web.
Oh yeah, I have to go over the AMDS schema as well.
The end result is that the viewer part of Quicksilver, will end up becoming more of a generic AMDS viewer. Thus, one picks (a) secure service(s) that return(s) AMDS data, fills out the form that it/they require(s) (based on retrieved metadata for selected services), compiles the results into some sort of mappable data, and displays it in the map... and one of those secure AMDS services will be poison data.
One of the concerns I had was that making the NPDS->AMDS converter secure would be completely heuristic... then I remembered that people have to be given logins to be able to access poison data, and it would be much easier if they just were able to access it if they had a node on the grid.
So yeah, big context switch over the next couple of days, expect flagellating expectations as I realize the can, can't, and how.
Also, I ported a bunch of the improvements I made to npdsgmaps-web (the viewer part of quicksilver) back to gmap-poly-web (a demonstration library made on top of Gmap-Polygon). That should be deployed to training tomorrow so the two apps act the same (and because the version currently on training doesn't use encoded polygons, and is therefore much slower and error prone).
Cheers!
Subscribe to:
Posts (Atom)
Posts
