Hi Danushka, I agree with Amila, we should not get any implementation details into schemas. The Schemas are a contract between user and the system. Its within the system how it executes the task user wants to accomplish. These schemas are completely agnostic to how Airavata talks to a system. For instance, user should be able to say, I want to run a job on Amazon and the host description has EC2 end points. But we should not at that level describe/tag classes on how Airavata talks to EC2.
Your suggestions on decoupling the provider has some value, but given Lahiru has recently eased this in a big way, if further improvements are needed, lets focus on looking at improving them. To achieve your goal of decoupling the providers to make it easy for developers to add new providers is a good one. Other alternatives to achieve this goal may be to write good amount of test cases, or make it easy within GFAC as a framework to add providers. Cheers, Suresh On Mar 4, 2013, at 10:51 PM, Danushka Menikkumbura <[email protected]> wrote: > Amila, > > Correct. When you define the class name in your schema definition, it > actually goes into the HostDescriptionType. > > Thanks, > Danushka > > > On Tue, Mar 5, 2013 at 8:44 AM, Amila Jayasekara > <[email protected]>wrote: > >> On Mon, Mar 4, 2013 at 9:56 PM, Danushka Menikkumbura >> <[email protected]> wrote: >>> Hi, >>> >>> As we have discussed on a separate thread it is very beneficial to have >>> gfac providers decoupled from the core so that gateway developers can >> write >>> their own providers and seamlessly integrate them with the Airavata >>> runtime. I suggested we have a separate plugin architecture to facilitate >>> that but it looks as if a simple and neat approach would be to enable >> using >>> dynamically loaded providers in the scheduler without having a separate >>> plugin manager to do that. >>> >>> In order to do that, we need to let the scheduler know the >> fully-qualified >>> class names of providers. I suggest we have the provider class name >> defined >>> in the host description. >> >> Hi Danushka, >> >> The provider class name is an implementation detail in GFac. I think >> we should not expose that to API. User does not need to know about >> class names implementing appropriate providers. Therefore I do not >> think HostDescriptor is the right place to put fully qualified class >> name of provider. >> >> Further I believe the fully qualified class name should be associated >> with org.apache.airavata.schemas.gfac.HostDescriptionType. >> >> HostDescriptionType has following derivations; >> >> org.apache.airavata.schemas.gfac.GlobusHostType >> org.apache.airavata.schemas.gfac.Ec2HostType >> org.apache.airavata.schemas.gfac.GsisshHostType >> org.apache.airavata.schemas.gfac.UnicoreHostType >> >> Thanks >> Amila >> >>> >>> WDYT? >>> >>> Thanks, >>> Danushka >>
