[seek-dev] Re: EcoGrid
Jing Tao
tao at nceas.ucsb.edu
Mon Jan 12 13:10:07 PST 2004
Hi, Raja:
Thanks for the info. I will take a look. Lets talk about it in the
conference call.
Jing
On Mon, 12 Jan 2004, Arcot Rajasekar wrote:
>
>
>
> Hi Jing
> I think many of these problems with GridFTP can be solved by
> using the SRB instead which has a superset of functionalities.
>
> thanks
> raja
>
> On Mon, 12 Jan 2004, Jing Tao wrote:
>
> > Hi, in my previous email. There is some comments there. They are hard
> > to be found :). Sorry for that.
> >
> > Thanks!
> >
> > Jing
> >
> >
> > On Mon, 12 Jan 2004, Jing Tao wrote:
> >
> > > Hi, Matt:
> > >
> > > It would be good that we have a conference call to discuss Ecogrid. I can
> > > make it on Jan 15th, 1pm PST.
> > >
> > > On Mon, 12 Jan 2004, Matt Jones wrote:
> > >
> > > > Hi Raja,
> > > >
> > > > Thanks for the note. I more or less agree with your assessment.
> > > > Unfortunately, I haven't tracked the progress to date very effectively,
> > > > so I'm not sure if we're ready to package stuff up. I think we should
> > > > have another conference call to firm up the progress and decide on a
> > > > release date and its contents. The call should include you, me, jing,
> > > > bing, dave, and rod at a minimum. I propose
> > > > Thursday January 15th at 1pm PST
> > > > for a conference call. Can everyone do it at 1pm PST? Please let me
> > > > know if you can not. When we finalize the time, I'll send out
> > > > conference call information to everyone.
> > > >
> > > > Some additional notes below...
> > > >
> > > > Arcot Rajasekar wrote:
> > > > >
> > > > > Hi Matt
> > > > > Bertram, Bing and I had a long conversation about what is done and
> > > > > what is needed in the next phase of the project. I looked at what we had
> > > > > laid out in our Seattle meeting and later confirmed at the Santa Barbara
> > > > > meeting. I think we should package the Ecogrid up and
> > > > > provide it with an easy use client sp that our SEEK scientists canm start
> > > > > playing with it and give feedback to this.
> > > > > I suggest that we quickly make the following available:
> > > > > 1. Server
> > > > > Metacat wrapper (Jing)
> > > > > SRB Wrapper (Bing)
> > > > > Digir wrapper (?)
> > > > > Xanthoria wrapper (?)
> > > > Maybe we can get DiGIR out, but I doubt Xanthoria at this point. I
> > > > think Rod has been struggling with getting the basic GT3 setup in place,
> > > > which indicates to me that GT3 will likely have some serious deployment
> > > > issues. But no harm in our releasing what we have working in
> > > > Metacat/SRB as an alpha of some sort.
> > > >
> > > > >
> > > > > providing the following functionalities:
> > > > > query
> > > > > get
> > > > > put
> > > >
> > > > We haven't implemented "put" AFAIK, unless we got it for free by
> > > > switching to using GridFTP.
> > >
> > >
> > > MetaCat ecogrid server is up for "query" and "get" function. It is running
> > > in both dev and pine.
> > >
> > >
> > > > > 3. get a client package
> > > > > for java based developer users
> > > > > for web-based users with a simple interface into SEEK ecogrid.
> > > >
> > > > Agreed. Jing has a initial client available. We can and should package
> > > > this as a library for distribution and make a web interface. But...we
> > > > need to do a code review to make sure it is designed properly. At this
> > > > point there has been very little design going into the code that's been
> > > > written, so its all rather ad-hoc. This is mostly because we've been
> > > > experimenting with GT3 which has been troublesome at the least.
> > > >
> > > > I also think we should make it a high priority to make Kepler
> > > > communicate over the EcoGrid to retrieve data. This has been the
> > > > limiting factor to demonstrating many of the Kepler tools. I am hoping
> > > > Jing can incorporate his current client in Kepler by the BEAM meeting in
> > > > ABQ coming up in a few weeks.
> > >
> > > I create a ecogird query client class. It has those public APIs:
> > > EcogridQueryClient()
> > > createServiceInstance()
> > > destroyServiceInstance()
> > > createUserProxy()
> > > createEcoGridQueryLevelOnePortType()
> > > query()
> > > get()
> > >
> > > I also put the client.jar, stub.jar and other necessery jar files into a
> > > zip file- ecogrid_client_lib.zip. If we unzip this file, we will get a dir
> > > name ecogrid_client_lib. After we put every jar file of this dir into
> > > class path, the client should work.
> > >
> > > But things is not so easy :) We decided use GridFtp to handle get()
> > > method and GridFtp need credential. So we need setup grid security in the
> > > client. Such as host's certificate, key, user's certificate, key. Also, we
> > > need to install GridFtp in client machine. I create a zip file to help
> > > person to install it. So it is hard to create a thin client.
> > >
> > > Another issue is gt3 itself. It is not very robust(probably, my code
> > > is not robust too :)) When I run the client code, sometimes it
> > > works fine. Sometimes gave some exception even i didn't change any thing.
> > > I will continue to digging it out.
> > >
> > > I will try my best to make Kepler communicate over the EcoGrid to retrieve
> > > data. But I am not sure if I can finished it before the BEAM meeting
> > > beause I don't know too much about Kepler and our ecogrid client is
> > > fragile.
> > >
> > > Thanks.
> > >
> > > Jing
> > >
> > >
> > >
> >
> >
>
>
--
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101
More information about the Seek-dev
mailing list