Loading ...
Sorry, an error occurred while loading the content.

RE: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign] Re: Repositories and Transaction Handling

Expand Messages
  • Dirk Riehle
    We want to have exactly one EUR currency object, one USD currency object, etc. There should be only 150 or currency objects in use at any time. equals() relies
    Message 1 of 8 , Jul 13, 2005
    View Source
    • 0 Attachment
      We want to have exactly one EUR currency object, one USD currency object, etc. There should be only 150 or currency objects in use at any time. equals() relies on this design decision (equals is reduced to an identity check then).

      If you have a free Hibernate created instance, two EUR objects won't be equal if they aren't the same object.

      In an older app we used the framework this made quite a performance difference. (Not so in the current one.) Today it is not as critical any longer for us, but it is just how the framework is built. You can switch on/off sharing of value objects.

      Dirk



      At 13.07.2005, Molitor, Stephen L wrote:
      Dirk (not Roni!)
       
      Sorry, didn't read your post carefully enough.  Regarding #2, I didn't quite understand this bit:
       
      > In Hibernate you can get around that by declaring access to a field as access="field" which avoids using getters and setters but goes to the field
      > directly. But then you won't get the benefit of the setter where necessary. For example, some of our value objects are immutable shared objects > > (Currency) and having an anonymously created instance floating around breaks that model. Going back to getter/setter field access doesn't cut it
      > as the issue is independent of this.
       
      If the objects are immutable, why does it matter if they are shared or not?  How does having a Hibernate created instance floating around break the model?
       
      Steve



      From: domaindrivendesign@yahoogroups.com [ mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dirk Riehle
      Sent: Wednesday, July 13, 2005 4:23 AM
      To: domaindrivendesign@yahoogroups.com
      Subject: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign] Re: Repositories and Transaction Handling

      Hi all,

      we started using Hibernate about a week ago, and even though I think it is probably the best of the ORM tools available, it does get in the way with (a) proper domain modeling and (b) separating domain models from persistence layers.

      I thought I'd describe the main issues I'm having right now---maybe someone knows a better solution or at least finds this interesting.

      1. Value Objects. We have a whole library of value objects (an earlier version can be found on www.jvalue.org) and so we would like to map them into columns within the enclosing entity object's table.

      Hibernate lets you specify value objects as components, but then you have to repeat the component structure any time you use a specific value object. For example, in an Account class, a balance attribute might be mapped like this:

      <component name="balance" class="org.jvalue.finance.Money">
               <property name="amount" access="field" column="BALANCE"/>
               <component name="currency" access="field" class="org.jvalue.finance.Currency">
                        <property name="code" access="field" column="CURRENCY"/>
               </component>
      </component>

      If you use Money objects some other place, you have to repeat that same definition in that other class mapping definition. So much about redundancy.

      Then I see Hibernate lets you specify classes as value objects, called user types. Unfortunately, you have to implement UserType or CompositeUserType. For us, this is out of the question, as we can't change/reimplement/extend our library that way. Wasn't a good OR Mapper supposed to be non-invasive?

      2. Field access. Hibernate wants us to use getters and setter for loading/saving objects. This gets in the way of domain semantics, for example some of our (legacy) code uses old-style assertions, for example:

      class Posting...

               public void setValidityDate(JDate date) {
                        // FIXME: assertIsNotSealed();
                        validityDate = JDate.getValue(date.asMilliseconds());
               }
      }

      assertIsNotSealed() throws an exception if this posting to a book had been carried out, hence sealed, and is supposed not to be touched. That behavior is part of the domain model for sure!

      In Hibernate you can get around that by declaring access to a field as access="field" which avoids using getters and setters but goes to the field directly. But then you won't get the benefit of the setter where necessary. For example, some of our value objects are immutable shared objects (Currency) and having an anonymously created instance floating around breaks that model. Going back to getter/setter field access doesn't cut it as the issue is independent of this.

      Anyway, long post, rather frustratedly, but still interesting, I hope.

      Dirk


      Interested in wikis? Please go to http://www.wikisym.org!
      Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
      Dirk Riehle | +49 172 184 8755 | http://www.riehle.org


              




      At 12.07.2005, Billy McCafferty wrote:
      There�s a great example of separating the transactional layer in Chapter 8 of �Hibernate in Action� by Christian Bauer and Gavin King.
       
      Billy McCafferty
       
       
      -----Original Message-----
      From: domaindrivendesign@yahoogroups.com [ mailto:domaindrivendesign@yahoogroups.com] On Behalf Of andrew_raphael_small
      Sent: Saturday, July 09, 2005 1:22 PM
      To: domaindrivendesign@yahoogroups.com
      Subject: [domaindrivendesign] Re: Repositories and Transaction Handling
       
      --- In domaindrivendesign@yahoogroups.com, Rex Madden
      <rexmadden@g...> wrote:
      > Any OR mapping tool will have several options for handling
      transactions. For
      > example, in Hibernate, the simplest method is to pass a session to
      your
      > repository which is opened at the beginning of a request, and then
      flushed
      > and closed at the end of a request (assuming you are talking about
      a web
      > app). You can use a ServletFilter to do the opening and closing.
      >  Of course, there are more sophisticated patterns for complicated
      scenarios,
      > but that's a good way to start.
      >
      >
      > --
      > Rex Madden

      I would be very interested to learn about those more sophisticated
      patterns.  Do you know some references that I can look at?  I want to
      set up our application to use the simple pattern you describe but I
      also want to be ready to address the complicated scenarios that we
      may encounter.

      Andrew Small



      <?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?---- HM ADS ?>

      YAHOO! GROUPS LINKS



      <?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?---- HM ADS ?>

      YAHOO! GROUPS LINKS



      Interested in wikis? Please go to http://www.wikisym.org!
      Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
      Dirk Riehle | +49 172 184 8755 | http://www.riehle.org

    • Steve Bate
      Dirk, Does the example at http://www.hibernate.org/172.html do what you want? It s mapping shared, immutable instances using a user type adapter without
      Message 2 of 8 , Jul 13, 2005
      View Source
      • 0 Attachment
        Dirk,

        Does the example at http://www.hibernate.org/172.html do what
        you want? It's mapping shared, immutable instances using a
        user type adapter without extending the shared class.

        Steve
        ________________________________________
        From: domaindrivendesign@yahoogroups.com
        [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dirk Riehle
        Sent: Wednesday, July 13, 2005 12:12 PM
        To: domaindrivendesign@yahoogroups.com
        Subject: RE: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign]
        Re: Repositories and Transaction Handling

        We want to have exactly one EUR currency object, one USD currency object,
        etc. There should be only 150 or currency objects in use at any time.
        equals() relies on this design decision (equals is reduced to an identity
        check then).

        If you have a free Hibernate created instance, two EUR objects won't be
        equal if they aren't the same object.

        In an older app we used the framework this made quite a performance
        difference. (Not so in the current one.) Today it is not as critical any
        longer for us, but it is just how the framework is built. You can switch
        on/off sharing of value objects.

        Dirk



        At 13.07.2005, Molitor, Stephen L wrote:

        Dirk (not Roni!)
         
        Sorry, didn't read your post carefully enough.  Regarding #2, I didn't quite
        understand this bit:
         
        > In Hibernate you can get around that by declaring access to a field as
        access="field" which avoids using getters and setters but goes to the field
        > directly. But then you won't get the benefit of the setter where
        necessary. For example, some of our value objects are immutable shared
        objects > > (Currency) and having an anonymously created instance floating
        around breaks that model. Going back to getter/setter field access doesn't
        cut it
        > as the issue is independent of this.
         
        If the objects are immutable, why does it matter if they are shared or not? 
        How does having a Hibernate created instance floating around break the
        model?
         
        Steve

        ________________________________________
        From: domaindrivendesign@yahoogroups.com [
        mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Dirk Riehle
        Sent: Wednesday, July 13, 2005 4:23 AM
        To: domaindrivendesign@yahoogroups.com
        Subject: Domain Models and ORM/Hibernate (was: RE: [domaindrivendesign] Re:
        Repositories and Transaction Handling

        Hi all,

        we started using Hibernate about a week ago, and even though I think it is
        probably the best of the ORM tools available, it does get in the way with
        (a) proper domain modeling and (b) separating domain models from persistence
        layers.

        I thought I'd describe the main issues I'm having right now---maybe someone
        knows a better solution or at least finds this interesting.

        1. Value Objects. We have a whole library of value objects (an earlier
        version can be found on www.jvalue.org) and so we would like to map them
        into columns within the enclosing entity object's table.

        Hibernate lets you specify value objects as components, but then you have to
        repeat the component structure any time you use a specific value object. For
        example, in an Account class, a balance attribute might be mapped like this:

        <component name="balance" class="org.jvalue.finance.Money">
                 <property name="amount" access="field" column="BALANCE"/>
                 <component name="currency" access="field"
        class="org.jvalue.finance.Currency">
                         <property name="code" access="field" column="CURRENCY"/>
                 </component>
        </component>

        If you use Money objects some other place, you have to repeat that same
        definition in that other class mapping definition. So much about redundancy.

        Then I see Hibernate lets you specify classes as value objects, called user
        types. Unfortunately, you have to implement UserType or CompositeUserType.
        For us, this is out of the question, as we can't change/reimplement/extend
        our library that way. Wasn't a good OR Mapper supposed to be non-invasive?

        2. Field access. Hibernate wants us to use getters and setter for
        loading/saving objects. This gets in the way of domain semantics, for
        example some of our (legacy) code uses old-style assertions, for example:

        class Posting...

                public void setValidityDate(JDate date) {
                         // FIXME: assertIsNotSealed();
                         validityDate = JDate.getValue(date.asMilliseconds());
                }
        }

        assertIsNotSealed() throws an exception if this posting to a book had been
        carried out, hence sealed, and is supposed not to be touched. That behavior
        is part of the domain model for sure!

        In Hibernate you can get around that by declaring access to a field as
        access="field" which avoids using getters and setters but goes to the field
        directly. But then you won't get the benefit of the setter where necessary.
        For example, some of our value objects are immutable shared objects
        (Currency) and having an anonymously created instance floating around breaks
        that model. Going back to getter/setter field access doesn't cut it as the
        issue is independent of this.

        Anyway, long post, rather frustratedly, but still interesting, I hope.

        Dirk


        Interested in wikis? Please go to http://www.wikisym.org!
        Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
        Dirk Riehle | +49 172 184 8755 | http://www.riehle.org


                




        At 12.07.2005, Billy McCafferty wrote:

        Theres a great example of separating the transactional layer in Chapter 8
        of Hibernate in Action by Christian Bauer and Gavin King.
         
        Billy McCafferty
         
         
        -----Original Message-----
        From: domaindrivendesign@yahoogroups.com [
        mailto:domaindrivendesign@yahoogroups.com] On Behalf Of andrew_raphael_small
        Sent: Saturday, July 09, 2005 1:22 PM
        To: domaindrivendesign@yahoogroups.com
        Subject: [domaindrivendesign] Re: Repositories and Transaction Handling
         
        --- In domaindrivendesign@yahoogroups.com, Rex Madden
        <rexmadden@g...> wrote:
        > Any OR mapping tool will have several options for handling
        transactions. For
        > example, in Hibernate, the simplest method is to pass a session to
        your
        > repository which is opened at the beginning of a request, and then
        flushed
        > and closed at the end of a request (assuming you are talking about
        a web
        > app). You can use a ServletFilter to do the opening and closing.
        >  Of course, there are more sophisticated patterns for complicated
        scenarios,
        > but that's a good way to start.
        >
        >
        > --
        > Rex Madden

        I would be very interested to learn about those more sophisticated
        patterns.  Do you know some references that I can look at?  I want to
        set up our application to use the simple pattern you describe but I
        also want to be ready to address the complicated scenarios that we
        may encounter.

        Andrew Small



        <?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?----
        HM ADS ?>
        ________________________________________
        YAHOO! GROUPS LINKS
        •  Visit your group " domaindrivendesign" on the web.
        •  To unsubscribe from this group, send an email to:
        •   domaindrivendesign-unsubscribe@yahoogroups.com
        •  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

        ________________________________________
        <?---- LSpots keywords ?><?---- HM ADS ?> <?---- LSpots keywords ?> <?----
        HM ADS ?>
        ________________________________________
        YAHOO! GROUPS LINKS
        •  Visit your group " domaindrivendesign" on the web.
        •  
        •  To unsubscribe from this group, send an email to:
        •   domaindrivendesign-unsubscribe@yahoogroups.com
        •  
        •  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

        ________________________________________
        Interested in wikis? Please go to http://www.wikisym.org!
        Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
        Dirk Riehle | +49 172 184 8755 | http://www.riehle.org

        ________________________________________
        YAHOO! GROUPS LINKS

        •  Visit your group "domaindrivendesign" on the web.
         
        •  To unsubscribe from this group, send an email to:
         domaindrivendesign-unsubscribe@yahoogroups.com
         
        •  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

        ________________________________________
      • Eric Evans
        ... Dirk, doesn t that depend on how the currency object is implemented? If equals() compares the currency code, then two EUR objects would be equal, whether
        Message 3 of 8 , Jul 13, 2005
        View Source
        • 0 Attachment
          Dirk Riehle wrote:

          > We want to have exactly one EUR currency object, one USD currency
          > object, etc. There should be only 150 or currency objects in use at
          > any time. equals() relies on this design decision (equals is reduced
          > to an identity check then).
          >
          > If you have a free Hibernate created instance, two EUR objects won't
          > be equal if they aren't the same object.
          >
          Dirk, doesn't that depend on how the currency object is implemented? If
          equals() compares the currency code, then two EUR objects would be
          equal, whether they are the same object or not. This is how a value
          object should behave. (Not actually sure about the Java Currency in this
          regard. Maybe I should check.)

          Ordinarily, I would think that having a single instance of each currency
          would only be important as an optimization, if you had so many of them
          that they hogging memory or taking too much time to instantiate. Do you
          think this will often be the case? Or are there other reasons you want
          to control this?
        • Molitor, Stephen L
          If it does matter, you might be able to write a Hibernate Interceptor and implement the newInstance method to control things. Instead of instantiating
          Message 4 of 8 , Jul 13, 2005
          View Source
          • 0 Attachment
            If it does matter, you might be able to write a Hibernate Interceptor
            and implement the newInstance method to control things. Instead of
            instantiating objects itself using the default constructor, Hibernate
            will invoke your code to instantiate objects, passing in the id. If
            that's what makes objects unique, then you can have newInstance always
            return the same object for the same id.

            (We use Interceptor.newInstance to have a dependency injection framework
            instantiate entities.)

            Steve

            -----Original Message-----
            From: domaindrivendesign@yahoogroups.com
            [mailto:domaindrivendesign@yahoogroups.com] On Behalf Of Eric Evans
            Sent: Wednesday, July 13, 2005 12:38 PM
            To: domaindrivendesign@yahoogroups.com
            Subject: Re: Domain Models and ORM/Hibernate (was: RE:
            [domaindrivendesign] Re: Repositories and Transaction Handling

            Dirk Riehle wrote:

            > We want to have exactly one EUR currency object, one USD currency
            > object, etc. There should be only 150 or currency objects in use at
            > any time. equals() relies on this design decision (equals is reduced
            > to an identity check then).
            >
            > If you have a free Hibernate created instance, two EUR objects won't
            > be equal if they aren't the same object.
            >
            Dirk, doesn't that depend on how the currency object is implemented? If
            equals() compares the currency code, then two EUR objects would be
            equal, whether they are the same object or not. This is how a value
            object should behave. (Not actually sure about the Java Currency in this
            regard. Maybe I should check.)

            Ordinarily, I would think that having a single instance of each currency
            would only be important as an optimization, if you had so many of them
            that they hogging memory or taking too much time to instantiate. Do you
            think this will often be the case? Or are there other reasons you want
            to control this?



            Yahoo! Groups Links
          • Molitor, Stephen L
            ... currency would only be important as an optimization, if ... time to instantiate. Do you think this will often be ... I agree. It sounds like you re
            Message 5 of 8 , Jul 13, 2005
            View Source
            • 0 Attachment
              > Ordinarily, I would think that having a single instance of each
              currency would only be important as an optimization, if
              > you had so many of them that they hogging memory or taking too much
              time to instantiate. Do you think this will often be
              > the case? Or are there other reasons you want to control this?

              I agree. It sounds like you're coupling a domain issue (what makes two
              value objects equivalent) with an optimization issue (how many distinct
              instances of equivalent value objects do we have). It seems like the
              equals method should be based on logical properties, not identity. The
              method that instantiates the value objects should worry about sharing
              instances. One should be able to turn off sharing without breaking the
              equals method.

              I think. But it really depends.... ;)

              Steve
            • Rex Madden
              Do you inject dependencies into Entities often? It seems like something I try to avoid, but I may be wrong. ... -- Rex Madden Director of Technology Cyrus
              Message 6 of 8 , Jul 13, 2005
              View Source
              • 0 Attachment
                Do you inject dependencies into Entities often?  It seems like something I try to avoid, but I may be wrong.

                On 7/13/05, Molitor, Stephen L <Stephen.L.Molitor@...> wrote:


                (We use Interceptor.newInstance to have a dependency injection framework
                instantiate entities.)

                Steve

                -----Original Message-----
                From: domaindrivendesign@yahoogroups.com
                [mailto:domaindrivendesign@yahoogroups.com ] On Behalf Of Eric Evans
                Sent: Wednesday, July 13, 2005 12:38 PM
                To: domaindrivendesign@yahoogroups.com
                Subject: Re: Domain Models and ORM/Hibernate (was: RE:
                [domaindrivendesign] Re: Repositories and Transaction Handling

                Dirk Riehle wrote:

                > We want to have exactly one EUR currency object, one USD currency
                > object, etc. There should be only 150 or currency objects in use at
                > any time. equals() relies on this design decision (equals is reduced
                > to an identity check then).
                >
                > If you have a free Hibernate created instance, two EUR objects won't
                > be equal if they aren't the same object.
                >
                Dirk, doesn't that depend on how the currency object is implemented? If
                equals() compares the currency code, then two EUR objects would be
                equal, whether they are the same object or not. This is how a value
                object should behave. (Not actually sure about the Java Currency in this
                regard. Maybe I should check.)

                Ordinarily, I would think that having a single instance of each currency
                would only be important as an optimization, if you had so many of them
                that they hogging memory or taking too much time to instantiate. Do you
                think this will often be the case? Or are there other reasons you want
                to control this?



                Yahoo! Groups Links









                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                   http://groups.yahoo.com/group/domaindrivendesign/

                <*> To unsubscribe from this group, send an email to:
                   domaindrivendesign-unsubscribe@yahoogroups.com

                <*> Your use of Yahoo! Groups is subject to:
                   http://docs.yahoo.com/info/terms/






                --
                Rex Madden
                Director of Technology
                Cyrus Innovation
                IT Consulting and Agile Software Development
                New York City, New York

                http://www.cyrusinnovation.com
                rmadden@...
              • Dirk Riehle
                ... Yes, it is an optimization. Using identity to check for equality doesn t violate value semantics, as long as you can guarantee that there is only one
                Message 7 of 8 , Jul 14, 2005
                View Source
                • 0 Attachment
                  > > We want to have exactly one EUR currency object, one USD currency
                  > > object, etc. There should be only 150 or currency objects in use at
                  > > any time. equals() relies on this design decision (equals is reduced
                  > > to an identity check then).
                  > >
                  > > If you have a free Hibernate created instance, two EUR objects won't
                  > > be equal if they aren't the same object.
                  > >
                  >Dirk, doesn't that depend on how the currency object is implemented? If
                  >equals() compares the currency code, then two EUR objects would be
                  >equal, whether they are the same object or not. This is how a value
                  >object should behave. (Not actually sure about the Java Currency in this
                  >regard. Maybe I should check.)

                  Yes, it is an optimization. Using identity to check for equality doesn't
                  violate value semantics, as long as you can guarantee that there is only
                  one instance of a specific value.

                  The point is: JValue is a framework, so we can't optimize for one specific
                  use but rather let users decide. The actual identity check isn't even done
                  in Currency but up in the hierarchy, in AbstractValue. equals(Object other)
                  looks something like this: return (other != null) || (other == this) ||
                  (!type.isShared() && hasEquivalentType(other) && doEquals(other)); doEquals
                  does the traditional field by field comparison and is implemented by
                  subclasses of AbstractValue (like Currency).

                  Once you do a full framework approach, it can get complicated.
                  type.isShared() tells you whether this value type is in shared mode or not.
                  hasEquivalentType() checks whether different implementations of the same
                  value type are considered equivalent. Not so much an issue with Currency,
                  but we used structured names a lot (www.ddd.org is a structured name with
                  three components and the delimiter '.'), and had different implementations
                  (Whole name in a single string, name components pre-parsed in an array or
                  list.)

                  The curse of trying to do it right for all possible uses :-) But fun.

                  Dirk

                  PS: Yes, it was all necessary. JValue was used in a high-performance
                  infrastructure as well as a low-performing simulation environment at my
                  prior company (SKYVA). The simulation environment was part of a UML IDE
                  that let you introduce new value types (UML datatypes) at runtime so we
                  needed to allow for runtime creation of value types which meant a whole
                  explicit modeling level for value types.

                  PPS: I'm just reading up on Domain-Specific Languages or "language-oriented
                  programming". If you want to do something like this, you'll end up doing
                  something like JValue. So I'm sure JetBrains, MS, and Intentional Software
                  have gone through the same problems.



                  Interested in wikis? Please go to http://www.wikisym.org!
                  Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
                  Dirk Riehle | +49 172 184 8755 | http://www.riehle.org
                • Dirk Riehle
                  ... Excellent idea, thanks! (Just didn t think of it.) ... Thanks for the pointer. I didn t get this from reading the reference manual. I thought your value
                  Message 8 of 8 , Jul 14, 2005
                  View Source
                  • 0 Attachment
                    Are you using Money specifically as a balance property mapped to BALANCE
                    and CURRENCY columns in many objects? If so, then you might consider
                    including the Money component definition as a XML entity. If not, then
                    you really don't have that much duplication/redundancy.

                    Excellent idea, thanks! (Just didn't think of it.)


                    > Then I see Hibernate lets you specify classes as value objects, called
                    > user types. Unfortunately, you have to implement UserType or
                    > CompositeUserType. For us, this is out of the question, as we can't
                    > change/reimplement/extend our library that way. Wasn't a good OR
                    > Mapper supposed to be non-invasive?

                    Have you looked at the example at http://www.hibernate.org/172.html?
                    It shows how to use a UserType adapter to persist an immutable
                    value without extending it.

                    Thanks for the pointer. I didn't get this from reading the reference manual.

                    I thought your value classes have to implement the UserType interface. But I hear you say you can actually just set up a mirror class hierarchy of UserType implementations for the value classes. Still a lot of work (where I thought a mapping description would suffice) but better than invasively modifying the library.


                    > In Hibernate you can get around that by declaring access to a field as
                    > access="field" which avoids using getters and setters but goes to the
                    > field directly. But then you won't get the benefit of the setter where
                    > necessary. For example, some of our value objects are immutable shared
                    > objects (Currency) and having an anonymously created instance floating
                    > around breaks that model. Going back to getter/setter field access
                    > doesn't cut it as the issue is independent of this.

                    I don't understand some of the issues here. Are you saying that you
                    have a specific mapped property that sometimes should be set directly
                    on a field and other times should be set using a setter method?

                    It only varies by type of property. I'm sure Hibernate lets me inject an adapter or so to handle this situation. I just have to re-read the manual to see which of the extension interfaces do the job best. Maybe the Inteceptor recommendation.

                    Thanks for the help!

                    Dirk


                    Interested in wikis? Please go to http://www.wikisym.org!
                    Take a Geek's Tour of Silicon Valley! http://www.ageekstour.com
                    Dirk Riehle | +49 172 184 8755 | http://www.riehle.org

                  Your message has been successfully submitted and would be delivered to recipients shortly.