1 Reply Latest reply on Nov 1, 2010 7:50 PM by kcbabo

    Component API or convention?

    tcunning

      Is there going to be any formal API around the components we provide?    I know "component" is sort of a vague idea purposefully, but it seems like there should be some convention here in at least the components we write so that components do things similarly :

       

      Component Consumers :

       

      How does a Component register a service?     Does it register a service itself automatically?   Do we pass a service name into the component so it can register a service?     Or does the component provide the user with a ExchangeHandler so that the user can register a service based on that component?   

       

      QName myService = new QName("myService");
      Component component = new Component()
      ComponentConfig config = new ComponentConfig(domainName);
      component.init(config); // 
      component.registerService(myService);
      

       

      or

       

      QName myService = new QName("myService");
      Component component = new Component()
      _domain.registerService(myService, component.getConsumerHandler));
      

       

      Provider Components :

       

      If the component is a provider, do we pass it an ExchangeHandler or ExchangeHandlerChain to deal with?    Or should we be able to add handlers to a chain, get the component's provider service, and then add our Handler to the component service's handler chain?

       

      // note : I made PrintlnBaseHandler up, assume it just prints the content of the message
      ExchangeHandler consumer = new PrintlnBaseHandler();
      Component component = new Component();
      ComponentConfig config = new ComponentConfig();
      config.setABunchofStuff(abunchOfStuff);
      config.setExchangeHandler(consumer);
      component.deploy(config);
      component.start();     
      

       

      or

       

      // note : I made PrintlnBaseHandler up, assume it just prints the content of the message
      ExchangeHandler consumer = new PrintlnBaseHandler();
      Component component = new Component();
      ComponentConfig config = new ComponentConfig();
      config.setABunchofStuff(abunchOfStuff);
      component.deploy(config);
      ServiceRegistration sr = component.getProviderService();
      sr.getHandlers().addHandler(consumer); // I believe this currently will fail
      component.start();    
      
        • 1. Re: Component API or convention?
          kcbabo

          We will definitely want to use some sort of common contract for the components that we provide with SwitchYard.  A number of these will simply be wrappers/delegates to existing containers in the runtime and therefore will be quite slim.  The component contracts that are most important, IMHO, are life cycle and deployment.  Do we need to define our own contracts here?  Maybe not.  Within JBoss there are a number of container APIs already available, OSGi has a well-defined module API, etc., etc.

           

          I noticed that you have the consumer registering a service in your example above.  The provider would actually register the service and the consumer would create an exchange and send it to the provider.

           

          In terms of when a component registers a service, this should be a side effect of deployment.  So you deploy an application and the configuration provides details on which components are providing and consuming which services.  The targeted components will have an API to access this information and do the right thing.

           

          Have you looked at IronJacamar at all?  It looks like they have a much lighter weight mechanism for developing and deploying adapters.  I wonder if that would make sense as the basis for a gateway component container.