也来说说网上订票系统

JavaEye网站 — Tue, 14 Oct 2008 12:54:47 +0800

作者: jiyanliang 链接：http://www.javaeye.com/topic/252623 发表时间: 2008年10月14日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

   我们知道，对于一般的网上订票系统，比如电影票定购、足球票定购，都有一个漂亮的座位选择界面，我们点取其中的几个座位后就可以去结账了。
   但是这里面就会有一定的问题，那就是对于资源的访问问题。下面来说说这种情况。
   如果A用户首先登录这个系统，假如这个时候还没有座位被定掉，A用户可以自由选择座位号，A点了几个座位后，这个时候B用户来了，点了一个座位后在A用户之前去结账了。这个时候如果B用户的座位号和A的座位号有重叠怎么办呢。
   我的想法：每个用户在点击一个座位号后都发送到后台数据库，后台程序自动更新前台页面，但是好像这个方法实现起来有难度，因为数据的传输本身就有延时。
   大家说说自己的看法的。我也是无意中想到这个问题。

已有 2 人发表回复，猛击->>这里<<-参与讨论

JavaEye推荐

从EOS5到EOS6：从Basic到Java

JavaEye网站 — Thu, 16 Oct 2008 09:03:24 +0800

作者: jxb8901 链接：http://www.javaeye.com/topic/253412 发表时间: 2008年10月16日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

据说EOS6将最近正式发布。虽然之前也听说过EOS6将有一些重大变化，但毕竟听到的只是只言片语，加上官方网站上对EOS6的介绍也是少之又少，所以一直想象不到EOS6的变化究竟有多“大”。

今天拿到了EOS6的文档及安装程序，花了一个下午的时间安装、阅读开发手册、试用，感觉仍是不得要领。XML总线没有了、页面逻辑没有了、业务逻辑没有了。页面流、逻辑流、服务、接口、构件装配、引用等等新概念让人无所适从。虽然还是有熟悉的EOS开发视图、EOS调试视图，但很明显：EOS6已远非我们所熟悉的那个EOS5了。嘿嘿，一句话：从EOS5到EOS6，那变化是相当的大。

又花了一个晚上的时间翻看了EOS studio附带的开发文档和参考手册，终于对EOS6的变化和发展有所理解和领悟，特地记录下来，希望能帮助后来者减少学习的成本。

从EOS5到EOS6的变化，可以类比为从Basic到Java的变化。从Basic到Java，就是从面向过程到面向对象，这是Basic和Java最大的也是最本质的差异，同样这也是EOS5和EOS6最大的也是最本质的差异。

1、在EOS5中，业务逻辑甚至是页面逻辑都可以认为是Basic中的一个函数或过程，而在EOS6中业务逻辑被“构件”和“逻辑流”两个概念代替了，EOS6中的一个“构件”可以有多个“逻辑流”。为什么要把EOS5中的一个概念拆分为EOS6中的两个概念呢？因为EOS6面向对象了。在EOS6中，一个“构件”可以被认为是一个Java类，而“构件”中的“逻辑流”就相当于Java类中的一个方法。甚至于为了更加的面向对象化，EOS6中的参数都可以是任意的Java对象，而在之前的EOS5中，这是不可能的，因为XML总线中只能存在有字符串。

2、在EOS5中，运算逻辑只能是静态方法，而且所有运算逻辑的方法签名都是固定一致的，必须接受一个XML总线作为参数，因此我们也可以在认为EOS5中没有过程或函数的形参和实参的封装，而只有全局变量。但在EOS6中，这一切统统被改变了，因为EOS6需要面向对象化。在EOS6中，运算逻辑可以是任何Java类的任何方法，甚至是非静态方法！对于习惯了过程式编程的程序员来讲，这一点可能是不可接受的，他们认为静态方法已够好的，他们无法理解为什么需要非静态方法（实例方法）。事实上EOS6这样做了，我想EOS6的设计者们有他的理由和想法。

3、 EOS5太简单了，从语言层面来看，没有太多可说的东西。但EOS6就不一样了，为了实现面向对象化，EOS6甚至引入了面向对象语言的核心概念：接口。虽然有人不同意，但以现今的程序开发眼光来看，“接口”这一概念的重要性要比面向对象中的“继承”概念的重要性大得多。EOS6恰恰实现了面向对象的“接口”概念而没有实现“继承”，我认为这一点不会影响EOS6进入面向对象语言殿堂的可能性。

4、 EOS6不仅仅是Java1.3或Java1.4，EOS6是Java5。因为EOS6实现了Java5中的变长参数，另外EOS6的运算逻辑全部支持Java5的Annotation（注解），EOS6的Java API也都支持范型，EOS6的IDE和服务器都运行于JDK 5。

5、 EOS6中的构件支持依赖注入（DI），EOS6 Server相当于一个IOC容器。近年非常火爆而今年风头稍减的名词——IOC，所表达的设计理念也被EOS6所采用了。只是换了一个说法，一个近年风头更劲的名词——SOA。要说EOS5支持SOA，了解的人都是相视一笑，大家都不说穿罢了。而EOS6那才是货真价实的SOA架构，据说EOS6实现了SCA/SDO规范。SCA中的构件装配就类似于IOC容器中的组件装配，构件只需声明依赖，其依赖关系可以由容器自动解决，类似于IOC中的依赖注入。事实上通过部分EOS6的代码可以看到，EOS6中使用了Spring2，可以想象EOS6的IOC应该有Spring的影子。

6、 EOS5简单，EOS6复杂。EOS5之所以简单，是因为其提供的功能弱，概念少，就如同Basic的简单是一样的道理。但EOS6就不同了，仅是新概念就增加了不少，如：接口、引用、实现、服务、构件、逻辑流等等；另外EOS6还引入了SCA/SDO的概念，什么DataObject，DataGraph，MUO等等。这些无疑会增加EOS6的入门难度和学习难度。

7、 EOS5中的XML总线被EOS6中的数据上下文的概念所取代。曾经，XML总线可是EOS引以为豪的骄傲。如今，新的SOA/SCA/SDO风头正劲，XML总线自然也要完成其历史使命退隐江湖了。其实EOS5的XML总线理念相当简单，就是一个树状结构的字符串类型的全局变量池。但为了支持面向对象，EOS6也只能忍痛割爱另寻新欢了。EOS6中的数据上下文其实和XML总线类似，但支持任意的Java类型。事实上就相当于一个基于线程局部存储的变量池，或者简单来说就是一个Map。但就是这样一个从字符串类型到任意类型的看似简单的改变，将深刻影响EOS6开发的各个方面。

8、据EOS的文档讲，EOS6支持AOP，虽然我还未了解到EOS6是如何实现的AOP，又实现到了什么程度，但我想面向对象的EOS6实现AOP应该不难。

8、EOS6与EOS5完全不兼容。虽然没有看到EOS关于升级和迁移的文档，但通过对比分析我们可以得出如下结论：原有的基于EOS5的业务逻辑是无法迁移到EOS6中的，也就是说所有的业务逻辑必须重新开发，这对于基于EOS5做了大量应用的公司来讲不是一个好消息。

至此，我们似乎隐约看到了EOS的发展肪络。曾经，EOS5被我们许多人所赞叹甚至为之而自豪，而今天，EOS6对EOS5的一些东西的抛弃，是否应该引起他们的思考呢？从面向过程到面向对象，从简单到灵活，从容易到复杂，这好象也是当今软件的发展之道。看到EOS这样的变化，也许我们应该欣喜，毕竟他在进步。

从EOS5.3到EOS6似乎用了近三年的时间，也就是说EOS花了三年时间实现了其本质上的变迁。但中国整体的IT水平能跟上这样的变迁吗？如果不能，那么我们可以预言，EOS6在推广上将远不及EOS5。

注：因为这篇文章仅仅是在接触了EOS6几个小时后所写，文章中对EOS6的理解难免会有错误，欢迎大家补充、讨论、批评和指正！

已有 0 人发表回复，猛击->>这里<<-参与讨论

JavaEye推荐

msnsdk文件

JavaEye网站 — Mon, 13 Oct 2008 10:43:00 +0800

作者: lukeshei 链接：http://www.javaeye.com/topic/252036 发表时间: 2008年10月13日
声明：本文系JavaEye网站发布的原创文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

msnSDK 文件

msnSDK(http://tcmail.program.com.tw/image/msnSDKV1_0_1.pdf)主要的功能就是把一些常用的MSN 功能做成一些API,讓外部的程式可以簡單的應用它來開發相關應用程式,目前;msnSDK支援4種程式介面, 1.SOAP 2.CGI 3.ADO (這三種API的功能相同) 4.CGI-Steam 這個介面主要是處理從man client 到msnSDK 之間的訊息以及線上狀況的資訊傳遞,歡迎需要測試功能的人或是有應用需求的各行各業先進與我聯繫(sonet.all@gmail.com)

已有 0 人发表回复，猛击->>这里<<-参与讨论

JavaEye推荐

行业解决方案论坛最新讨论 - JavaEye

也来说说网上订票系统

从EOS5到EOS6：从Basic到Java

msnsdk文件

msnSDK 文件