Twitter github

Visualizing OSGi Services

In PDE, we’re working on adding OSGi Services information to the Plug-in Registry view… the question came up on how these things should be visualized. It turns out that creating icons for OSGi services is a painful task. This was our initial stab at it:

Not so bad eh? Well, when talking to Equinox Framework extradonaire, Tom Watson, he was a bit confused by the icons. He pointed me to a picture that Peter Kriens uses to describe OSGi services apparently:

That’s cute… I can see that Peter was trying to describe that only one bundle can register a specific service (pointy side of triangle) and multiple bundles can bind to it (flat side of the triangle). However, this doesn’t really help me in creating an icon that normal people would understand… also… why a triangle? So I tried to hack something up quickly in a budget paint program:

Ok, I kept the triangle… hypothetically put an ‘S’ on it to represent service… than I put arrows on the top and bottom of the triangle to represent “importing” and “exporting” services. Nope, I’m not satisfied with this crap either. Actually, when I think about it… visualizing services is as confusing as driving in Boston:

How does everyone out there picture OSGi services in their heads?

  • Simon Archer

    You ask for what’s inside my head and you’re likely to regret it! The notation I use is one of puzzle pieces. While working with customers from around the world, we found that puzzle pieces were always well understood. A bundle that exports a service has an outie puzzle shape, and a bundle that imports a service has an innie puzzle shape. Bundles that both export services and import services have both an innie and an outie puzzle shape. For an example of what I mean, see this page of the SAT documentation. When we draw “puzzle piece diagrams” we give each service a distinct puzzle piece shape, which makes it easy to see which services are needed where. Credit for this notion goes to Paul Vanderlei. For the design of a service icons the idea of an innie and outie puzzle piece might be a useful one.

  • Simon Archer

    You ask for what’s inside my head and you’re likely to regret it! The notation I use is one of puzzle pieces. While working with customers from around the world, we found that puzzle pieces were always well understood. A bundle that exports a service has an outie puzzle shape, and a bundle that imports a service has an innie puzzle shape. Bundles that both export services and import services have both an innie and an outie puzzle shape. For an example of what I mean, see this page of the SAT documentation. When we draw “puzzle piece diagrams” we give each service a distinct puzzle piece shape, which makes it easy to see which services are needed where. Credit for this notion goes to Paul Vanderlei. For the design of a service icons the idea of an innie and outie puzzle piece might be a useful one.

  • Andrei Loskutov

    I can only hope that the information will be shown not only as some strange group of pixels. I guess you will put some lines into the tooltip or something like that. Otherwise we all “average” OSGI consumers will need to bookmark this blog 😉

  • Andrei Loskutov

    I can only hope that the information will be shown not only as some strange group of pixels. I guess you will put some lines into the tooltip or something like that. Otherwise we all “average” OSGI consumers will need to bookmark this blog 😉

  • Benedikt Arnold

    I like Simons idea of using some kind of puzzle pieces.

  • Benedikt Arnold

    I like Simons idea of using some kind of puzzle pieces.

  • Ron

    I’ve always wanted something like this for PDE (visualization of services).
    Just out of curiousity, how does this work? (e.g. do you track calls to registerService()/getService()?)

  • Ron

    I’ve always wanted something like this for PDE (visualization of services).Just out of curiousity, how does this work? (e.g. do you track calls to registerService()/getService()?)

  • Benedikt Arnold

    … and what about services that are registered/get declaratively. For example via DS or SpringDM?

  • Benedikt Arnold

    … and what about services that are registered/get declaratively. For example via DS or SpringDM?

  • Graham

    Hey I think services are a runtime object, so how about a moving object? Like a Spinning Wheel?
    What about adding them to a debugging window, so we can see runtime dependancies of services, and this also helps with development with tools like DS, and Spring-OSGi where we can see the result.

  • Graham

    Hey I think services are a runtime object, so how about a moving object? Like a Spinning Wheel?What about adding them to a debugging window, so we can see runtime dependancies of services, and this also helps with development with tools like DS, and Spring-OSGi where we can see the result.