J2EE Web架构与CS架构命名上的差异

发布时间:2017-03-28 00:00:00 编辑:小静 手机版

  J2EE平台由一整套服务(Services)、应用程序接口(APIs)和协议构成。下面是小编整理的关于J2EE Web架构与CS架构命名上的差异,欢迎大家参考!

  J2EE Web架构与CS架构命名上的差异

  与传统的CS(客户端与服务器端)架构相比,J2EE Web程序服务器提供了很多额外的技术支持。而且这些技术是一般Web应用程序都需要用到的,但是Web程序开发人员不需要再另行开发,只需要直接拿过来使用即可。具体的来说,在Web应用中主要通过调用现成的API来完成这个功能。而且使用这些技术时,基本上没有什么技术含量。因为在具体工作中使用这些技术都是采用基本固定的格式。命名技术就是其中一个典型的代表。在这篇文章中,笔者根据自己的经验,谈谈这方面使用过程中的注意点。

  一、 与传统架构之间的区别。

  在使用这个技术之前,笔者认为开发人员至少需要知道,在Web架构与CS架构之间的区别。只有如此,才能够更加全面的了解采用新技术所能够带来的优势。故笔者一开始就着重强调两者之间的差异。

  在应用程序开发中,如果一个类A需要调用另外一个类B,则类A需要知道类B的源程序,然后在其中新建一个类B的实例,才能够实现调用。而且当一个程序改变时,还需要重新编译。从这可以看出,类与类之间的连接需要通过实例来完成,他们之间的连接就比较混乱。

  而采用J2EE命名服务则不需要这么麻烦。简单的说,JE22命名服务器提供了应用构件程序的命名环境。如果采用了这种技术的话,那么实现类调用时,就可以不通过实例来完成。做一个形象的比喻,命名服务就好像是一个地址簿。当开发人员在程序开发时采用了新的构件或者新建了某个类,那么相关的信息就会都在这个地址簿中登记。作为开发人员的话,就不需要再去查找原始的类,只需要在这个地址簿中查找即可。显然这方面了我们日常的开发工作,可以缩短开发的周期,同时简化类之间的引用。最重要的是,如果以后被引用的类有变化时,不需要编译整个应用程序,而只需要重编译有变化的类即可。

  二、 命名服务的核心环节解析。

  J2EE命名服务提供各种应用构件程序的统一命名环境。其英文简称是JNDI。从这个英文名字中可以看到,这个命名服务包括两层含义:命名和目录接口。我们在了解这个技术的时候,如果从这两个角度去理解,可能会更加简单一点。JNDI简化了高级Web程序类之间的查找调用。

  从技术上来说,JNDI主要是通过API来实现的。JNDI API提供了Web构件进行标准目录操作的方法。举一个简单的例子,可以将对象属性和Java对象联系在一起,或者通过对象属性来查找Java对象。当我们在电话簿中查找某个电话的时候,会现在索引中找到某个人的名字。然后再从这个索引中打开对应的记录,查找这个人的电话、住址等联系信息。JNDI核心的工作思路就是如此。在上面笔者谈到过,这些技术都是采用基本固定的调用格式。也就是说,JNDI已经被标准化。为此应用程序可以通过使用JNDI来访问其他通用的命名服务。如支持常用的We命名协议、DNS等命名架构。笔者认为这点非常的重要。因为其支持多种命名结构,则可以与其他平台的应用系统,如C++等进行很好的系统的整合。

  三、 使用命名服务的注意事项。

  JNDI命名服务支持多种命名结构,如Web命名协议、DNS命名架构等等。那么到底该采用什么样的命名结构呢?这里面还是有比较大的学问。因为在以后系统维护中,可能要与其它应用程序进行整合。此时如果整合的系统采用相同或者类似的命名架购,那么以后整合的工作就会相对简单许多。一般来说,一家公司开发的产品,其采用的都是统一的命名架购。不管开发人员喜欢使用什么样的命名结构,公司都会要求其在后续的开发时采用公司规定命名架购,这也主要是为了方便后续与自己公司产品的集成。现在主要的问题是,如果公司接受的是客户委托授权的开发,同时又有与其他软件集成的内容在里面。那么对于这个命名架购可能需要特别的考虑。如要分析一下,企业现有软件所采用的命名架构。然后根据其采用的形式,来确定自己最终需要采用的命名结构。一般来说,在一个应用软件或者一个项目中,最好采用同一种命名架购,如采用的都是Web命名协议等等。这就好像在不同版本的电话簿中,采用的是同一个目录格式。这就会在很大程度上方便用户的查询。

  其次需要注意的是,虽然JNDI命名服务采用都是基本固定的格式,即已经采用了标准化的手段。但是从实际工作来看,开发人员往往需要结合实际情况,做出适当的调整。如需要考虑,命名的合理性。包括可读性、命名的长度等问题。虽然在具体的命名规则上,没有很严格的限制。但是如果设计合理、细节考虑周到,那么在很大程度上可以减少后续维护的压力。如在一个项目团队开发中,命名的规则需要经过项目成员的讨论通过,然后再进行强化培训。这对于后续项目成员按规则办事会有很大的帮助。再如,现在不少应用软件都是按模块来开发的。此时在命名规则设计时,也需要考虑到模块的分类。简单的说,一个模块一个目录。不要将不同模块的类存放在一起。这有利于后续应用软件的升级、二次开发等等作业。总之,虽然命名服务的使用比较简单,但是具体在设计时,还是有一定的难度。需要项目管理人员具有比较丰富的经验。一个合理的命名规则,对于应用程序的开发很有帮助。

  最后笔者需要强调的是,应用服务器定义的对象与用户自己定义的对象的区别。为了保障应用程序的正常运行,应用服务器往往会自动定义一些对象,如控制对象等等。而程序开发人员也会根据需要自定义相关的对象。这两种不同的对象对于JNDI命名服务来说,有什么区别呢?这里需要注意的是,JNDI在后台其采用的是多目录的形式,如其最上一层的目录是Java:Comp/env。后续的各种对象(包括应用服务器创建的和开发人员自己创建的),都放在这个目录下面。不过这里需要注意的是,两种不同形式创建的对象其所存放的目录是不同的。应用服务器创建的对象一般是存放在顶级目录中,一般目录的位置不能够改变。相反,用户自定义的对象,则可以分别根据所建立对象的特点来分门别类的建立目录。最常见的还是根据构件的类别和源代码所处的模块来建立目录。这方便了用户的查找。例如Ejb对象可以放在env/ejb目录中。然后在这个目录下面,再根据应用系统的模块创建几个子目录,来进行分门别类的管理。

  总之,JNDI命名服务采用了标准化与固定格式的手段,降低了技术门槛。与传统的开发架购相比,简化了类之间连接的管理,不需要通过很多的源代码就可以实现类之间的调用。不过如果要使用好这个技术,也有不少的难度。笔者这里讲的难度,不是指技术上的。而是指经验上的。如如果选择合适的命名架构、设计合理的命名规则等等,这些都需要开发人员具有一定的项目背景。否则的话,很难做出正确的判断。

本文已影响861
+1
0