z****e
发帖数: 54598 | 1 java有什么东西不是在你熟悉之后变简单的？
又不仅仅是thread部分，网络编程没有变简单？
从来不碰rmi，socket这些？ |
|
b***i
发帖数: 3043 | 2 有这样一个应用，京东的云存储可以通过服务器端通过密匙生成一个url,然后客户端得
到这个Url，来上传文件。
另一个方式，是客户端通过密匙生成一个JingdongStorageService对象，然后得到一些
其他相关对象直接操作云存储。那么，我觉得这样不安全，直接把密匙暴露在客户端。
如果用户反编译，则可以取得密匙。
能否把服务器的JingdongStorageService对象或者相关对象通过http返回到客户端，然
后客户端操作之？这样，至少，服务器可以决定是否停止提供给这个用户。
服务器就是京东云平台，所以可能不用rmi吧，只能操作web。 |
|
y********0
发帖数: 371 | 3 目前的skill set: Core java, java RMI, XML, Oracle, PL/SQL,web services, Unix
。 请教下这些找工作够用吗？为找工作考虑建议再学些什么skill?
刷题都有在刷。 |
|
y********0
发帖数: 371 | 4 目前的skill set: Core java, java RMI, XML, Oracle, PL/SQL,web services, Unix
。 请教下这些找工作够用吗？为找工作考虑建议再学些什么skill?
刷题都有在刷。 |
|
|
c**t
发帖数: 2744 | 6 so bad, it seems impossible:
Java intentionally severely limits your access to JVMs running applets. Java
applets can't access the client-side filesystem, and I'm fairly sure that
there is absolutely no way to access a client-side event queue either.
I would strongly recommend looking into the RMI, and trying to collaborate
with the 3rd-party applet's vendor. If you're attempting what I think you
are, Java won't allow it. Its web platform assumes that all systems involved
in any sort of transact |
|
y**b
发帖数: 10166 | 7 多谢。java才看了两个星期，这个RMI只有个概念，还不会用，似乎很方便。
第二个方法我也想到了，虽然有点繁琐。
原意是做一个小画板，一个用户每画一笔其他用户都能看见，
一个用户画的时候其他用户不能画(mutex)。 |
|
b*****e
发帖数: 474 | 8 来自主题: Programming版 - CORBA Berkeley sockets definitely.
If not at protocol level, such as distributed computing, maybe things like
RPC
or java RMI and IDL. CORBA is still supported. |
|
c*********e
发帖数: 16335 | 9 俺最佩服它的rmi,能想出这个idea的是我的偶象。
板。 |
|
N******7
发帖数: 1297 | 10 rmi的概念其实早就有吧，DCOM，Corba都是这种RPC的概念。不过Java的abstract做得
真不错，SUN的engineer书生气浓，但做事认真。 |
|
m*******l
发帖数: 12782 | 11 现在JAVA的抄的很多概念什么mvc, rmi啥的,人家微软不比这个晚 |
|
z*******3
发帖数: 13709 | 12 java之前有企业应用
但是濒临绝境，因为维护成本随着项目的增大，呈现指数级上升
所以有了人月神话那本书，那本书也是最早软件工程这个学科的圣经
可以说也就是有了这本书之后，软件工程才真正开始发展起来
只不过有趣的是
到今天还有人以为
大型项目的问题，还跟30年前一样，以为人们还在面临着相同的问题
刻舟求剑
那本书提高了一个很经典的沟通成本的问题
就是一个面向过程的开发语言的死结
所以才有了后来的面向对象
也正是通过面向对象语言的大规模采用
才使得这种沟通成本大大降低，模块化结构化的思想深入人心
后来才有了虚拟机这个东西，有了虚拟机
就保证程序能够跑在所有的os上，至少理论上是这样
然后jdbc保证了程序能跟所有的数据库合作，hibernate等工具强化了这一合作
再通过其他手段，比如tomcat等开源工具，保证了能跟浏览器客户端浏览器的合作
还有jni提供了跟c以及c++等语言的接口
所以真正最大的glue是java
包括r什么function language都有跟java的接口
这才是java的真正威力所在
而不是什么某一个语言上的feature的好坏
只对比语言某一个featur... 阅读全帖 |
|
z*******3
发帖数: 13709 | 13 大神，java做后端有一个特别明显的优势
多线程
这个也是很多时候最让人头疼的一块
python什么做web不是不可以
但是这个东西更像是一个单线程的东西
虽然说web我们都要用，而且大多数时候
web可以用单线程搞定
however
一旦量上去了，多线程是必需的
老早以前，后端就在用ibm那些8个cpu的server了
如果多线程支持不够的话，要想说普及开来
恐怕是不行的，虽然应付小型的应用，单线程＋分支线程这种模式可以搞定
也就是异步，event这些，但是真正的后端是建立在多线程的开发基础之上
这个java本身其实也做得不是很够，人们在这个基础之上
发明了app server这些，rmi也是多线程的
当然你要说这些是古董的话，多线程也有新的工具和框架
akka就是其中之一，对于旧的代码，util.concurrent包也做出了改良
所以这一块才是真正的分水岭，多线程也是后端最臭名昭著的麻烦
恐怕不用加之一了，而对于多线程的处理，恰恰是脚本语言的软肋
虽然你说python是oo，但是你也知道python对于多线程的支持怎样
为什么说web server没什么呢？
因为server s... 阅读全帖 |
|
g*****g
发帖数: 34805 | 14 还扯上了，连JNI跟RMI都不支持，java io的类库都藏了自己私货，还谈
兼容。JRockit 跑服务一直比Hotspot快，咋没见Sun告Weblogic？ |
|
c*********e
发帖数: 16335 | 15 rmi,
找几个code example,copy,paste.不用自己造轮子。 |
|
z*******3
发帖数: 13709 | 16 socket api
rmi
ejb remote
web service
jca
jms
太多了，随便选一个上 |
|
|
z*******3
发帖数: 13709 | 18 很多语言还真不能这么分析
比如rpc的方法，很多语言就比较欠缺
比如python
java的rpc不仅可以web service来做，还有rmi
还有ejb，还有jca，还有jms，各种方法各种做
实际动手时候只会觉得方法太少，而不是太多
很多时候压根就不提供这个东西以外的方法
你没有选择，好的政府，提供java/c++的toolkit
操蛋的政府，就只有java的toolkit给你
好的提供json/xml
坏的就只有xml
没有选择的余地
这就是现状，学会去适应，而不是尝试着去革命
人不要动不动挑战环境，人的力量很渺小
包括大神您 |
|
g*****g
发帖数: 34805 | 19 JNI, RMI去了，core classes改了，还兼容性呢？真是无脑。 |
|
z****e
发帖数: 54598 | 20 所谓的mapreduce的话，其实无非是多线程＋切割＋不同物理机器上查找的一个实现
找到后把结果反馈最后归并的一个过程，如果对多线程和垮物理机器有点经验的话
其实大同小异，难点主要是这两个，但是都算不上什么特别难的
多线程是编程基础，这个多线程比绝大多数多线程都简单
甚至没有什么并发的冲突，应该不用加任何锁在map的时候，reduce的话应该也不用
垮物理机的调用稍微有些深入，但是网络学得好的话
问题不大，用不了rmi或者corba可以用socket来写，socket学过网络的应该也都会
毕竟这个查找不要求百分百精准，而且对时间的要求也偏低
不象游戏那样要求那么高，这是第一个
第二个是nosql的存储，这个其实可以看成是一个简化的db
也就是不存在有sql和transaction的db系统，只有很少的几个index
所有查询必须通过这个index来做，所以灵活度比不上sql
但是简化的东西没有理由比脚本更难才对，所以学过db的话
这个其实也不是很难，理论上不会比db的sql难，毕竟是简化的东西
如果是搜多引擎的话，定义两个index就差不多了，一个是网站的域名
另外一个是日期，日期排序... 阅读全帖 |
|
z*******3
发帖数: 13709 | 21 你们迟早都要连起来的
把backend
我之前问你用什么连其实就是根据经验作出的判断
因为系统集成最难的往往就是怎么连起来
其实如果你是不同系统的话
web service几乎是你们能选择的唯一的手段
无论json/rest还是soap，其实效率都一般般
中间有各种消耗，所以我问你有没有其它手段
但是如果是java的话
jms, jca, rmi, ejb, mq之类的随便选
GET |
|
z****e
发帖数: 54598 | 22 不止rest算，连rpc,rmi,jms那些都算
ws只是实现soa的一种手段而已
不仅限于用ws实现 |
|
m******t
发帖数: 635 | 23 rpc,rmi这些东东还在用么？好像非常久远了 |
|
|
z****e
发帖数: 54598 | 25 从最简单的facade开始说
facade就是一个统一的对外包接口
当然这个接口要有实现的部分
但是对于不同的组件而言，其它人要是想操作这些组件的话
只需要跟这一个接口打交道就行了
比如你有apple和oragne两个东西
那么你自己定义了一个fruit接口
那么这个接口提供了getApple和getOrange两个方法
那么你就不需要单独滴去跟apple还有orange相关类打交道
每次要找fruit，直接找这个接口就好了
proxy就是一个代理
举个例子，比如你想跟另外一台机器上的jvm打交道
那么每次你都需要向那台机器发送各种请求
那么一个很直接的想法就是，我在本机制造一个对象，并假设这个对象就是那台机器
然后所有跟这个机器打交道的操作，我给封装到这个对象里面去
那么这个对象就是代理，这个在rmi时候用得比较多
stub和skeleton，stub就是代理，remote接口就是一个代理 |
|
F****n
发帖数: 3271 | 26 那时候必须得会DCOM和CORBA
IUnknown啥的Stupid
CORBA后来做Java RMI的项目发挥了作用，
当时感叹终于没有白学。
结果几年都改Web Service了。 |
|
z****e
发帖数: 54598 | 27 corba -> rmi -> web service
jni -> script engine
这都是一个演绎进化的过程 |
|
g*****g
发帖数: 34805 | 28 所有的这些东西，不过是几个词，scalability, availability, elasticity。
clouding computing/nosql/big data底下的各种轮子就是个building blocks. 轮子多
了，选择多了，对开发者的经验要求也更高。能够熟练运用这些轮子的，就有能力设计
架构。不熟悉的，在别人做好的架构上添砖头一样可以混口饭吃。当年j2ee(jsp,
servlet, jsf, ejb, jmx, jms， rmi)同样是一堆东西，java的难点从来就不在java语
言上，
而是熟练掌握并应用这些框架上。
跟js在前端这一波相比，js只是重新解决以前解决了的问题，开发更快速一点而已，效
率更好一些。后
端这波则是解决以前解决不了的问题，比如log下企业里每个数据的变化，并从中分析
用户的需要而获利。以前无法承受这样的数据量，或者有这样的数据量无法处理，现在
有解决方案。各个企业往里的投入也完全不是前端的变化可以比拟的。
的. |
|
b*******s
发帖数: 5216 | 29 看了下java的remoteexception
就是rpc
A RemoteException is the common superclass for a number of communication-
related exceptions that may occur during the execution of a remote method
call. Each method of a remote interface, an interface that extends java.rmi.
Remote, must list RemoteException in its throws clause. |
|
c********1
发帖数: 421 | 30 【 以下文字转载自 JobHunting 讨论区 】
发信人: xtaihc (波波), 信区: JobHunting
标 题: 工作总结，.net 方向的，大牛就不用看了。
发信站: BBS 未名空间站 (Tue Sep 2 21:47:31 2014, 美东)
首先感谢一直支持我的老婆哈，正是她的工作稳定，我当老公的才可以跳来跳去的，还
帮我生了个漂亮女儿：）。
再次跳成功，感觉一次比一次难，我找的不是大公司，中小型的吧，经过5个月的折腾
，终于搞定。H1B很悲催啊，基本上公司一听H1B,基本上就没什么戏了。想起那些刚刚
毕业的学弟，估计更难吧，不过肯找，还是没问题的，这个是事实。
先介绍一下自己，4年前非名校毕业。sotware engenner, H1b,略知皮毛. 工作方向是.
net 方向，工作不忙，有时感觉会无聊，下班没事的时候自己私下给别的小企业做软件
和系统和counselor，开始的时候感觉怕做不好，也怕丢人，现在感觉也挺有意思的，
没啥怕的，基本上小企业到后边会挺依赖你的，挣钱挺容易。最近给一个企业做架构和
OA,用的是c#,MVC,EF,KnockoutJS... 阅读全帖 |
|
g*****g
发帖数: 34805 | 31 这东西本来就是企业Server端跑得，ejb是97年的东西，90年代的企业市场也是由Sun跟
IBM主导的，Corba消失很大原因就是JDK内建了Corba的支持，使得过度很容易。Spring
火起来是05年的事情了，当年主导Spring remoting的也是Hession, Burlap, RMI，而
不是Web Service。 |
|
a*f
发帖数: 1790 | 32 从协议上来说应该是Corba -> RMI -> Web Service
2000前还是JDK 1.1 1.2，2000年才有了J2EE的规范，97 98 JEE属于还在摸索中 |
|
z****e
发帖数: 54598 | 33 ws是后来m$跟jcp闹翻之后
自己出去搞了一个.net
游离于主流之外，大门自己也觉得这样不行
迟早还是要合流，所以m$就跟ibm几个一起搞出了ws
xml几乎就是为ws量身定做的
再然后就是soap和uddi还有wsdl的失败
被简化的rest和json统统干掉
ejb在一些银行里用得还是比较多的
ws也是用在系统间比较多
单纯的java分布式系统内部，比如hadoop什么还是用rmi |
|
a*f
发帖数: 1790 | 34 把这个链补全应该像这样
DLL Link ->OLE->DCOM/RPC->Corba->RMI->WS->REST |
|
z****e
发帖数: 54598 | 35 corba之前的不知道，太古老了
但是corba->rmi->ejb remote->ws(soap)->restful ws差不多
restful ws已经把网络通信简化到最简了
包括通信协议都可以自由选择，数据结构用json应该是以后主流
再简单估计也难 |
|
c********1
发帖数: 5269 | 36 shared memory, tcp/IP socket, RMI. |
|
|
g*****g
发帖数: 34805 | 38 The right way is to use an external caching server like Memcached or Redis,
and you keep your cache there.
That being said, the simpliest way on top of your current architecture is to
set up a REST or JMX or RMI call to invalidate cache on other nodes when
data is
updated
. And you can statically configure your nodes to know all other nodes in the
cluster.
send |
|
f*****w
发帖数: 2602 | 39 此外我想起来CORBA 原生的实现貌似是C++ 所以如果Java里面在用多半 意味着你的
东西对某些C++的东西有依赖
楼上zhaoce大牛说的rmi 我不懂 但是我感觉如果真是有远程的某个东西居然还是c++
的 那真还是挺麻烦的 |
|
z****e
发帖数: 54598 | 40 corba是跨语言的
不仅仅是java
REST, RMI, DCOM, CORBA, and web services
都是类似的东西
++ |
|
o**2
发帖数: 168 | 41 dcom应该和corba/rmi等类似，属于remote/distributed oop一类的技术吧？
昨天的中文简介是从编程语言的角度去看Lemina技术，接下来我会写一篇从编程范式的
角度来看Lemina，希望能给你和楼上的appoolloo提供一个新的角度来理解Lemina。
这里不妨剧透一下：
Object vs Lemina function
Object-oriented programming vs Lemina function-oriented programming (aka
Lemina programming)
OOP language runtime vs Lemina computer |
|
z****e
发帖数: 54598 | 42 源自rmi时代ejb的local接口
ejb的下场应该都很清楚了 |
|
z*******3
发帖数: 13709 | 43
复杂什么，websphere和weblogic都有很傻瓜的gui
只不过都是要钱的，一般ejb用annotation也可以很简单
协议ejb用的是rmi，你说的可能是web service restful |
|
z*******3
发帖数: 13709 | 44 mr本质上是对不同的函数提供一个标准化的接口
就有点像spring为不同的obj提供一个标准化的接口一样
最终你不需要依赖客户的具体obj以及func
你就能写出东东来给其它人去用
hdfs本质上是对于不同node提供了一个标准化的file system接口
用了rmi，底层是jvm对于不同os的封装
db也有啊，db的统一封装就是jdbc，对于sql的统一封装就是hibernate这些
没有这些东西，你自己搞也无非那么一回事
现在hdfs的替代品也多了起来，比如c*，这个做得比较高级一点，各种工具比较多
比如vert.x也提供了一个低级的file system的封装
同样hdmr的替代品也逐步多了起来，比如yarn，spark还有蓄势待发的flink
不过这些主要是batch
stream应该是下一阶段重点，storm，rxjava，flink stream应该会大放异彩
展开新一轮的搏杀，硬盘上的数据没啥意思，还是搞内存中的数据有趣 |
|
z****e
发帖数: 54598 | 45 对于同一台jvm上的spring用法几乎是一样的
无论是不是toy还是prod. code
如果分布式的话，spring就不管了，你自己要想办法处理跨机器的通信
比如用jms，或者web service，或者rmi
总有一种rpc适合你
如果你非要举出例子来
public class MyClass{
@Autowire
private UrClass urClass
public void doSth(...){
...
urClass.func(...);
...
}
}
基本上就这个模式 |
|
z****e
发帖数: 54598 | 46 效率如何？
web server benchmark上没有看到对比
有个系统，之前用rmi，很慢
后来改成了netty+json那一套，其实就是自己做了一个vert.x
速度快不少
但是看到用到了jetty
不知道还有没有优化的空间 |
|
z****e
发帖数: 54598 | 47
用什么都有，用tomcat因为apache口碑好，坑少，文档多
没了，就这一个，这是最理想的，一个类库做一件事
错了，spring的功能是di，主要是管理一个bean的生命周期
这样从客观上节省了内存和decoupling，其次也减少了内存泄漏的可能性
另外一个spring的主要功能是aop，这是spring两大利器
致于mvc，那个其实不重要，属于扯蛋的部分，ui的东西扯蛋居多
因为db本身的市场正在被nosql所蚕食，nosql天生就是object
所以不怎么强调orm，db因为都是relational，所以需要orm
作为trade off，orm牺牲了一部分性能，但是好处是可以比较容易滴迁移db
hibernate用上去之后，你就不在乎mysql和postgre的差别了
当然这很理想，但是至少一定程度上搞定了这个问题
类似ror
no，java的世界缤纷多彩，你看看techempower那个列表
你就可以看到，几乎一半都是jvm上的东西，你很难说某个东西一定不对
都是个人的选择嘛，grails对于groovy来说很重要，要知道
groovy可是表现最佳的脚本，这个你看vert... 阅读全帖 |
|
|
t****l
发帖数: 134 | 49 Simply,
Web services provide a way of invoking local/remote functions via
standard mechanisms: SOAP (messaging), WSDL (description), UDDI
(discovery). Basically, it can be regarded as evolution from RPC,
CORBA, and RMI, etc.
XML is the technique used in SOAP, WSDL and UDDI.
Web services don't need a web page to host them. |
|
l****t
发帖数: 49 | 50 The UNIX RPC (for standard C) and JAVA RMI. the tranditional RPC interfaces
are NOT convinient for users who know nothing about the two complex language.
Especially, when you want to use RPC in web application, mostly in SGML via
HTTP, embedding any of the two inteface into the asp or whatever is difficult.
In order to solve this problem, the XML-RPC and later SOAP are developed.
Here, the RPC is the functionality, while XML is only the format and encoding
of the data. For further information, p |
|
