On Fri, Jul 29, 2011 at 7:18 AM, Nirmal Fernando <[email protected]> wrote: ... > So, what you say on following reasoning? > > eg: > > * > <component name=" > SubtractServiceComponent"> > <implementation.java class="calculator.SubtractServiceImpl"/> > </component> > > For this, I'll add a service to "SubtractServiceComponent", since there are > no 'service' elements. > > * > <component name="Catalog"> > <implementation.java class="services.FruitsCatalogImpl"/> > <property name="currencyCode">USD</property> > <service name="Catalog"> > <t:binding.jsonrpc/> > </service> > <reference name="currencyConverter" target="CurrencyConverter"/> > </component> > > For this "Catalog" component "Catalog" is the only service, that I'll be > added. >
Hi Nirmal, Here are a few approaches for you to think about: (a) If you want to show in the diagram all the services and references, including the ones that are unwired, the only way to do that is to introspect the component implementation, as the composite document only contains optional configuration of (potentially a subset of) the component implementation services and references. (b) If you only want the diagram to show the services and references that are wired or have their endpoints configured then it's much easier, just follow the wires and show the services they're targeting (which may not appear in the composite but you know they should be shown as they're targets of wires), plus the service and references elements that are actually configured in the composite. (c) You could also make a simplifying assumption (as a step stone for now) and only show one service per component. After all if a component A is wired to component B to call some function in B's implementation, it's not that important that it's wired to B's service foo, bar or blah. Showing that A is wired to B is already pretty nice. (d) Write a separate tool that introspects a component implementation and generates a .componentType document declaring its services and references (see the SCA assembly spec for what a .componentType document looks like). Then in your diagram generator use that .componentType document to know the shape of the component implementation (its services and references) without having to dig into the implementation itself. Disclaimer: option (d) is probably not going to be very popular with other people in the Tuscany project or the SCA spec group... as it looks like both groups are slowly 'burying / not promoting' component types but IMHO that would still be the best one. I'll be happy to elaborate as to why I think that if you're interested in that approach... but perhaps think about the other approaches first, in particular (b) and (c) which are simpler. Hope this helps. -- Jean-Sebastien
