Gerhard Froehlich wrote: > Stephan, > this's a very good example. Why don't we put parts > of it to the phoenix homepage?
+10 More docs, More docs! It makes it easier for newbies! > > 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]> > > . > > -- "Those who would trade liberty for temporary security deserve neither" - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
