ATMI的编程问题 - Tuxedo (Chinese)

我想问一ATMI编程可以用c++来做吗? 

of course! 

可我看到文档上只有C的开发文档,也就是我在Tuxedo写Server端ATMI开发只有
C,Cobol,FML。这是为何? 

安装一个TUXEDO客户端,调用tuxedo的动态库.
当然,够悍的话,不安装也行. 

什么意思?我现在开发Server端的应用的话,用ATMI接口编程,它能编译C++程序吗?能说的详细些吗? 

据BEA工程师说,可以,用标准 C++。 

使用用标准 C++是可以的。大家很多都使用vc++ or bc++等编译程序 

在TUXEDO中是可以使用C++的,因为用C/C++关键是你的编译器,而不是TUXEDO,
在编程方面,TUXEDO只是提供了函数库和一些数据结构而已。
另外用C++要小心TUXEDO中间的tpreturn函数采用了longjmp的远程goto方式,
所以导致在tpreturn之前申明的栈上的对象无法自动析构,存在memory leak
的危险!!! 

C++中“函数”称为方法,那在编译时也得以Service的方式发布出来才行,对吗? 

谢谢各位的回答!不好意思我是初学Tuxedo和C++,问的问题比较傻.
我还有疑问,就是在ATMI进行Server端开发时,一般情况下是用buildServer来编译程序呢?还是自己来编译程序,那种好呢?如果用buildServer来编译的话,在Linux上我怎么让它找到C++的编译器呢? 

编译器是由环境变量来设置的,看看tuxedo的文档中关于环境变量设置
的部分,另外,如果是c++的初学者,建议不要用c++开发,c++的陷阱
比较多,搞不好就会coredump和memory leak 

同意pingcy的说法,尽量不要使用C++,还是使用标准C。 

支持c++ 毕竟c封装太简单了。而且不利于重复利用。在linux上tuxedo支持
gcc

Related

我对几本经典模式书籍的评价

GOF的<设计模式>自是鼻祖,无用多说.记得拿到该书后,大有相见很晚之感,连续看了三遍,感到自己对OO的理解上了一个台阶.
Martin Fowler的<分析模式>与其所写的<企业应用架构模式>相比,多少有点垃圾.许多时候用了极大篇幅描写的模式,只是很简单的东西,一个类图就可以足够清楚,而且参考意义并不是很大.如果作为睡前消遣阅读的书,也是不错,但真正的收获并不会太大.另外一本书<企业应用架构模式>值得一看,尽管许多模式在实际开发中已经使用过,但看到在理论的高度有相同模式,也会让你欣喜不已.特别是起基于java和C#的例子,相信大家都倍感亲切.
还有<pattern-oriented software architecture>也值得一看,尽管书中对许多模式的叙述喋喋不休,显得有点多余,所介绍的各种模式确实能够减少你在架构搭建和设计时为许多问题所考虑的时间.
是你写的吗?
如果排版都不正确,很是怀疑。
我看的大多是英文版的,所以很大程度上收到英语水平的限制。
《分析模式》看起来比较累,因为里面的例子太生活了
《企业应用架构模式》看起来还好,感觉自己已经会了不少,很兴奋
最过瘾的是《软件配置模式》,书简单而且感觉学到了知识,而且感觉许多配置管理方面的书都太浮华了,脱离实际严重
《J2EE核心模式》,先看了中文的,翻译比较差,所以看英文的,但怎么看的都忘了,准备重新看
《实用J2EE设计模式编程指南》这本书也不错,看的中文的,感觉像实战指南
我看的书太少了,还有很多没看过,应该好好补一下了
感觉《J2EE核心模式》英文版还不错了
jiajianping ,你写的就该把它分好段,要不我会以为是直接从某各地方拷贝过来的
设计模式,企业应用架构模式,分析模式
影响力一本不如一本,为什么呢?也许真的是水平一本不如一本。也许还有其他原因
其实出现这种局面一点都不奇怪,从内容上看
三本书越来越远离编码本身
从感兴趣的人数上来看
程序员>架构师>业务建模师
群众基础加上选择性思维使得三本书的受关注程度大不相同
我一向觉得,如果思维层次达不到,学模式也是白学
让一个在jsp里直接操作db操作得不亦乐乎的人去看设计模式,他只能觉得?嗦
任何一本模式书,都是对实践的一种总结,看的人一定至少在某种程度上
感到心有戚戚焉才能理解模式的语境
因此,对于从来都没有自发的创造出任何一种创建型模式(最简单的模式)的开发者,
我觉得根本就没必要去学设计模式了
很有意思,我当初看设计模式的时候完全没觉得有什么畅快淋漓的感觉
不过是很多面向对象设计原则+对OOP语言的折衷而已,换句话说是匠气十足
而且过于追求理想化的context,说实话真没有阎宏写的<java与模式>实用,
偏偏很多初学模式的人都奔着这本经典而去,由于缺乏实践的支撑
很难体会到模式实际上经常(如果不是总是)组合使用的,而且不总是那么纯粹
反而容易误入为模式而模式的陷阱
强烈推荐想学模式的人先看<敏捷软件开发>
企业应用架构模式,我到看得大呼过瘾,觉得是远没有获得其应有的地位,
也许和我面向的恰恰是企业应用有关
至于分析模式,我看了几眼就不看了,因为我根本没在那本书的语境下实践过
根本就不可能体会作者的意图。那本书是给业务建模人员看的,根本不是给
做OOAD的人看的。面向的完全是两个不同的方向,以系统建模的眼光去看待
业务建模的思维完全是外行评价内行,虽然两者可能有那么一点点联系。
书经典,评价也很中肯
楼主和斑竹合作给了大家一个好的建议
不想多说,只想举一个例子.
不管这本书是好是坏,我要想批评它,我就会先看它.
看到<<JAVA 与模式>>的作者那种推销劲我已经深恶痛绝,简单象苍蝇一样.
但为了能正确在评价我还是花了几个晚上的时间认认真真地读了一遍.
于是,我有了发言权.
其中<<里氏代换原则>>用了7张14页,说了N多屁话,只是一句话,连我家阿黄(一只老得快要不行的狗)都知道的一句话:父类能出现的地方子类也一定能出现.
我想凡学过一周以上时间的JAVA程序员没有人不知道父类能出现的地方子类也一定能出现这句话吧,而如果你已经知道这句话懂不懂它的一个好听和名字叫"里氏代换"有什么关系呢?
这就是现在介绍模式的书.
象我这种没有任何开发任务纯以研究为目的的读者浪费了些时间倒无所谓,但那些以时间拿工资的软件开发人员上当受骗后,这种作者杀人不见血,而且一杀一大片.在封建社会是可以灭九族的.
原来是这样,这本书很多人都有自己的评价。
作者说自己写了一年,稿费才几万块,而年薪好几百万,当时也感觉此人太牛,既然axman这么说,就不去看了
JAVA 与模式
没看过.这里有前辈给指点了.好.
不买了.
有人的评价很不负责的.
的确,<java与模式>里废话太多
但是我还是认为,对于经验甚浅的人来说,看这本书要比看<设计模式>强得多
虽然我更加推荐<敏捷软件开发>,但有些人就是喜欢“模式”这个大名词
如果一个人把<设计模式>都看得懂7788了,当然会觉得<java与模式>不够简洁
但问题在于<设计模式>写得有点过于简洁,象学术论文多过普及读物
所以是不适合初学者看的,其实,<java与模式>也不太适合初学者
但仍然好过<设计模式>。
而且里面讲了一些基本的oo原则,单只为了这几个原则,也值得一看
很不幸,LSP在我所鼓吹的<敏捷软件开发>里也用了差不多14页
而且两者的例子也差不多,但明显<敏捷>的行文更加紧凑
知道这个原则很简单,但是不用错则很不容易,14页很值得
看了这些老师的讨论.比看书都爽.以后多这样.
<<j2ee设计模式>>不错.还有gof的<<设计模式>>
对于<Java和模式>,不好做评价,但看过其目录和内容介绍.有点狐假虎威,扯虎皮做大旗的感觉.还是看点经典的好.

没有整理前的架构设计文档。

这个文档是RUP的文档修改版。我们的文档基本上是在这之上修改来的。
我看了wonder提出的意见,的确我再回过来看看,的确感觉原始文档要比我上次提供的文档模板在整个结构要还要清晰一些。
同时希望wonder版主对这个文档修改一下,这样呢让大家更能对架构设计更好的理解。
因为最近比较忙,先提一个小建议。从这个文档中没有看到逻辑视图,既你的架构是如何分层的呢?
提几个自己的看法:
1.文档简介中应该包括定义、缩略语、词汇表部分。
2.非功能需求不应放到引言中,因为这部分的内容实在是太重要了,单独提出一个章节。而且有的观点说要分开运行期质量、开发期质量和约束等,我觉得不用分的这么详细,只要能说清楚就可以了。
3.概念框架,从解释中看是指词典,不知道这里的概念框架和概念架构有什么区别,是想描述概念架构吗?
4.系统架构看描述很类似于概念性架构,但是概念性架构应该是不需要描述接口细节的。
5.其他视图最好能单独列出来,什么东西一叫其他,往往就会被忽略,“描述过程、开发、物理视图,说明逻辑部件是如何映射到其他视图上的”这句感觉不太严谨,视图之间是从不同的角度来看架构,应该不是映射关系。
先写这么多,欢迎继续讨论。 :)
说影射呢是说得我们是如何在进行架构设计工作的。也就是能够从一个角度看待透彻了后,那么能够从另外一个角度来看清问题的另一面,但是所看到的东西绝对还是这个事物,而绝对不会说我们看见的是另外一个东西,所以几者之间必然要统一。
也就是架构设计的先后顺序,是有一个先后顺序地, 后面的每一步都是一个不断的深化与转化过程。就拿设计与需求来说,角度不一样 但是描述最终的基础实质---所解决的问题是一样的。 所以这里我使用了影射,我认为就是如过你的每一个步骤都能够和前面的工作接轨,而且都有一套方法论,那么工作不就是完全自动化了吗?现在很多项目我发觉都是事件在驱动。
虽然说rup中,整个过程是迭代进行的,那是指整个过程是迭代的,而不是说过程中的每一个环节都是迭代,也就是说,并不是说需求根本没有做就可以做设计。
嗯,整个思路应该是大致相同的,可能理解和表达不一样。我看来得好好的消化一下。
套得象 不象,先往上套 再说,嘿嘿
可以借鉴一下

请教高手:如何下手将Powerbuilder C/S二层模式,用Tuxedo改造成三层,

现在手上有个用pb开发的C/S二层的系统,因为系统通讯问题,网络不稳定,需要将其改造成三层,不知道如何下手将Powerbuilder C/S二层模式,用Tuxedo改造成三层,虽然知道一些关于Tuxedo的使用,但是将一个大的系统进行全面改造,却没有经验,需要高手指点,其中涉及到哪些方面的,原来的系统那些地方需要改造,怎么改造,能否提供一个范本,不胜感谢!chengandgang#163.com
似乎除了主机和数据库其它的都要改
原来的数据库设计和代码可以有许多的借鉴,但是代码几乎都得重新写了。
这样的话,属于软件架构的变化。感觉这样:powerbuilder的datawindow的好处就很难使用上了,前端还需要使用pb吗???是不是使用别的更美观,更实用?
看样子是个大工程了,因为设计的思想变了.
将Tuxede客户端函数封装成标准windows dll,在PB中加载调用(同样适用于VB,Delphi等非C/C++语言的开发工具);
数据库联接、事物控制等原来在PB中直接访问数据库的操作通过在Tuxedo端配置和编成实现;
划分 业务模块,功能模块儿 在Tuxedo端编程实现,如果原来PB划分的好,剩下的工作就是移植;
PB前台负责展示、业务流程处理,通过控件封装,使DataWindow等PB原有优势继续保留,具体数据库访问、控制 以及业务逻辑处理在Tuxedo中间层实现,但是对于事物处理Tuxedo ubb中支持的是XA事物,如果多数是本地事物,还是通过编程进行控制。
楼主所说的这种情况下要做的变动比较大,工作量可能不会次于一个新的系统。建议还是先找出来原系统不稳定的地方,实在不行再考虑移植部分功能到Tuxedo,可以将业务逻辑封装到procedure中,直接在Tuxedo中写大量的业务逻辑还是挺有难度的。
封装成DLL是一个很好的方法
very simple
楼主的意思是不是pb作个客户端而已,把业务操作和数据库的操作都封装到tuxedo服务端吧,这个代码基本要重新写一遍。
很久以前我们写过一个ODBC for tuxedo,你们也可以试一下这个方法。
将数据窗口和tuxedo的fml域进行映射,可以构建自己的前端开发平台,前端人员可以不需要了解Tuxedo,直接操作datawindow就可以了。。我们目前有一套基本稳定的开发框架,就是按这种方式来构建的。
你的系统的所有核心算法是可以共用的,但需要用c,pro*c或pl/sql在后台进行重写,而最核心的数据库表是可以完全复用的。
你可以将原有系统的界面输入、输出项作为前后台的接口报文,实现前后系统的接口。
一般情况下一个100多个功能点的系统(每个功能点平均包括增,删,改,查四个基本功能),从设计到改造15个人2个月基本可以完成。
如果业务逻辑在数据库服务中用存储过程多一些的移植,移植会快一些。

[原创] “Step by Step教你用CruiseControl”

看到有位老兄原创了一篇cruisecontrol的文章,我也来凑个热闹,把前些时间写的关于CC的入门文档现个丑 :)
好文章啊!我对持续集成也很感兴趣,能不能多介绍一下经验呢?
原意和linclick一同学习。有问题不妨在这里讨论:)
为什么我总是无法下载呢?
下载到304 KB的时候出现问题
显示完成,但是无法打开
用下载工具也不行,郁闷
原创辛苦了
不错的教程。写的很详细!

关于queue编程

我想在服务器程序中用queue来传递服务器之间的控制消息。
例如: 服务1->queue1->服务2->queue2->服务3->queue3->....
应如何编程和配置? queue是否需要配置成reply 方式 
你先试试配置tuxedo自带的例子qsample,这样你对queue就有一些了解了。 
tuxedo自带qsample我已经调试通了,并且在上面另加了个服务,但设置成reply方式时,第二个服务始终不能从和他名称相同的队列中dequeue消息,为什么? 
你说的reply方式是指什么?是说用什么函数?对queue的message进入queue和退出queue只能用tpenqueue和tpdequeue函数。你能具体说说你的意思吗? 
在客户端enqueue前设置控制结构的一项为REPLY,这只是个大概意思,具体结构和参数记不清了。这样,第一个服务处理完成后写入应答队列。应答队列名和服务2的名称相同,他能不能自动dequeue应答队列内的消息?为什么第一个服务就可以自动dequeue入口队列中的消息?除了第二个服务和ubbconfig中加入一个TMQUEUE和在TMQFORWARD中CLOPT中的-q 选项后加入",queue2"外,没有做任何改动。对了,在原qsample例子ubbconfig中,SERVERS段中,server的SVRID和TMQUEUE的相同,是不是我新加服务后,也得加一个SVRID相同的TMQUEUE? 
我理解的queue和函数之间的调用是这样的:
client<-->TMQUEUE<-->queue<-->TMQFORWARD<-->server
client和TMQUEUE之间用tpenqueue函数,而TMQFORWARD和server之间用tpdequeue函数。TMQUEUE是tuxedo自己提供的将message加入queue的server。而TMQFORWARD是tuxedo自己提供的自动查询queue并将message读取到server端的server。每一个queue space对应一对TMQUEUE和TMQFORWARD。
我现在试了可以用client->queue space1->server 1->queue space2->server 2,但是必须试queue space1和queue space2在一个文件里面,如d:\tux\QUE中。其他情况我还没有成功。
此文被damask在2002/11/06 11:22:22修改! 
这样说来我不需要在enqueue前设置RAPLY方式,自己做enqueue和dequeue.服务器之间的队列操作也这样? 
我想用类型操作系统队列的方式按msgid取消息,设置flags=TPQGETBYMSGID,总是报-1。如果是TPQWAIT就没问题。但是如果不按msgid,又怎么能保证客户端取到的是自己要的消息呢? 我怀疑tuxedo的队列有bug。有高手解答一下吗?
tpdequeue()返回-1应该是由于取消息的时候queue中没有想要的MSGID的消息造成的,用TPQWAIT标志是阻塞在queue上,直到期望的MSGID消息就绪时才返回。

Categories

Resources