Stephan, this's a very good example. Why don't we put parts of it to the phoenix homepage?
Cheers Gerhard >-----Original Message----- >From: Stephen McConnell [mailto:[EMAIL PROTECTED] >Sent: Wednesday, November 14, 2001 11:35 PM >To: Avalon Developers List >Subject: RE: Interfaces=Services / dependencies? > > > >Hans: > >A bunch of note in-line. > > >Hans Herbert wrote: >> I am new at this Mailinglist and hope that my questions are not >> too stupid. >[sniped example] > >Don't worry - getting the hang of the assembly, manifest and xinfo stuff >takes a little while. I've snipped out your example and instead I'm >including an example below of a real .xinfo file and further down an >extract of an assembly.xml file - together with some comments. > >Here is a .xinfo file for a reasonably simple block that serves as a >factory for business processes the handle PKI certification request. >I've added comments in line to explain what's going on. > > ><blockinfo> > > <block> > <version>1.0</version> > </block> > > <services> > > <!-- > This block could be declaring several services that it supports. > Unlike an Java interface, the service includes a version tag. So > its possible for a block to several services with possibly > different versions. If there are multiple services then just > declare them with multiple service entries here. Phoenix will make > sure that the class with the same name as the .xinfo file > implements these interfaces (if it doesn't then Phoenix will > terminate) > --> > > <service name="net.osm.hub.gateway.FactoryService" version="1.0" /> > > </services> > > <!-- > So far, we have the definition of a class that supports possibly > multiple version interface. But things get much more interesting when > we think about the services that this block requires in order to function > properly. That's partly handled by the dependencies element and partly by > the assempbly.xml file (which I'll explain later). I the following > dependency example there are seven "service" dependencies (i.e. 7 >versioned > interface dependencies that must be fulfilled for this block to function. > --> > > <dependencies> > > <!-- > Each dependency contains a declaration of a role name and the > the service interface and version that can fulfil that role. The > dependency does not say anything about where that service > implementation should come from (that's the job the assembly.xml > file). The role element is simply the label used in the implementation > of your block configure method that distinguishes a particular > instance of the service. > --> > <dependency> > <role>GATEWAY</role> > <service name="net.osm.hub.gateway.GatewayContext" version="1.0"/> > </dependency> > > <!-- > This dependency declaration simply states that in order to function, >this > block requires an a "service" (which happens to a wrapper to a CORBA > ORB version 2.4) and that the block implementation will lookup that > service using the "ORB" keyword. > --> > <dependency> > <role>ORB</role> > <service name="net.osm.hub.gateway.ORBService" version="2.4"/> > </dependency> > > <!-- > This dependency declares a requirement for a PSS (Persistent State > Service) Storage Home. > --> > <dependency> > <role>PSS</role> > <service name="net.osm.hub.gateway.ProcessorStorageHomeService" >version="1.0"/> > </dependency> > > <!-- > This dependency enables the block to establish a call-back to the > block supplying the service. This block uses the Registry interface > to publish a business process description to a higher level manager. > --> > <dependency> > <role>REGISTRY</role> > <service name="net.osm.hub.gateway.Registry" version="1.0"/> > </dependency> > > <!-- etc. --> > <dependency> > <role>DOMAIN</role> > <service name="net.osm.hub.gateway.DomainService" version="1.0"/> > </dependency> > <dependency> > <role>RANDOM</role> > <service name="net.osm.hub.gateway.RandomService" version="1.0"/> > </dependency> > <dependency> > <role>CLOCK</role> > <service name="net.osm.service.time.TimeService" version="1.0"/> > </dependency> > </dependencies> > ></blockinfo> > >Here is a block declaration I've cut from an assembly.xml file. This enables >the declaration of WHERE the services are coming from. I.e. you may have a >system with many blocks and even the potential for matching services >available >>from more that one block. The class attribute provides the link to the >.xinfo >file and the implementation class. The name is used a key within the >assembly.xml file when wiring things together. E.g. the provide element >references a block by its name - and declares that the named block will >serve >as the provider of the service. The role attribute matches the role element >in the .xinfo dependency declaration. > > <!-- Certification Request Factory --> > <block class="net.osm.pki.process.CertificationRequestServer" >name="certification" > > <provide name="gateway" role="GATEWAY"/> > <provide name="gateway" role="ORB"/> > <provide name="gateway" role="PSS"/> > <provide name="gateway" role="DOMAIN"/> > <provide name="gateway" role="RANDOM"/> > <provide name="pki" role="REGISTRY"/> > <provide name="time" role="CLOCK"/> > </block> > >> Now the question: Isn't that some kind of double information. I >> tried some different configuration, but it seems that it has to >> be that way. >> - What is the advantage/idea behind this? > >First of all it forces structure and separation, secondly, it provides a way >of managing possibly multiple versions of the same interface in a single >environment. Thirdly, it enables explicit declaration of the source of >service provision. For example, in the OSM platform we have multiple blocks >providing a TimeService. One of those blocks uses an external time >reference while the others use a local time reference. The local time block >declare dependencies on the external source time block and periodically >synchronised. In this example all of the TimeService services are exposing >the same interface, same version (i.e. same service), but the decision as to >which service is the provider to another can be explicitly controlled. >While the time example is perhaps trivial, there are significant policy >security implications related to service provider selection. > >> I found your last answer regarding the BlockListener and "Linking >> Interfaces to a Block". How can I implement this in my code? > >To create a block listener you need to do the following: > > 1. declare the listener in the assembly.xml file > > <avalon> > <block-listener name="myListener" class="MyClass" /> > <!-- > and any other stuff > --> > </avalon> > > 2. implement the listener > > public class MyClass > implements BlockListener > { > public void blockAdded( BlockEvent event ) > { > System.err.printl( "ADDED " + event.getName() ) > } > public void blockRemoved( BlockEvent event ) > { > System.err.printl( "REMOVED " + event.getName() ) > } > } > > 3. make sure the listener is included in a jar file in > the ${SAR-INF}/lib directory. > >An I think that about it. > >> Let's say, I have a Block that would like to communicate with all >> the other blocks via interfaces (of course). Either I write all these >Blocks and >> interfaces in that above described way OR I say the Block "He, if a Block >> implements your interface, this Block wants to talk to you. > >You could do that but I would recommend using the formal .xinfo/assembly.xml >approach because (a) are getting much more rigorous about the relationships >between blocks, and (b) you get lifecycle support, dependency validation, >and >things like resource establishment for free courtesy of Phoenix block >lifecycle >management. > >> So start a lookup at this Block using the componentManager.lookup(ROLE)". >> - Is it possible to do such a checking during starting up without writing >> all down in assembly and xinfo? > >No. > >> This would be a much more flexible way of linking (my opinion) > >Absolutely - much more flexible, much easier to put together, and much less >reliable. :-) > >Cheers, Steve. > >Stephen J. McConnell, OSM sarl >digital products for a global economy >http://www.osm.net >mailto:[EMAIL PROTECTED] > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
