Skip to Content

Rumours are that here will, from WAS version 8.0, be 3 different categories of ABAP classes: Upper, Middle, and Lower. What follows is an exclusive heads-up regarding these revolutionary new features of ABAP!

 

Upper classes:

  • Upper classes can invoke methods of middle and lower classes (but only call favours of other upper classes).
  • Upper classes are always abstract.
  • Upper classes are allowed to call a specific default method of lower classes: Abuse.
  • Upper classes normally refuse to be friends with most middle, and all lower classes. This will result in compilation errors (for middle class friendships) and system dumps (for lower class friendships).
  • Upper classes will occasionally try to allocate a higher amount of system resources for their own use – as long as this is not noticed by the dispatcher. Whenever attention is brought to this point, the upper class in question will instantly re-model itself or automatically re-implement itself in a different application server with more generous system resources.
  • The attributes of the upper classes are generally more beautiful and well-shaped than those of the middle and lower classes.
  • Some of the methods of upper classes are completely empty.

 

Middle classes:

  • Middle classes can only invoke methods of other middle or lower classes.
  • Middle classes usually have a wide range of methods, but are somewhat more demanding on system resources than lower classes (see below).
  • Middle classes are relatively stable compared with lower (and upper) classes, especially during times of system stability. In an unstable system, however, they will be more prone to failing.
  • Middle classes will perform noticeably better when co-existing in an application with upper classes (especially when their methods are called by upper classes). Less so if they are combined with lower classes, whereby they become more likely not to respond.

 

Lower classes:

  • Lower classes can only call methods of other lower classes, never those of middle or upper classes. If a lower class tries to call the methods of an upper class, the upper class will ignore it. Lower classes calling methods of a middle class may result in the middle class throwing an exception.
  • Lower classes cannot even exist in an application containing upper classes. Such applications will not compile.
  • (The concept of having a sub-type of lower classes called a “working class” was abandoned early on due to a high percentage of such implementations were shown to not respond to their own methods).
  • Lower classes generally have very limited sets of methods, but more (and larger) attributes than upper or middle classes. Besides, the attributes of the lower classes are generally uglier, since they usually only inherit from other lower classes (never from upper classes). In general, as the system grows, the functionality of most lower classes will become less desirable and the classes will eventually make themselves redundant.

 

Epilogue:

More and more applications now rely on a specific type of interfaces which are implemented via so-called Outsourced Classes (classes that are implemented in a different application server entirely, and only called upon when needed). This application server usually runs in a different time zone.

To report this post you need to login first.

16 Comments

You must be Logged on to comment or reply to a post.

  1. Volker Wegert
    Trond,

    I think you’re on the right track, but you’ll probably have to refine your hierarchy definition by specifying the garbage collection behaviour. A proposal:
    Upper classes will expect their garbage to be cleaned up without any intervention of their own.
    Middle classes will pretend to clean up garbage, but rather redistribute it instead of actually getting rid of it.
    Lower classes are regarded as garbage by upper and middle classes and subject to cleaning up.

      Volker

    (0) 
    1. Trond Stroemme Post author
      Brilliant addition, Volker!

      Of course, a consequence of this is that the lower classes will, on regular intervals, invoke some of their nastier methods (all at the same time) causing the systems administrator to launch Firefighter in order to restore stability.

      A specific transaction within Firefighter (FF_SPRAY) will be added to cope with these events.

      (0) 
  2. Luís Pérez Grau
    hmmmm… I don’t get the advantages of split one object in 3 classes, looks som kind of evolved frienship, but really I don’t get the point. It will be great if you share a source of information about this kind of technology to understand better what’s behind of it and have a richer discussion.

    Regards,

    Luis

    (0) 
  3. Michelle Crapo
    Drum roll please:

    The billionaire class – I think it should go before the upper class.

    How about a lower, lower class where they need some assistance from the other classes just to keep up with maintenance!

    And somewhere maybe in a different structure there is the management class.  I wonder what they do.

    I loved this one LOL,

    Michelle

    (0) 
    1. Trond Stroemme Post author
      I don’t think the management class would do much, except deter system performance and occasionally re-organize themselves according to a complex algorithm located in the SAP kernel.

      As for the billionaire class, it will be a very small subset of the upper class. The billionaire class will basically reside in its own system, which will be physically removed from other systems (no common blades, please). It will communicate with other (billionaire) classes via tRFC’s (transcendental RFC’s).

      There are rumours that a small group of the billionaire classes are actually responsible for managing the whole system, but since all their methods are private and the code hidden, this can not be proved.

      (0) 
    2. Suhas Saha
      Management classes generate singleton objects, that too on their own discretion.

      These objects are usually not available when required & WAS 8.0 class documentation states, “These classes are not (yet) 100% tested. Use at your own risk”.

      Cheers,
      Suhas

      (0) 
  4. Christopher Solomon
    So from this, can I speculate that WAS 8.0 will simply operate on one common, shared token system that all classes will pass around?…of course the upper classes will accumulate more while the middle classes generate most….and the lower classes will take freed up resources wherever they can get them.

    Thanks for the giggles. =)

    (0) 

Leave a Reply