[jboss-cvs] JBossAS SVN: r66563 - projects/microcontainer/trunk/docs/User_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Tue Oct 30 06:03:07 EDT 2007
Author: newtonm
Date: 2007-10-30 06:03:07 -0400 (Tue, 30 Oct 2007)
New Revision: 66563
Modified:
projects/microcontainer/trunk/docs/User_Guide/en-US/User_Guide.xml
Log:
Added definition of POJOs.
Modified: projects/microcontainer/trunk/docs/User_Guide/en-US/User_Guide.xml
===================================================================
--- projects/microcontainer/trunk/docs/User_Guide/en-US/User_Guide.xml 2007-10-30 09:39:16 UTC (rev 66562)
+++ projects/microcontainer/trunk/docs/User_Guide/en-US/User_Guide.xml 2007-10-30 10:03:07 UTC (rev 66563)
@@ -31,12 +31,12 @@
<para>Java EE (Enterprise Edition) - Servers (typically running 3-tier applications)</para>
</listitem>
</itemizedlist>
- <para>Each environment aims to provide a base level of functionality on top of which developers can add their own code to create applications. For example Java SE provides networking and security libraries together with graphical user interface toolkits to facilitate the development of desktop and simple client-server applications. Java EE takes this a stage further by adding a number of 'enterprise' services such as transactions, messaging, and persistence that allow much more robust and scalable 'enterprise' applications to be developed. These services are typically combined together inside a JEE application server to provide a standard runtime environment for enterprise applications however it is often the case that we do not need to use them all.</para>
+ <para>Each environment aims to provide a base level of functionality on top of which developers can add their own code to create applications. For example Java SE provides networking and security libraries together with graphical user interface toolkits to facilitate the development of desktop and simple client-server applications. Java EE takes this a stage further by adding a number of 'enterprise' services such as transactions, messaging, and persistence that allow much more robust and scalable 'enterprise' applications to be developed. These services are typically combined together inside a JEE application server to provide a standard runtime environment for enterprise applications, however it is often the case that we do not need to use them all.</para>
<para>Having unused services in your environment is undesirable as they can take up valuable resources such as CPU and memory. They can also clutter up the environment with unecessary configuration files which complicates maintenance and causes confusion. It would therefore be good if there was a controlled way to remove them without breaking any dependencies they might have. Similarly there are often occasions when applications need services that aren't provided by JEE so it would be good if there was a controlled way to add them, again making sure that any dependencies are first satisfied.</para>
<para>JBoss Microcontainer aims to provide these capabilities by allowing services, created using Plain Old Java Objects (POJOs), to be deployed into a standard Java SE runtime environment in a controlled manner to create a customized environment for your applications. Dependencies between services are fully managed by the microcontainer to ensure that new services cannot be deployed until services they depend on have first been deployed. Likewise undeploying a service causes all dependent services to first be undeployed to maintain the integrity of the system. </para>
- <para>Deploying services in this way, on top of a Java SE environment, is exactly how we have created the latest version of JBoss Application Server (JBoss AS 5.0) which provides a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. This even applies to different Java EE environments such as Glassfish since you can plug in different classloading models during the service deployment phase.</para>
+ <para>Deploying services in this way, on top of a Java SE environment, is exactly how we have created the latest version of JBoss Application Server (JBoss AS 5.0) which provides a standard Java EE environment. If you need additional services then you can simply deploy these on top of Java EE to provide the functionality you need. This even applies when using the microcontainer in different Java EE environments such as Glassfish since you can plug in different classloading models during the service deployment phase.</para>
<para>Since JBoss Microcontainer is very lightweight and deals with POJOs it can also be used to deploy services into a Java ME runtime environment. This opens us new possibilities for mobile applications that can now take advantage of enterprise services without requiring a full JEE application server. </para>
- <para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either XML or annotations depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the runtime environment, allowing you to access POJOs and services from your test methods using just a few lines of code.</para>
+ <para>In common with other lightweight containers JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either XML or annotations depending on where the information is best located. Finally unit testing is made extremely simple thanks to a helper class that extends JUnit to setup the test environment, allowing you to access POJOs and services from your test methods using just a few lines of code.</para>
</chapter>
<chapter>
<title>Download and Installing</title>
@@ -49,6 +49,19 @@
</chapter>
<chapter>
<title>Building Services</title>
+ <para><emphasis role="bold">
+ <emphasis role="underline">POJOs</emphasis>
+ </emphasis></para>
+ <para>The term POJO is an acronym for Plain Old Java Object and was first coined while Rebecca Parsons, Josh MacKenzie, and Martin Fowler were preparing for a talk at a conference in September 2000. It describes the practice of encoding business logic in regular java objects instead of components such as EJB 2.1 Entity Beans. The benefit of this approach is that you're not required to implement any special interfaces. This not only keeps your code simple but allows it to be used in a wider variety of environments and makes it easy to unit test.</para>
+ <para><emphasis role="bold">Definition:</emphasis> <emphasis role="italic">A POJO declares business methods, which define behaviour, and properties, which represent state. Some properties represent associations to other POJOs.</emphasis></para>
+ <para>For experienced developers this should sound familiar as it mimicks almost exactly the proposals set out in the JavaBeans specification. JavaBeans describes a component model for User Interface development emphasizing simplicity and standardized naming conventions for property accessor methods. The idea was that this would allow automatic discovery of an object's properties so that an instance could easily be created and populated with state at runtime. The main use case was creating and configuring visual user interface components such as text boxes, buttons, and tables from within an integrated development environment (IDE).</para>
+ <para><emphasis role="bold">Definition:</emphasis> <emphasis role="italic">A Java Bean is a reusable software component that can be manipulated visually in a builder tool.</emphasis></para>
+ <para> Importantly a Java Bean is not required to inherit from any particular base class or interface. Also while Java Beans are primarily targeted at builder tools they are entirely usable by human programmers.</para>
+ <para>Strictly speaking a Java Bean should include support for events and persistence but in many cases developers choose not to implement these features and simply follow the standardized naming conventions for property accessor methods; i.e. get and set. This 'lightweight' form of Java Bean is commonly referred to as just a 'bean' and is semantically equivalent to a POJO.</para>
+ <para>The terms POJO and bean are therefore interchangeable and you will encounter both in the microcontainer documentation and configuration files.</para>
+ <para><emphasis role="bold">
+ <emphasis role="underline">Services</emphasis>
+ </emphasis></para>
<para>The word 'service' has many definitions in the English language but in the context of developing Java applications it is helpful to define it as follows:</para>
<orderedlist>
<listitem>
@@ -67,14 +80,13 @@
<para>Q) Does a class have to implement an interface in order to provide a 'well-defined' interface?</para>
<para>A) Not necessarily. Providing that we don't change the public method signatures of the class then we can always change its implementation without needing to recompile our client. The 'well-defined' interface in this respect is composed from the public method signatures.</para>
<note>
- <para>Implementing an interface is only necessary if we want to allow a client to <emphasis role="bold">choose</emphasis> between <emphasis role="bold">different implementations</emphasis>. i.e. if the client is compiled against an interface then we can provide as many different implementations of the interface as we like without having to recompile the client.</para>
+ <para>Implementing an interface is only necessary if we want to allow a client to <emphasis role="bold">choose</emphasis> between <emphasis role="bold">alternative implementations</emphasis>. i.e. if the client is compiled against an interface then we can provide as many different implementations of the interface as we like without having to recompile the client.</para>
</note>
- <para>What then must we do in order to create a service using a POJO? The answer is to provide a registry that allows us to register a reference to the POJO instance with a name. Clients can then lookup the POJO reference using the name at runtime and use it to perform work. The POJO class is not required to implement an interface unless it is important that the client can choose between different implementations. </para>
+ <para>What then must we do in order to create a service using a POJO? The answer is to provide a registry that allows us to register a reference to the POJO instance with a name. Clients can then lookup the POJO reference using the name at runtime and use it to perform work. The POJO class is not required to implement an interface unless it is important that the client can choose between alternative implementations. </para>
<para>JBoss Microcontainer provides such a registry in order that we can deploy our POJO services into a runtime environment such as Java SE and look them up from within our applications.</para>
<para>Since robust implementations of Java EE services are already available from JBoss.org and other communities, it is common for companies to focus on creating more 'business-oriented' services. For this reason we shall look at creating, configuring and testing a simple Human Resources service that can be used in a wide-variety of companies.</para>
<section>
<title>Creating POJOs</title>
- <para>Hibernate 115 - (page 114 describes what a POJO is) Mention the bridge to bean through the Java Bean spec.</para>
</section>
<section>
<title>Wiring POJOs together </title>
More information about the jboss-cvs-commits
mailing list