You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Hans Herbert <ja...@hotmail.com> on 2001/11/14 12:14:59 UTC
Interfaces=Services / dependencies?
Hello,
I am new at this Mailinglist and hope that my questions are not too stupid.
a) assembly.xml versus Block.xinfo
Using assembly.xml you have to descripe (e.g.)
[...]
<block class="CLAS_WITH_INITIAZILE_COMPOSE_ETC"" name="BLOCK1">
<provide name="BLOCK2" role="INTERFACE_VON_BLOCK2"/>
<provide name="BLOCK3" role="INTERFACE_VON_BLOCK3"/>
</block>
[...]
Using Block1.xinfo
[...]
<services>
<service name="INTERFACE_VON_BLOCK1" version="1.0"/>
</services>
<dependencies>
<dependency>
<service name="INTERFACE_VON_BLOCK2" version="1.0"/>
</dependency>
<dependency>
<service name="INTERFACE_VON_BLOCK3" version="1.0"/>
</dependency>
......
</dependencies>
[...]
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?
I found your last answer regarding the BlockListener and "Linking Interfaces
to a Block". How can I implement this in my code?
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
impmenets your interface, this Block wants to talk to you. 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?
- If yes, how is it possible to implement this (give me a hint)
- Can BlockListener with addBlock and removeBlock be the solution for that?
This would be a much more flexible way of linking (my opinion)
Many thanks in advance.
Hans Herbert
_________________________________________________________________
Downloaden Sie MSN Explorer kostenlos unter http://explorer.msn.de/intl.asp
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
>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?
Let me try to explain (I'm newbie, too :):
- The assembly.xml file is wiring together blocks to one server application.
That's done by provide. That means a server application can hold several
blocks.
Like FTPServer in the cornerstore project
-> a cornerstore block (generic services)...
-> a ftpserver block
Just look in the ftp-server.sar how it's organized.
- The block.xinfo is the meta information for one block. Information like Version
on which services he depends and what service he can offer.
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interfaces=Services / dependencies?
Posted by Berin Loritsch <bl...@apache.org>.
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:mcconnell@osm.net]
>>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:mcconnell@osm.net
>>
>>
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> .
>
>
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
>Sounds like you'll be learning xdocs Gerhard... ;-)
Nothing new mate, did wrote some for cocoon :)
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interfaces=Services / dependencies?
Posted by Paul Hammant <Pa...@yahoo.com>.
Gerhard,
>>
>>Put it on it's own page--but with the Phoenix docs.
>>
>Under:
>Administrators Guide
>Deployers Guide
>Assemblers Guide
>Block Developers Guide
>
>or as HowTo?
>
>>Actually there are some scratchings that touch on it--see if you
>>can fit it in.
>>
>We will see...
>
Sounds like you'll be learning xdocs Gerhard... ;-)
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
>>>>Stephan,
>>>>this's a very good example. Why don't we put parts
>>>>of it to the phoenix homepage?
>>>>
>>>+1
>>>
>>>Anyone volunteer to convert it into an xml document ? ;)
>>>
>> Ahem, it was my idea and therefore I should do it. But I'm
>> heavily engaged with AvalonDB. So please tell me under which
>> part of the avalon homepage do want this example. Standalone
>> or somewhere integrated.
>
>
>Put it on it's own page--but with the Phoenix docs.
Under:
Administrators Guide
Deployers Guide
Assemblers Guide
Block Developers Guide
or as HowTo?
>Actually there are some scratchings that touch on it--see if you
>can fit it in.
We will see...
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interfaces=Services / dependencies?
Posted by Berin Loritsch <bl...@apache.org>.
Gerhard Froehlich wrote:
>>On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
>>
>>>Stephan,
>>>this's a very good example. Why don't we put parts
>>>of it to the phoenix homepage?
>>>
>>+1
>>
>>Anyone volunteer to convert it into an xml document ? ;)
>>
> Ahem, it was my idea and therefore I should do it. But I'm
> heavily engaged with AvalonDB. So please tell me under which
> part of the avalon homepage do want this example. Standalone
> or somewhere integrated.
Put it on it's own page--but with the Phoenix docs.
Actually there are some scratchings that touch on it--see if you
can fit it in.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
>On Fri, 16 Nov 2001 21:39, Gerhard Froehlich wrote:
>> >On Thu, 15 Nov 2001 23:06, Gerhard Froehlich wrote:
>> >> >On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
>> >> >> Stephan,
>> >> >> this's a very good example. Why don't we put parts
>> >> >> of it to the phoenix homepage?
>> >> >
>> >> >+1
>> >> >
>> >> >Anyone volunteer to convert it into an xml document ? ;)
>> >>
>> >> Ahem, it was my idea and therefore I should do it. But I'm
>> >> heavily engaged with AvalonDB. So please tell me under which
>> >> part of the avalon homepage do want this example. Standalone
>> >> or somewhere integrated.
>> >
>> >Well it is up to you. Some of the response looked like good material for
>> > the start of a FAQ list ;)
>>
>> The FAQ List I considered, too. But it's a little effort to maintain :). Is
>> there a tool or something else...
>
>Well there is but I actually prefer to have a handmaintained list. If you
>want to set up the faq list building and possibly add a whole bunch of
>questions - I am more than happy to answer the questions and maintain the
>answers ;)
I can try to start this...maybe you can mail me your "suggestion" to
g-froehlich@gmx.de.
>> >Other parts could be integrated into the main phoenix docs (or even
>> > replace large chunks of them if you want). Or you may want to keep part
>> > of it as a standalone example - not sure. Either way - go to town on it
>> > ;) More documentation is always good.
>>
>> See thread "new docs". I put it under "All together --> example
>> configuration".
>
>saw it. Slowly making my way through my mail backlog ;)
A everyday pleasue ;)
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interfaces=Services / dependencies?
Posted by Peter Donald <do...@apache.org>.
On Fri, 16 Nov 2001 21:39, Gerhard Froehlich wrote:
> >On Thu, 15 Nov 2001 23:06, Gerhard Froehlich wrote:
> >> >On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
> >> >> Stephan,
> >> >> this's a very good example. Why don't we put parts
> >> >> of it to the phoenix homepage?
> >> >
> >> >+1
> >> >
> >> >Anyone volunteer to convert it into an xml document ? ;)
> >>
> >> Ahem, it was my idea and therefore I should do it. But I'm
> >> heavily engaged with AvalonDB. So please tell me under which
> >> part of the avalon homepage do want this example. Standalone
> >> or somewhere integrated.
> >
> >Well it is up to you. Some of the response looked like good material for
> > the start of a FAQ list ;)
>
> The FAQ List I considered, too. But it's a little effort to maintain :). Is
> there a tool or something else...
Well there is but I actually prefer to have a handmaintained list. If you
want to set up the faq list building and possibly add a whole bunch of
questions - I am more than happy to answer the questions and maintain the
answers ;)
> >Other parts could be integrated into the main phoenix docs (or even
> > replace large chunks of them if you want). Or you may want to keep part
> > of it as a standalone example - not sure. Either way - go to town on it
> > ;) More documentation is always good.
>
> See thread "new docs". I put it under "All together --> example
> configuration".
saw it. Slowly making my way through my mail backlog ;)
--
Cheers,
Pete
------------------------------
Kitsch never goes out of style
------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
>On Thu, 15 Nov 2001 23:06, Gerhard Froehlich wrote:
>> >On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
>> >> Stephan,
>> >> this's a very good example. Why don't we put parts
>> >> of it to the phoenix homepage?
>> >
>> >+1
>> >
>> >Anyone volunteer to convert it into an xml document ? ;)
>>
>> Ahem, it was my idea and therefore I should do it. But I'm
>> heavily engaged with AvalonDB. So please tell me under which
>> part of the avalon homepage do want this example. Standalone
>> or somewhere integrated.
>
>Well it is up to you. Some of the response looked like good material for the
>start of a FAQ list ;)
The FAQ List I considered, too. But it's a little effort to maintain :). Is there
a tool or something else...
>Other parts could be integrated into the main phoenix docs (or even replace
>large chunks of them if you want). Or you may want to keep part of it as a
>standalone example - not sure. Either way - go to town on it ;) More
>documentation is always good.
See thread "new docs". I put it under "All together --> example configuration".
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interfaces=Services / dependencies?
Posted by Peter Donald <do...@apache.org>.
On Thu, 15 Nov 2001 23:06, Gerhard Froehlich wrote:
> >On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
> >> Stephan,
> >> this's a very good example. Why don't we put parts
> >> of it to the phoenix homepage?
> >
> >+1
> >
> >Anyone volunteer to convert it into an xml document ? ;)
>
> Ahem, it was my idea and therefore I should do it. But I'm
> heavily engaged with AvalonDB. So please tell me under which
> part of the avalon homepage do want this example. Standalone
> or somewhere integrated.
Well it is up to you. Some of the response looked like good material for the
start of a FAQ list ;)
Other parts could be integrated into the main phoenix docs (or even replace
large chunks of them if you want). Or you may want to keep part of it as a
standalone example - not sure. Either way - go to town on it ;) More
documentation is always good.
--
Cheers,
Pete
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
>On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
>> Stephan,
>> this's a very good example. Why don't we put parts
>> of it to the phoenix homepage?
>
>+1
>
>Anyone volunteer to convert it into an xml document ? ;)
Ahem, it was my idea and therefore I should do it. But I'm
heavily engaged with AvalonDB. So please tell me under which
part of the avalon homepage do want this example. Standalone
or somewhere integrated.
Cheers
Gerhard
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Interfaces=Services / dependencies?
Posted by Peter Donald <do...@apache.org>.
On Thu, 15 Nov 2001 11:16, Gerhard Froehlich wrote:
> Stephan,
> this's a very good example. Why don't we put parts
> of it to the phoenix homepage?
+1
Anyone volunteer to convert it into an xml document ? ;)
--
Cheers,
Pete
"You know what a dumbshit the 'average man' on the street is? Well, by
definition, half of them are even dumber than that!"
J.R. "Bob" Dobbs
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by giacomo <gi...@apache.org>.
On Thu, 15 Nov 2001, Gerhard Froehlich wrote:
> Stephan,
> this's a very good example. Why don't we put parts
> of it to the phoenix homepage?
+1
Giacomo
>
> Cheers
> Gerhard
> >-----Original Message-----
> >From: Stephen McConnell [mailto:mcconnell@osm.net]
> >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:mcconnell@osm.net
> >
> >
> >
> >--
> >To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> >For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Gerhard Froehlich <g-...@gmx.de>.
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:mcconnell@osm.net]
>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:mcconnell@osm.net
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Interfaces=Services / dependencies?
Posted by Stephen McConnell <mc...@osm.net>.
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:mcconnell@osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>