실습문서 Cugain의 샘플프로젝트 jpetstore 분석기 - (7) PetStoreImpl.java

/**
 * JPetStore primary business object.
 *
 * <p>This object makes use of five DAO objects, decoupling it
 * from the details of working with persistence APIs. Thus
 * although this application uses iBATIS for data access,
 * another persistence tool could be dropped in without
 * breaking this class.
 *
 * <p>The DAOs are made available to the instance of this object
 * using Dependency Injection. (The DAOs are in turn configured
 * using Dependency Injection.) We use Setter Injection here,
 * exposing JavaBean setter methods for each DAO. This means there is
 * a JavaBean "property" for each DAO. In this case the properties
 * are write-only: there is no getter method to accompany the
 * setter methods. Getter methods are optional: implement them
 * only if you want to expose access to the properties in your
 * business object.
 *
 * <p>There is one instance of this class in the JPetStore application.
 * In Spring terminology, it is a "singleton". This means a
 * per-Application Context singleton. The factory creates a single
 * instance; there is no need for a private constructor, static
 * factory method etc as in the traditional implementation of
 * the Singleton Design Pattern.
 *
 * <p>This is a POJO. It does not depend on any Spring APIs.
 * It's usable outside a Spring container, and can be instantiated
 * using new in a JUnit test. However, we can still apply declarative
 * transaction management to it using Spring AOP.
 *
 * <p>This class defines a default transaction attribute for all methods.
 * Note that this attribute definition is only necessary if using Commons
 * Attributes auto-proxying (see the "attributes" directory under the root of
 * JPetStore). No attributes are required with a TransactionFactoryProxyBean,
 * as in the default applicationContext.xml in the war/WEB-INF directory.
 *
 * <p>The following attribute definition uses Commons Attributes attribute syntax.
 * @@org.springframework.transaction.interceptor.DefaultTransactionAttribute()
 *
 * @author Juergen Hoeller
 * @since 30.11.2003
 */

/**
 * JAX-RPC OrderService endpoint that simply delegates to the OrderService
 * implementation in the root web application context. Implements the plain
 * OrderService interface as service interface, just like the target bean does.
 *
 * <p>This proxy class is necessary because JAX-RPC/Axis requires a dedicated
 * endpoint class to instantiate. If an existing service needs to be exported,
 * a wrapper that extends ServletEndpointSupport for simple application context
 * access is the simplest JAX-RPC compliant way.
 *
 * <p>This is the class registered with the server-side JAX-RPC implementation.
 * In the case of Axis, this happens in "server-config.wsdd" respectively via
 * deployment calls. The Web Service tool manages the lifecycle of instances
 * of this class: A Spring application context can just be accessed here.
 *
 * <p>Note that this class does <i>not</i> implement an RMI port interface,
 * despite the JAX-RPC spec requiring this for service endpoints. Axis and
 * other JAX-RPC implementations are known to accept non-RMI endpoint classes
 * too, so there's no need to maintain an RMI port interface in addition to
 * the existing non-RMI service interface (OrderService).
 *
 * <p>If your JAX-RPC implementation imposes a strict requirement on a service
 * endpoint class to implement an RMI port interface, then let your endpoint
 * class implement both the non-RMI service interface and the RMI port interface.
 * This will work as long as the methods in both interfaces just differ in the
 * declared RemoteException. Of course, this unfortunately involves double
 * maintenance: one interface for your business logic, one for JAX-RPC.
 * Therefore, it is usually preferable to avoid this if not absolutely necessary.
 *
 * @author Juergen Hoeller
 * @since 26.12.2003
 */