Accessing SwitchYard Application Meta-data

[rcernich]

Hey all,

As part of my work on the SwitchYard console, I've gotten to the point where I need access to application meta-data (e.g. to display the services defined by the application).  With a few minor modifications, I'm able to access the meta-data through SwitchYardService.getValue().getConfig().  A couple of questions:

Is this the best way to access the application meta-data?

SwitchYardDeployment (SwitchYardService.getValue()) exposes lifecycle methods for managing the deployment; SwitchYardMetaData (SwitchYardDeployment.getConfig()) exposes setters for modifying application meta-data.  Based on that, should there be a separate API for accessing the meta-data (i.e. a read-only view)? 

What are your thoughts?

Rob

[kcbabo]

I think what we need to do here is define a set of interfaces which represent the entities that we plan to pop up in the console (and other tooling such as command-line, IDE, etc.).   I'll expand on this in the other thread you created re: admin API.  I definitely still see a need to expose the configuration descriptor, but the interface route will allow us to provide an admin interface beyond just the AS7 deployment hooks and DMR. Starting from the interfaces, we can map to:

- AS7 console

- JMX

- Jopr/JON

- JAX-RS/RESTEasy

- OSGi service registry

The basic entities would be something like:

- SwitchYard  : system-level info

- Component : one for each installed component

- Application : one for each application

- Service : one for each service

The interesting thing to me is that all of these entities share relationships which should make it easy to navigate between them, e.g. view the list of services, select one, then navigate to the app containing that service.

[rcernich]

Hey Keith,

This sounds good to me.  The mappings simply become ways of exposing the API through various access protocols/API.

Rob

[kcbabo]

OK, I took a quick swipe at this and came up with the following basic interfaces.  All this information is available now and I think it should be easy to map to the console quickly.

public interface System {

    String getVersion();
    List<Application> getApplications();
    List<Component> getComponents();
    List<Service> getServices();
}

public interface Component {
    String getName();
    boolean isGateway();
    boolean isImplementation();
    String getType();
    String getConfigSchema();
}

public interface Application {
    public List<Service> getServices();
    public QName getName();
}

public interface Service {

    QName getName();
    Component getImplementation();
    List<Component> getGateways();
    String getInterface();
}

Again, this is really just scratching the surface.  I'm hoping we can iterate over this to get closer to what we need.

Some random thoughts:

• This is obviously a rough first shot, but after messing with it a bit, I'm confident that we can evolve this to be something decent.
• I'm thinking we will have a core set of these admin interfaces which are then extended or wrapped by other implementation-specific interfaces (JMX/MBean, JAX-RS, etc.) vs. expecting a single interface to be able to be mapped to all of these technologies.
• I can attach the top-level System interface to the SwitchYardService, which should make it easy for you to pull out.
• Lifecycle, monitoring, and other control/edit functions are not represented yet, but I think these can be incorporated directly and/or layered on top.

[rcernich]

Hey Keith,

This looks great.  I can integrate the API into the SY service.

One quick question, did you want navigation to be bidirectional, e.g. Service.getApplication()?

Thanks for scratching this out.

Rob

[kcbabo]

Good point about the back pointer to Application from Service.  I will get this packaged up into a new admin module and get a pull request out by tonight.  You can pick it up from there and have a new console by tomorrow morning? ;-)