PHPRPC 让 SOA 从梦想变成现实
SOA 是一种程序设计思想,其实早在远古时代(计算机史)它就已经出现了。无非就是把系统分解,将数据和业务逻辑部分尽量独立出来,然后以服务形式提供给另外的系统共用。
那时也有一些可以实现 SOA 的工具,比如 DCOM、CORBA 等,不过前者仅限于 Windows,后者又太复杂,而且也仅对 C/C++、Delphi、Java 这等语言有较好支持,而且也都是商业开发软件中才会包含,对于开源的脚本类语言来说支持很差甚至没有支持(因为太复杂了,不是什么人都可以实现的了的,能够把整个 CORBA 规范完整读下来,都需要很好的耐心,还不一定都能够完全理解)。之后互联网发展了,XML-RPC 出现了,XML-RPC 很简单,但是也太过简单(因为它只是一个 SOAP 的实验原型而已),简单的数据可以传输,复杂点的就没办法了,所以后来就发展成了 SOAP 这个名字简单实际却很复杂的怪物,尽管 SOAP 已经够复杂了,但它也不过仅仅是定义了数据格式,于是后来就又有了一堆 WS-* 的补充。这样就变得跟 CORBA 一样了,不再是什么人都能理解,什么人都能实现了,或者说除了大公司和大组织有这个能力外,其他人基本上没有这个能力介入。再之后人们突然想发现了宝一样,发现了几年前就被提出来的 REST,于是一堆号称 REST 的服务又出现了,这东西看上去简单,可是实际上却是把数据转换、传输等等问题全都扔给使用者来自行解决了。最后 REST 教父都把这些号称 REST 的服务给否定了。除了这些以外,当然还有其它的方案,比如 Hessian、ICE、Adobe 的基于 AMF3 的通信方案等等,这些不能不说是好的技术,但不是局限于某几种语言,就是局限于某个特定的应用范围。所以要搞 SOA 就需要在这些不同的协议和解决方案之间进行转换,这就出来了 ESB,到这里之后已经看上去很好很强大了。可是它真的可以解决问题吗?真的不是在制造新问题吗?当然它解决了一定的问题,可是同样也制造了更多新问题。能够在各种技术之间转换固然很好,可是本来要掌握这些很复杂的技术中的一种就已经是一件很困难的事了,还要几种都学,几种都要用,这是多大的挑战啊!还有一个问题就是这些协议中本来就有慢的要命的(比如基于 SOAP 的 Web Service),还要再加个转换的过程,那还有什么效率可言。所以,ESB 最后就变成了“哦,傻逼”!SOA 也就变成了听上去很美,做起来很难的东西。
可是实际上我们回过头来再想想,我们要 SOA 到底是想实现什么?不就是要将系统分解,然后异构重组吗?最后问题就这么简单,我们需要的不一定是基于 SOAP 的 Web Service,不一定是将各种协议都能进行转换的 ESB。我们需要的是一种能够在异构系统间可以有效的进行数据交换的技术,这样我们就已经可以构建 SOA 的系统了。别的技术我不敢说,至少目前 PHPRPC 做到了这一点,你不但可以在 Java、.NET 这些语言之间方便的交换数据,还可以跟 PHP、Ruby、Python、Perl 这些开源脚本语言中以同样的方式交换数据,还可以用 Delphi/BCB 来做 Windows 界面的前台,也可以用 JavaScript 做 Web 前台,还可以用 Flash/Flex/RIA/WPF/SilverLight 这些来做内容更丰富的前台,而所有这些前台都可以共享同一个后台,还不需要关心后台究竟用什么语言来实现。甚至手机上的 J2ME、.NET CF、Flash Lite 和手机浏览器的 JavaScript 都可以完美支持。有了 PHPRPC 之后,你就突然就有了这么多选择,甚至随着 PHPRPC 的发展,你还会有更多更多的选择,SOA 从现在开始就不再是遥不可及的梦了。

“你的组织要求你更改PIN消息”将显示在登录屏幕上。当在使用基于组织的帐户设置的电脑上达到PIN过期限制时,就会发生这种情况,在该电脑上,他们可以控制个人设备。但是,如果您使用个人帐户设置了Windows,则理想情况下不应显示错误消息。虽然情况并非总是如此。大多数遇到错误的用户使用个人帐户报告。为什么我的组织要求我在Windows11上更改我的PIN?可能是您的帐户与组织相关联,您的主要方法应该是验证这一点。联系域管理员会有所帮助!此外,配置错误的本地策略设置或不正确的注册表项也可能导致错误。即

Windows11将清新优雅的设计带到了最前沿;现代界面允许您个性化和更改最精细的细节,例如窗口边框。在本指南中,我们将讨论分步说明,以帮助您在Windows操作系统中创建反映您的风格的环境。如何更改窗口边框设置?按+打开“设置”应用。WindowsI转到个性化,然后单击颜色设置。颜色更改窗口边框设置窗口11“宽度=”643“高度=”500“>找到在标题栏和窗口边框上显示强调色选项,然后切换它旁边的开关。若要在“开始”菜单和任务栏上显示主题色,请打开“在开始”菜单和任务栏上显示主题

默认情况下,Windows11上的标题栏颜色取决于您选择的深色/浅色主题。但是,您可以将其更改为所需的任何颜色。在本指南中,我们将讨论三种方法的分步说明,以更改它并个性化您的桌面体验,使其具有视觉吸引力。是否可以更改活动和非活动窗口的标题栏颜色?是的,您可以使用“设置”应用更改活动窗口的标题栏颜色,也可以使用注册表编辑器更改非活动窗口的标题栏颜色。若要了解这些步骤,请转到下一部分。如何在Windows11中更改标题栏的颜色?1.使用“设置”应用按+打开设置窗口。WindowsI前往“个性化”,然

您是否在Windows安装程序页面上看到“出现问题”以及“OOBELANGUAGE”语句?Windows的安装有时会因此类错误而停止。OOBE表示开箱即用的体验。正如错误提示所表示的那样,这是与OOBE语言选择相关的问题。没有什么可担心的,你可以通过OOBE屏幕本身的漂亮注册表编辑来解决这个问题。快速修复–1.单击OOBE应用底部的“重试”按钮。这将继续进行该过程,而不会再打嗝。2.使用电源按钮强制关闭系统。系统重新启动后,OOBE应继续。3.断开系统与互联网的连接。在脱机模式下完成OOBE的所

任务栏缩略图可能很有趣,但它们也可能分散注意力或烦人。考虑到您将鼠标悬停在该区域的频率,您可能无意中关闭了重要窗口几次。另一个缺点是它使用更多的系统资源,因此,如果您一直在寻找一种提高资源效率的方法,我们将向您展示如何禁用它。不过,如果您的硬件规格可以处理它并且您喜欢预览版,则可以启用它。如何在Windows11中启用任务栏缩略图预览?1.使用“设置”应用点击键并单击设置。Windows单击系统,然后选择关于。点击高级系统设置。导航到“高级”选项卡,然后选择“性能”下的“设置”。在“视觉效果”选

在Windows11上的显示缩放方面,我们都有不同的偏好。有些人喜欢大图标,有些人喜欢小图标。但是,我们都同意拥有正确的缩放比例很重要。字体缩放不良或图像过度缩放可能是工作时真正的生产力杀手,因此您需要知道如何对其进行自定义以充分利用系统功能。自定义缩放的优点:对于难以阅读屏幕上的文本的人来说,这是一个有用的功能。它可以帮助您一次在屏幕上查看更多内容。您可以创建仅适用于某些监视器和应用程序的自定义扩展配置文件。可以帮助提高低端硬件的性能。它使您可以更好地控制屏幕上的内容。如何在Windows11

屏幕亮度是使用现代计算设备不可或缺的一部分,尤其是当您长时间注视屏幕时。它可以帮助您减轻眼睛疲劳,提高易读性,并轻松有效地查看内容。但是,根据您的设置,有时很难管理亮度,尤其是在具有新UI更改的Windows11上。如果您在调整亮度时遇到问题,以下是在Windows11上管理亮度的所有方法。如何在Windows11上更改亮度[10种方式解释]单显示器用户可以使用以下方法在Windows11上调整亮度。这包括使用单个显示器的台式机系统以及笔记本电脑。让我们开始吧。方法1:使用操作中心操作中心是访问

Windows上的激活过程有时会突然转向显示包含此错误代码0xc004f069的错误消息。虽然激活过程已经联机,但一些运行WindowsServer的旧系统可能会遇到此问题。通过这些初步检查,如果这些检查不能帮助您激活系统,请跳转到主要解决方案以解决问题。解决方法–关闭错误消息和激活窗口。然后,重新启动计算机。再次从头开始重试Windows激活过程。修复1–从终端激活从cmd终端激活WindowsServerEdition系统。阶段–1检查Windows服务器版本您必须检查您使用的是哪种类型的W


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Dreamweaver CS6
Visual web development tools

WebStorm Mac version
Useful JavaScript development tools

Notepad++7.3.1
Easy-to-use and free code editor

MinGW - Minimalist GNU for Windows
This project is in the process of being migrated to osdn.net/projects/mingw, you can continue to follow us there. MinGW: A native Windows port of the GNU Compiler Collection (GCC), freely distributable import libraries and header files for building native Windows applications; includes extensions to the MSVC runtime to support C99 functionality. All MinGW software can run on 64-bit Windows platforms.

Atom editor mac version download
The most popular open source editor

hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
偶的rpcfx对于List Collection一律序列化成Array,
然后加个实际类型的标签~
不知道phprpc怎么处理的~
hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
这个是 C# 的吧?C# 的泛型比 Java 的好,可以获取到 xxx 的实际类型,所以在反序列化时,完全按照你声明的类型还原。
hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
这个是 C# 的吧?C# 的泛型比 Java 的好,可以获取到 xxx 的实际类型,所以在反序列化时,完全按照你声明的类型还原。
搞错 是 List
不知道phprpc对这种有什么改进。毕竟hashmap性能不好。
我对轻量级的远程调用很感兴趣。想问一下楼主,抛开性能问题,PHPRPC与XML-RPC和Hession/Burlap相比,在功能上主要有哪些优点?
hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
偶的rpcfx对于List Collection一律序列化成Array,
然后加个实际类型的标签~
不知道phprpc怎么处理的~
因为Java是擦除式的泛型,所以运行时绝对获取不到泛型的定义xxx类型。
但问题是,通过反射getClass方法不就能得到每个元素的Class类型了么?
hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
这个是 C# 的吧?C# 的泛型比 Java 的好,可以获取到 xxx 的实际类型,所以在反序列化时,完全按照你声明的类型还原。
搞错 是 List
不知道phprpc对这种有什么改进。毕竟hashmap性能不好。
那看来是 Java 了,Java 的泛型就没 C# 那么好了(没有运行期类型信息)。因此只有 xxx 是自定义类时,才可以正确处理。其它的如果是容器,应该是 AssocArray,其它基本类型就别用这种泛型容器方式了,直接用数组才能正确转型。
hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
偶的rpcfx对于List Collection一律序列化成Array,
然后加个实际类型的标签~
不知道phprpc怎么处理的~
因为Java是擦除式的泛型,所以运行时绝对获取不到泛型的定义xxx类型。
但问题是,通过反射getClass方法不就能得到每个元素的Class类型了么?
hmmm.....上一个项目 客户端用的 c++/cli。那边显示类型就是 hashtable。晚上试试phprpc效果如何。
hessian 对于 在
class xx
{
IList
}
里面的 xxx 一律映射为hashmap..变成 IList
偶的rpcfx对于List Collection一律序列化成Array,
然后加个实际类型的标签~
不知道phprpc怎么处理的~
因为Java是擦除式的泛型,所以运行时绝对获取不到泛型的定义xxx类型。
但问题是,通过反射getClass方法不就能得到每个元素的Class类型了么?
hmmm.....上一个项目 客户端用的 c++/cli。那边显示类型就是 hashtable。晚上试试phprpc效果如何。
我说的运行期,是指序列化程序(Java端)的运行期,不是rpc客户端的运行期。
应该在底层协议上,让SOA摆脱束缚,真正回到 服务和服务集成 的思维上。
应该在底层协议上,让SOA摆脱束缚,真正回到 服务和服务集成 的思维上。
SOA的三个问题这个框架一个都没有解决:
1)怎么非常快速的通过配置把一个Java,Spring,BPEL修改成这种协议?
2)怎么把别人用JMS,WS写好的服务用这种协议去访问?
3)怎么通过这个协议之上的框架把满足相关通信协议的组件形成一个流程
应该在底层协议上,让SOA摆脱束缚,真正回到 服务和服务集成 的思维上。
SOA的三个问题这个框架一个都没有解决:
1)怎么非常快速的通过配置把一个Java,Spring,BPEL修改成这种协议?
2)怎么把别人用JMS,WS写好的服务用这种协议去访问?
3)怎么通过这个协议之上的框架把满足相关通信协议的组件形成一个流程
我试着解答一下
1:写代码。phprpc就是做这个使的
2:还是写代码。既然phprpc可以支持多种语言,你就写java代码去掉jms呗,ws随便你了,用什么语言不行
3:依然是写代码。
1)定义一个类似workflow或者bepl的“流程服务”去封装及这个组件(如果你用java写的,我建议你使用jbpm;如果是多语言的,那你最好暴露出ws接口后用bpel封装),然后在phprpc中写代码调这个“流程服务”就可以了。
2)直接用phprpc一个一个调,然后自己写流程逻辑不就可以了吗。
哈哈,瞎扯的,别当真
另外,我记得还看到有人把Tibico看作是消息队列,我不知道有没有实际使用过Tibico,其实Tibico是一个中间融合剂。上面所谓的系统数据异构转换,完全可以采用Tibico这样的东西来做。Tibico是可以做数据转换与映射的,我觉得在SOA这样的“假、大、空”理论体系中最有用的部分应该就是Tibico这样的东东(IBM也有好像是叫做Interface change server简称ICS)有了这个东西,一开始提出的a1系统的融合就没有问题。比如如果a1使用的是ws,如果要融合,使用Tibico开发一个响应的适配器就可以很方便的进行融合,Tibico这样的东西应该说是屏蔽了协议。
还有,楼主确实不必要将PHPRPC与SOA扯上关系,PHPRPC的目的是什么?我觉得不是为了SOA,PHPRPC有自己的特色有自己的应用场景。
还有一点,我觉得PHPRPC今后的发展应该逐渐转移到使用的易用性,方便性,简洁性上。性能我觉得已经足够强大,不一定作为主要的目的。看看soap在一开始其目的就是面向易用的,使用xml的消息,人人都能看得懂,都能用。
楼主还是需要考虑一下如何将服务的定义能够统一描述,做到类似wsdl一样的定义。毕竟要做服务整合这个还是很有必要的,且还是很有用处的。
说了一堆废话,自己的见解不知道对不对,欢迎拍砖!
SOA已经成为了现实,
现在的问题是能不能让这种现实更美好
PHPRPC 跨语言吗?只是你在不断支持更多语言
在我看来PHPRPC更像一个RPC框架
应该在底层协议上,让SOA摆脱束缚,真正回到 服务和服务集成 的思维上。
SOA的三个问题这个框架一个都没有解决:
1)怎么非常快速的通过配置把一个Java,Spring,BPEL修改成这种协议?
2)怎么把别人用JMS,WS写好的服务用这种协议去访问?
3)怎么通过这个协议之上的框架把满足相关通信协议的组件形成一个流程
JMS是异步的,和WS能放在一起说么?理念和应用场景差异很大的。
应该在底层协议上,让SOA摆脱束缚,真正回到 服务和服务集成 的思维上。
SOA的三个问题这个框架一个都没有解决:
1)怎么非常快速的通过配置把一个Java,Spring,BPEL修改成这种协议?
2)怎么把别人用JMS,WS写好的服务用这种协议去访问?
3)怎么通过这个协议之上的框架把满足相关通信协议的组件形成一个流程
JMS是异步的,和WS能放在一起说么?理念和应用场景差异很大的。
怎么不能放在一起说....是你见识少而已, 没见过什么大的商业产品
譬如说sap的pi就支持这种场景
应该在底层协议上,让SOA摆脱束缚,真正回到 服务和服务集成 的思维上。
SOA的三个问题这个框架一个都没有解决:
1)怎么非常快速的通过配置把一个Java,Spring,BPEL修改成这种协议?
2)怎么把别人用JMS,WS写好的服务用这种协议去访问?
3)怎么通过这个协议之上的框架把满足相关通信协议的组件形成一个流程
JMS是异步的,和WS能放在一起说么?理念和应用场景差异很大的。
怎么不能放在一起说....是你见识少而已, 没见过什么大的商业产品
譬如说sap的pi就支持这种场景
请联系上下文看贴,不要鸡同鸭讲。
我的意思是:PHPRPC又不是异步的,和JMS有什么好比的,是和SOAP(Web Service)比。
我现在就碰到类似困境.在楼主另一篇大作中,我也咨询过.phprpc若能推广,我们都受益,呵呵.
如:
当在客户端取数据时,
List list = user.getList();
数据的确在list内,可通过list.size()知道list的大小,但在访问list内字符串数据时,总是报java.lang.ClassCastException: [B.........
请问一下这是什么原因呢?
我个人认为,应该是客户端根本就不知道服务端返回的list的数据是什么类型(就算知道list服务端传过来的是String List,强行转型也会出错),应该是直接以字节数组的形式传过来的,
那么我要获取list的字符串,是不是要挨过的将每一个字节数组转换成字符串哟,如果真是这样,那传一个自定义对象list
岂不是非常的麻烦。
您的判断非常的正确,确实字符串是以 byte[] 形式返回的,在不能明确获知字符串类型的情况下,字符串和字符数组都是以字节数组的形式表示的。
Java 的泛型只是一个语法糖,所以它的泛型元素类型是无法通过反射来获取的(这点与 .NET 泛型完全不同),因此,Java 的泛型元素类型如果设置为基本类型(包括String)和容器类型的话,则无法正确接收,只有自定义类型对象才可以用泛型容器来接受,因为自定义类型对象在序列化时是包含准确的类型信息的。
不过向这种类型,你可以在客户端通过声明成 String[] 来接收,因为这样就可以获取到元素类型,并自动进行正确的转换。否则,你就只能用非泛型接口(如List)或非泛型类(如ArrayList)接收了,接收之后,对于元素需要用 org.phprpc.util.Cast.cast 方法来进行类型转换。
测试时我也遇到这个情况,作者能解决吗?不然转换很麻烦
如:
当在客户端取数据时,
List list = user.getList();
数据的确在list内,可通过list.size()知道list的大小,但在访问list内字符串数据时,总是报java.lang.ClassCastException: [B.........
请问一下这是什么原因呢?
我个人认为,应该是客户端根本就不知道服务端返回的list的数据是什么类型(就算知道list服务端传过来的是String List,强行转型也会出错),应该是直接以字节数组的形式传过来的,
那么我要获取list的字符串,是不是要挨过的将每一个字节数组转换成字符串哟,如果真是这样,那传一个自定义对象list
岂不是非常的麻烦。
您的判断非常的正确,确实字符串是以 byte[] 形式返回的,在不能明确获知字符串类型的情况下,字符串和字符数组都是以字节数组的形式表示的。
Java 的泛型只是一个语法糖,所以它的泛型元素类型是无法通过反射来获取的(这点与 .NET 泛型完全不同),因此,Java 的泛型元素类型如果设置为基本类型(包括String)和容器类型的话,则无法正确接收,只有自定义类型对象才可以用泛型容器来接受,因为自定义类型对象在序列化时是包含准确的类型信息的。
不过向这种类型,你可以在客户端通过声明成 String[] 来接收,因为这样就可以获取到元素类型,并自动进行正确的转换。否则,你就只能用非泛型接口(如List)或非泛型类(如ArrayList)接收了,接收之后,对于元素需要用 org.phprpc.util.Cast.cast 方法来进行类型转换。
测试时我也遇到这个情况,作者能解决吗?不然转换很麻烦
这个问题产生的原因是PHPRPC所用的序列化格式不能区分二进制字符串和Unicode字符串,所以这个在PHPRPC里是硬伤,没办法修改。不过好消息是,我们的商业开源版软件Hprose中,这个硬伤被解决啦,而且是彻底的解决,所有类型都不需要做类型转化了(甚至连org.phprpc.util.Cast这样的帮助类都不存在了,因为完全不需要了)。Hprose在性能上还有大幅提升,效率是PHPRPC的10几倍,在易用性上也有了更大的改善,如果您有兴趣的话,可以测试一下。