Context
Service lookup and creation involves complex interfaces and network operations.
Problem
J2EE clients interact with service components, such as Enterprise JavaBeans (EJB)
and Java Message Service (JMS) components, which provide business services and
persistence capabilities. To interact with these components, clients must either locate the
service component (referred to as a lookup operation) or create a new component. For
instance, an EJB client must locate the enterprise bean's home object, which the client then
uses either to find an object or to create or remove one or more enterprise beans. Similarly,
a JMS client must first locate the JMS Connection Factory to obtain a JMS Connection or a
JMS Session.
All Java 2 Platform, Enterprise Edition (J2EE) application clients use the JNDI
common facility to look up and create EJB and JMS components. The JNDI API enables
clients to obtain an initial context object that holds the component name to object bindings.
The client begins by obtaining the initial context for a bean's home object. The initial
context remains valid while the client session is valid. The client provides the JNDI
registered name for the required object to obtain a reference to an administered object. In
the context of an EJB application, a typical administered object is an enterprise bean's home
object. For JMS applications, the administered object can be a JMS Connection Factory (for
a Topic or a Queue) or a JMS Destination (a Topic or a Queue).
So, locating a JNDI-administered service object is common to all clients that need to
access that service object. That being the case, it is easy to see that many types of clients
repeatedly use the JNDI service, and the JNDI code appears multiple times across these
clients. This results in an unnecessary duplication of code in the clients that need to look up
services.
Also, creating a JNDI initial context object and performing a lookup on an EJB home
object utilizes significant resources. If multiple clients repeatedly require the same bean
home object, such duplicate effort can negatively impact application performance.
Let us examine the lookup and creation process for various J2EE components.
The lookup and creation of enterprise beans relies upon the following:
A correct setup of the JNDI environment so that it connects to the naming and
directory service used by the application. Setup entails providing the location of the naming
service and the necessary authentication credentials to access that service.
The JNDI service can then provide the client with an initial context that acts as a
placeholder for the component name-to-object bindings. The client requests this initial
context to look up the EJBHome object for the required enterprise bean by providing the
JNDI name for that EJBHome object.
Find the EJBHome object using the initial context's lookup mechanism.
After obtaining the EJBHome object, create, remove, or find the enterprise bean,
using the EJBHome object's create, move, and find (for entity beans only).
The lookup and creation of JMS components (Topic, Queue, QueueConnection,
QueueSession, TopicConnection, TopicSession, and so forth) involves the following steps.
Note that in these steps, Topic refers to the publish/subscribe messaging model and Queue
refers to the point-to-point messaging model.
Set up the JNDI environment to the naming service used by the application. Setup
entails providing the location of the naming service and the necessary authentication
credentials to access that service.
Obtain the initial context for the JMS service provider from the JNDI naming service.
Use the initial context to obtain a Topic or a Queue by supplying the JNDI name for
the topic or the queue. Topic and Queue are JMSDestination objects.
Use the initial context to obtain a TopicConnectionFactory or a
QueueConnectionFactory by supplying the JNDI name for the topic or queue connection
factory.
Use the TopicConnectionFactory to obtain a TopicConnection or
QueueConnectionFactory to obtain a QueueConnection.
Use the TopicConnection to obtain a TopicSession or a QueueConnection to obtain a
QueueSession.
Use the TopicSession to obtain a TopicSubscriber or a TopicPublisher for the required
Topic. Use the QueueSession to obtain a QueueReceiver or a QueueSender for the required
Queue.
The process to look up and create components involves a vendor-supplied context
factory implementation. This introduces vendor dependency in the application clients that
need to use the JNDI lookup facility to locate the enterprise beans and JMS components,
such as topics, queues, and connection factory objects.
Forces
EJB clients need to use the JNDI API to look up EJBHome objects by using the
enterprise bean's registered JNDI name.
JMS clients need to use JNDI API to look up JMS components by using the JNDI
names registered for JMS components, such as connection factories, queues, and topics.
The context factory to use for the initial JNDI context creation is provided by the
service provider vendor and is therefore vendor- dependent. The context factory is also
dependent on the type of object being looked up. The context for JMS is different from the
context for EJB, with different providers.
Lookup and creation of service components could be complex and may be used
repeatedly in multiple clients in the application.
Initial context creation and service object lookups, if frequently required, can be
resource-intensive and may impact application performance. This is especially true if the
clients and the services are located in different tiers.
EJB clients may need to reestablish connection to a previously accessed enterprise
bean instance, having only its Handle object.
Solution
Use a Service Locator object to abstract all JNDI usage and to hide the complexities
of initial context creation, EJB home object lookup, and EJB object re-creation. Multiple
clients can reuse the Service Locator object to reduce code complexity, provide a single
point of control, and improve performance by providing a caching facility.
This pattern reduces the client complexity that results from the client's dependency on
and need to perform lookup and creation processes, which are resource-intensive. To
eliminate these problems, this pattern provides a mechanism to abstract all dependencies
and network details into the Service Locator.
- 浏览: 14447 次
- 性别:
- 来自: 北京
文章分类
最新评论
发表评论
-
集成层模式:Service Activator—服务激发器模式
2014-04-09 20:31 984ContextEnterprise beans and o ... -
集成层模式:Data Access Object—数据访问对象模式
2014-04-09 20:31 486ContextAccess to data varies ... -
表示层模式:Value List Handler—值列表处理器模式
2014-04-09 20:32 734ContextThe client requires a ... -
表示层模式:Transfer Object Assembler—传输对象组装器模式
2014-04-10 22:48 720ContextIn a Java 2 Platform, ... -
业务层模式:Composite Entity—复合实体模式
2014-04-08 21:38 462ContextEntity beans are not i ... -
业务层模式:Session Facade—会话门面模式
2014-04-08 21:38 399ContextEnterprise beans encap ... -
业务层模式:Transfer Object—传输对象模式
2014-04-08 21:37 395ContextApplication clients ne ... -
业务层模式:Business Delegate—业务委托模式
2014-04-08 21:37 950ContextA multi-tiered, distri ... -
表示层模式:Dispatcher View—分发者视图模式
2014-04-08 21:37 507ContextSystem controls flow o ... -
表示层模式:Service to Worker—工作者服务模式
2014-04-07 10:48 948ContextThe system controls flow ... -
表示层模式:Front Controller—前端控制器模式
2014-04-07 10:45 346ContextThe presentation-tier re ... -
表示层模式:Composite View—复合视图模式
2014-04-07 10:41 454ContextSophisticated Web page ... -
表示层模式:View Helper—视图助手模式
2014-04-07 10:37 993ContextThe system creates pre ... -
表示层模式:Intercepting Filter—拦截过滤器模式
2014-04-07 10:29 599Context The presentati ...
相关推荐
安装labview之后,如何解决NI service locator is not running
服务定位器模式(Service Locator Pattern)用在我们想使用 JNDI 查询定位各种服务的时候。考虑到为某个服务查找 JNDI 的代价很高,服务定位器模式充分利用了缓存技术。在首次请求某个服务时,服务定位器在 JNDI 中...
.NET 服务器定位模式(Service Locator Pattern)——Common Service Locator-附件资源
Autofac的ServiceLocator模式应用,零配置
Ckode.ServiceLocator Ckode.ServiceLocator是一个简单的本机实现的服务定位器,用于简化依赖项注入。 例子: 创建一个实例: var locator = new ServiceLocator();ISomeInterface instance = locator....
Locatable是一个Swift微框架,它利用Property Wrappers通过自定义属性@Locatable实现Service Locator模式
用Java实现23种设计模式 1. 创建型模式 工厂模式(Factory Pattern) ... 服务定位器模式(Service Locator Pattern) 传输对象模式(Transfer Object Pattern) 生产者消费者模式(Producer Consumer Pattern)
感谢菜鸟教程为我们大家做出的无私奉献。结合菜鸟教程实例,和Java设计模式(国外)...对设计模式进行自我学习。提供自我见解,源码文件。 希望有不好的地方多加理性批评,以便及时改正。
创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式,而不是使用 new 运算符直接实例化对象。...服务定位器模式(Service Locator Pattern) 传输对象模式(Transfer Object Pattern)
该文件解释了IServiceLocator实现必须正确实现以符合此接口的预期语义,以及一些实现注意事项。 规格 GetInstance(Type, string) 这是从容器中检索单个实例的核心方法。 此方法不得返回null。...
服务定位器 服务定位器违反了封装,隐藏了正确使用的前提条件。 是一种反模式。 是一种模式,允许我们开发松耦合代码。 结果 Get cached! services.Servicio1 Creating a new services.Servicio1 instance. Put ...
服务定位器.NET IoC 容器和服务定位器
ts-service-locator 服务定位器模式是一种防止组件与其依赖的服务之间的硬性依赖的模式。 有关更多信息,请参。 ts-service-locator是使用服务定位器模式的解决方案,具有类型安全性。 使用它来注册全局使用的服务并...
这是关于服务定位器模式的初学者教程。虽然服务定位器模式目前非常不受欢迎,并且被依赖注入容器的使用推到了一边,但看看它提供了什么以及为什么它现在被认为不足仍然很有趣。
参考Yii2实现的以依赖注入为基础的服务定位器,Yii2代码部分为vendor / yiisoft / yii2 / di /依赖注入DI依赖注入知道怎么初始化对象,只需配置构造参数就可以,核心代码如下(简化,只是说思路) class Di { //经过...
Locator-Yui 是 YUI 文件定位器插件。它可以与 Locator 组件(from Yahoo! to shift YUI' modules)集成使用,生成 YUI Loader 元数据。已编译的模块则可以通过 express-yui在服务器和客户端中使用。 标签:...
8.1.2 Service Locator 8.1.3 IoC容器 8.1.4 StructureMap 8.2 Model-View-Presenter 8.3 Front Controller 8.3.1 Command模式 8.3.2 Chain of Responsibility模式 8.4 Model-View-Controller 8.4.1 ...