Software Público Brasileiro

<!DOCTYPE partintro PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"  [ ]>
<partintro>

   <para>
      The first major theme of CDI is <emphasis>loose coupling</emphasis>. We've already seen three means of achieving
      loose coupling:
   </para>

   <itemizedlist>
      <listitem>
         <para>
            <emphasis>alternatives</emphasis> enable deployment time polymorphism,
         </para>
      </listitem>
      <listitem>
         <para>
            <emphasis>producer methods</emphasis> enable runtime polymorphism, and</para>
      </listitem>
      <listitem>
         <para>
            <emphasis>contextual lifecycle management</emphasis> decouples bean lifecycles.
         </para>
      </listitem>
   </itemizedlist>

   <para>
      These techniques serve to enable loose coupling of client and server. The client is no longer tightly bound to an
      implementation of an interface, nor is it required to manage the lifecycle of the implementation. This approach 
      lets <emphasis>stateful objects interact as if they were services</emphasis>.
   </para>

   <para>
      Loose coupling makes a system more <emphasis>dynamic</emphasis>. The system can respond to change in a
      well-defined manner. In the past, frameworks that attempted to provide the facilities listed above invariably did
      it by sacrificing type safety (most notably by using XML descriptors). CDI is the first technology, and certainly
      the first specification in the Java EE platform, that achieves this level of loose coupling in a typesafe way.
   </para>

   <para>
      CDI provides three extra important facilities that further the goal of loose coupling:
   </para>

   <itemizedlist>
      <listitem>
         <para>
            <emphasis>interceptors</emphasis> decouple technical concerns from business logic,
         </para>
      </listitem>
      <listitem>
         <para>
            <emphasis>decorators</emphasis> may be used to decouple some business concerns, and
         </para>
      </listitem>
      <listitem>
         <para>
            <emphasis>event notifications</emphasis> decouple event producers from event consumers.
         </para>
      </listitem>
   </itemizedlist>

   <para>
      The second major theme of CDI is <emphasis>strong typing</emphasis>. The information about the dependencies,
      interceptors and decorators of a bean, and the information about event consumers for an event producer, is
      contained in typesafe Java constructs that may be validated by the compiler.
   </para>
  
   <para>
      You don't see string-based identifiers in CDI code, not because the framework is hiding them from you using clever
      defaulting rules&#8212;so-called "configuration by convention"&#8212;but because there are simply no strings
      there to begin with!
   </para>

   <para>
      The obvious benefit of this approach is that <emphasis>any</emphasis> IDE can provide autocompletion, validation
      and refactoring without the need for special tooling. But there is a second, less-immediately-obvious, benefit.
      It turns out that when you start thinking of identifying objects, events or interceptors via annotations instead
      of names, you have an opportunity to lift the semantic level of your code.
   </para>

   <para>
      CDI encourages you develop annotations that model concepts, for example,
   </para>

   <itemizedlist>
      <listitem>
         <para><literal>@Asynchronous</literal>,</para>
      </listitem>
      <listitem>
         <para><literal>@Mock</literal>,</para>
      </listitem>
      <listitem>
         <para><literal>@Secure</literal> or</para>
      </listitem>
      <listitem>
         <para><literal>@Updated</literal>,</para>
      </listitem>
   </itemizedlist>

   <para>instead of using compound names like</para>

   <itemizedlist>
      <listitem>
         <para><literal>asyncPaymentProcessor</literal>,</para>
      </listitem>
      <listitem>
         <para><literal>mockPaymentProcessor</literal>,</para>
      </listitem>
      <listitem>
         <para><literal>SecurityInterceptor</literal> or</para>
      </listitem>
      <listitem>
         <para><literal>DocumentUpdatedEvent</literal>.</para>
      </listitem>
   </itemizedlist>

   <para>
      The annotations are reusable. They help describe common qualities of disparate parts of the system. They help us
      categorize and understand our code. They help us deal with common concerns in a common way. They make our code
      more literate and more understandable.
   </para>
  
   <para>
      CDI <emphasis>stereotypes</emphasis> take this idea a step further. A stereotype models a common
      <emphasis>role</emphasis> in your application architecture. It encapsulates various properties of the role,
      including scope, interceptor bindings, qualifiers, etc, into a single reusable package. (Of course, there is also
      the benefit of tucking some of those annotations away).
   </para>
  
   <!--
   <para>
      Even Web Beans XML metadata is strongly typed! There's no compiler for XML, so Web Beans takes advantage of XML
      schemas to validate the Java types and attributes that appear in XML. This approach turns out to make the XML more
      literate, just like annotations made our Java code more literate.
   </para>
   -->
  
   <para>
      We're now ready to meet some more advanced features of CDI. Bear in mind that these features exist to make our
      code both easier to validate and more understandable. Most of the time you don't ever really
      <emphasis>need</emphasis> to use these features, but if you use them wisely, you'll come to appreciate their
      power.
   </para>

<!--
vim:et:ts=3:sw=3:tw=120
-->
</partintro>