@echo off
echo set sh=WScript.CreateObject("WScript.Shell") >telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------UNIX IPAddress
echo sh.SendKeys "open 10.0.18.100{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------userID
echo sh.SendKeys "root{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------password
echo sh.SendKeys "root{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs

echo sh.SendKeys "ls {ENTER}">>telnet_tmp.vbs

start telnet

cscript //nologo telnet_tmp.vbs

rem del telnet_tmp.vbs

2)添加Blog帐户:

3)设置日志类型：

4)连接测试

但在WS化时，由于日久生疏，一个小小的WS化变动，却花了整整好几天时间！为此，狠下以来，将其过程进行记录，以便下次参考。

WS整体流程：

以下分别介绍：

1、设计和实现WebService服务端功能组件，用于统一处理针对本应用系统所需进行WebService化的逻辑实现。并将系统逻辑处理中的对象转成序列化后的String对象，以符合WebService交互标准。

2、根据SBPApi.java，生成WSDL等：通过Eclipse右键菜单中的WebService-->Create Web Service项。完成后，会在web目录下建立wsdl目录和SBPApi.wsdl，在WEB-INF目录下建立（改写）server-config.wsdd等文件,并完成对web.xml的修改。其操作流程示如下：

3、根据SBPApi.wsdl，生成WebService客户端开发包和部署文件：

1)为不影响已有项目，可另建java Web项目；

2）将wsdl目录复制至新项目对应的web目录下；

3）通过eclipse已提供的webService插件（右键）功能，生成客户端开发包所各文件。此时，所生成的文件与服务端对象文件结构一至。

4）调整关联引用文件，将其调整至客户端开发包，从而避免与服务器端的引用路径重复而引发不便，并将服务器SDK中已有文件删除。

5）建立客户端的快速使用代理SBPClient.java，对WebService服务端交互工作的SBPApiSoapBindingStub.java进行客户端封装，并根据服务端中交互对象进行反向工程，其示例结构如下：

6）将clientApi下的所有文件打包后，加入测试项目进行测试。此时，因客户端所使用的服务端对象未包含在WebService客户端开发包中，因此需要将服务端对象也一同打包。

7）测试。

4、开发环境：Eclipse3.3.1.1 + JDK1.5.06 + Apache Axis version: 1.4

Java中，多线程编程中的线程编写，有两种方式，即扩展Thread基类或继承Runnable接口；例如：

public class T extends Thread {

public void run() {

……

}

}

public class R implements Runnable {

public void run() {

……

}

}

对于扩展Thread的实现类T，可以使用T.start()来启动此线程；如

public static void main(String[] args) {

Thread t = new T();

t.start();

}

但对于继承Runnable接口的实现类R，因接口中并没有提供直接启动线程的start()方法，只有一个线程主逻辑运行的run()方法。此时，如执行run()，会因为R.run()只是作为此线程实现类的一个方法，并未在主线程之外，启动另一个线程，从而导致R.run()阻断主线程继续向下执行；并未达到多线程运行的目的。

错误启动代码如下：

public static void main(String[] args) {

R r = new R();

r.run();

}

那么，如何使用另外线程来启动继承Runnable接口的实现类呢？以下就是它的正确的使用方式：

public static void main(String[] args) {

R r = new R();

Thread t = new Thread(r);

t.start();

}

此时，需注意，在主线程执行时，需等待子线程执行，否则，当主线程结束后，子线程也将结束。

系统A与系统B分别部署在不同域的两台服务器中，但它们的身份都统一在身份认证服务器中；身份认证信息以Session方式存贮于各自系统中，并辅以cookie进行使用。

当用户在A系统登录后，访问B系统时，由于是跨域访问，导致身份信息不能正确的传递到B系统中，从而致使用户需在B系统中重新登录。

解决方案：

处理这类跨域访问时，我们最先使用从B系统向C通过HttpRequest(类AJAX请求)的方式获取身份信息，此方式好处是同步处理，方便用使用；但其限制诸多，如需设置信任站点、用户访问确认等，甚至，在对应用服务器作了一次安全升级后，根本无法访问了。因此，需另行开辟途径，于是，在同事建议下，我们使用IFrame内嵌跨域验证网页，来解决此问题。

1、原理设计：用户在访问B系统时，先使用一内置的iframe，并将iframe的src指向身份认证服务器系统代理验证接口；如果用户已经在A系统中进行过登录，即A域了中已存在着身份认证信息后，身份认证服务器中也将具有其身份信息将其附带着身份认证信息后重定向访问B系统代理接口；B系统代理验证接口在接收到由A系统传递而来的身份认证信息后，通过身份认证服务器验证后，在B系统所在域重建身份认证信息。

2、实现逻辑贴码：

1）B系统代理验证接口：

（1）IFrame逻辑贴码：

（2）JS检测是否通过认证逻辑贴码：

2）身份认证服务器端接口（JSP）：

3、注意事项：

1）由于身份认证中心使用cookie作为身份标识，因此，需要用户在浏览器中允许使用cookie的设置；

2）由于在iframe中进行跨域重定向，因此需在IE安全中的跨域浏览子框架项设为启用：

4、源码文件：

……

1、通过dos窗口，进入至jdk安装目录下的bin目录中；

2、运行jconsole.exe，并设置信息输出的目标文件，以便于分析，否则将直接输出至屏幕上；

3、连接正在运行的目标jvm；

4、连接后的jconsole如下：

5、通过通过Ctrl+Break组合键，产生javacore至指定文件中。

6、下一步就是对所产生的javacore文件进行具体的分析和使用了。

某日，公司进行年度一次的体检！

在连续查出10个脂肪肝后，医生对第11个进来检查的人说：“等会，我们的B超机好像出问题了，等检修后再进行”

这是一个真实的事件，我们这些IT行业的从业人员，多坐少动，压力大，时间长，导致体质差的边医生都怀疑机器了！

唉！

1、建立J2ME项目

2、在完成开发后，进入Application Descriptor编辑界面

3、因默认情况下，Application Descriptor文件中未定义MIDlet启动对象，因此需使用EditPlus或记事本等文本编辑器，编辑Application Descriptor文件（位于项目根目录下），并添加以下项目，如：

4、运行Application Descriptor编辑界面中的Lanuch as enumlated Java ME JAD，进行测试

5、在步骤4之后，会在项目根目录下的.mtj.tmp中生成LaunchFromJAD子目录，其中的worm.jad和worm.jar即是手机程序的安装文件

6、将worm.jad和worm.jar复制至手机中，运行worm.jad进行安装后，即可使用

二、问题分析：

1、如报【文件不完整】错误，则检查worm.jad中的项目是否完整。在Eclipse中使用Lanuch as enumlated Java ME JAD测试通过，并自动生成的此文件，一般都是完整的，不需作任何修改。

2、如报【版本错误】，则检查您在Eclipse中使用的的模拟器版本是否是您手机所支持的，出现此错误后，将模拟器版本调低试试。其位置如下

三、开发环境：

1、java JDK1.6.0_10；

2、EclipseV3.3.1.1；

3、sun公司J2ME-WTK开发包：sun_java_wireless_toolkit-2_5_2-ml-windows.exe

4、Eclipse移动应用开发包：eclipseme.feature_1.7.9_site.zip

消息中心产品简介

产品简介

在XXX产品框架中，我们根据产品发展规划和业务领域需要，使用基于JMS技术，通过应用WEBService，开发了消息中心中间件（简称MC）。通过消息中间件，我们可以实现各系统间的异步数据交换和事务处理、执行不需前台使用人员干预的如后台业务和数据同步工作，也可用来处理一些受到安全和其它一些因素制约，导致无法直接通过数据库或应用系统进行处理的受限业务。

消息中心中间件，包括消息总线和消息客户端两部分：消息客户端负责业务类消息实例的产生、发送消息实例到消息总线、接收从消息总线转发而来的消息实例、将收到的消息实例交由其载体应用系统进行与之对应的业务处理等活动；消息总线负责接收从消息客户端产生并发送而来的消息实例、消息重建、根据消息配置进行消息实例重建,将重建后的消息实例转发至对应的消息客户端等活动。

消息客户端与XXX各应用系统集成在一起，并通过应用系统开放WEBService端口进行消息的发送和接收等，从而避免单独部署和发布所带来的困难和额外资源消耗。消息总线可单独部署，也可和消息客户端一样，与XXX应用系统集成部署，在XXX产品框架下，有且只需要一套消息总线即可满足需要。消息配置中心，其作用包括配置和管理消息中心各组成部分的部署方式和访问信息，以此将消息中心各部有机的联系起来；同时，各消息业务应用，也使用配置文件进行配置化管理，并与消息中心各组成部分进行关联配置，从而形成一个统一且开放的整体；其它的如性能优化处理、日志记录等也在配置中心进行配置和管理。

应用现状

在消息中间件V1.0版本开发完成后，我们即将其投入实用。在XXX各分子系统这近一年时间的运行和使用过程中，消息中心很好的完成了预定任务，其可靠性、可扩展性和适用性得到很好的验证。以此为据，通过使用消息中心，开发出基于消息中心的客户化应用和业务活动也在持续的增加中，到现在为止，已经有包括网络检测、信息同步、配置更新、电子目录树更新、权限同步等诸多应用是基于消息中心应用开发，并很好的使用在XXX各分子系统的测试和内网正式环境中。

问题出现、描述、分析与处理记录

问题出现

在XXX系统正式接入外网后，通过对业务进行跟踪，发现外网用户（系统）所产生的消息实例无法正常的到达指定的消息总线及消息客户端。最主要的体现是权限同步消息应用无法正常完成的问题，导致外网用户权限未得到及时更新。对此过程中消息中心所涉及部分进行分析发现：所有的权限同步消息实例在产生后，不能正常的将此消息实例发送至消息总线，分析失败原因，只有一种，那就是”connect time out”。从此信息可看出，应该是外网系统所发出的消息无法通过WEBService送达指定的消息总线接收端所至。但从内网发出的同一类消息，其发送和接收却又都是正常的。

分析过程记录

1、先分析我们系统的整体部署方式，如下图所示：

根据外网用户可正常登录和访问系统，并可通过系统准确及时的发出执行指令操作，完成其所需的业务活动来看，网络方面和系统和硬件方面都不存在问题。

2、在外网环境下，直接进行各消息客户端和消息总线的服务的检测，所发请求都能够正确的到达指定目标，WEBService的响应也正常且正确，也就是说，各应用系统加载的消息服务运行也正常。

3、根据本次检测需要，另行开发消息中心专用检测工具，为本次和今后的行的消息中心检测和问题分析，作好更充分的准备。

4、通过检测工具，发现，外网环境下，消息客户端和消息总线之间不能够联通，从而找到问题所出：即不知是何原因，导致外网消息与外网的消息总线间联络不通！

5、对外网用户消息产生和发送的过程和逻辑实现进行分析：我们发现，为了满足应用系统外网访问的需要，我们对消息系统配置信息中服务地址的ServerName进行了伪处理，即在运行时，根据用户浏览器的请求头来判断用户使用的是哪一个WEB服务器地址，并将此地址动态的代替消息配置中的各ServerName信息，从而保证各使用用户只能够访问其指定的WEB服务器，从而避免因WEB服务器的不匹配而影响其访问速度、处理效率等故障的发生。此方式已在我部门多套同时服务于内外网络的系统中得到可靠的验证。

那么，会不会因为ServerName在动态解释过程中，因多并发情况下，因后访问者将前访问者的ServerName改写而导致错误的解释，即将不同网络用户的消息地址进行张冠李戴而导致消息无法正常发送呢？

分析消息中心各部分WEBService生成和使用机制：因系统的并发性要求较高，在高峰期其在线用户可达3000人，并发用户在300以上，且系统稳定性要求极高。为提高系统的性能和稳定性，在系统启动时即将消息中心各部的WEBService连接进行创建和缓存，以提升消息中心资源利用率，并提升其访问性能。

当存在多网络用户访问时，可能因消息中心存贮的WEBService连接并不是其用户所使用的那个网络的WEBService服务地址，此时，消息肯定是无法送达至此用户所需要的目标的。因此，报”connect time out”错误就成必然的了。

既然已找到问题的可能原因，我们立即进行着手分析和解决：根据部署要求，我们对对消息服务连接服务进行了升级，即将服务请求进行分类处理和实现，并在消息配置中对所使用的部署方式、代理实现后，交由测试人员进行部署和测试。

测试结果：令人失望的是，此问题依然存在！在通过外网WEB服务器访问的系统，其消息还是无法发送至消息总线。由此得知，此种分析方向是错误的！

至此，好像已经走入了死区,能想到的方式都已经想到了，但问题到底出在哪呢？

问题解决

在一次与同事聊天的过程中，忽然想到一个问题，那就是：我们的消息的产生和应用都是由应用系统和与之集成在一起的消息客户端自动产生和处理的，此过程中完全不受人工干预和影响。而应用系统是部署在应用服务器中，WEB服务器仅是用来处理用户的HTTP请求à将此请求转发至对应的应用服务器后à将应用服务器的响应返回给用户。

在此过程中WEB服务器并未对用户业的http请求进行过任何业务上的处理！那么，问题会不会出在WEB服务器端呢？检查一下消息中心的配置不管是使用ServerName还是写死IP和域名，我们的消息中心配置的地址都是指向WEB服务器。而在应用系统发现消息时，其所在位置是应用服务器。而应用服务器是无法直接访问部署于外网IP中的WEB服务器的，当然，消息无法发送至目标就成为必然了。

既然已经找到问题，那就动手，将消息中心的配置信息指向应用服务器后，重启应用系统后测试，问题果然解决！

通过应用服务器进行后台自动处理的，进行HTTP或WEBService活动，其目标必需是它能够访问的有效地址！这个问题在以前也曾经碰到过，只是由于时间隔得太久，且这些场景应用出现太少，而导致再次发生。

补充与心得

1、    基于应用系统或后台自动触发的一些业务逻辑，如其中存在着系统间相互访问或远程调用等，必需以应用系统自身为根，进行连接测试；通过外层包装或其它代理，进行访问时，必需先剥离过外层包装或其它代理后，再进行连接测试，并以测试结果，作为决策的依据！此举适用于各类系统的架构设计和逻辑实现过程中。

2、    基于中间件产品应用，及时开发与之配套的检测和使用工具，是一件必不可少的工作，此举将为后期的实施和问题分析节省大量的工作量。