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