参照分布式和企业系统结构、及应用开发的重点明显地转向基于构件的应用开发,讨论基于构件应用开发的未来趋势

pptuzi 2004-08-11 06:30:51
参照分布式和企业系统结构、及应用开发的重点明显地转向基于构件的应用开发,讨论基于构件应用开发的未来趋势.


呵呵,这个是我在NIIT这学期的ISAS项目。不不是很明白,有什么大家说就可以了。谢谢
本人QQ:27258391
...全文
362 18 打赏 收藏 转发到动态 举报
写回复
用AI写文章
18 条回复
切换为时间正序
请发表友善的回复…
发表回复
huangbang 2004-08-27
  • 打赏
  • 举报
回复
小兔你还真高
帮你顶了
huanghelang 2004-08-27
  • 打赏
  • 举报
回复
丫的,怎么全是jspcool中的熟人!
am2000 2004-08-27
  • 打赏
  • 举报
回复

cucuchen 2004-08-27
  • 打赏
  • 举报
回复
呵呵,帮小兔先顶顶~!
pptuzi 2004-08-27
  • 打赏
  • 举报
回复
嘿嘿,谢谢
紫黑蓝白 2004-08-18
  • 打赏
  • 举报
回复
帮兔子顶顶先,呵呵。
gengjun83 2004-08-18
  • 打赏
  • 举报
回复
UP
pptuzi 2004-08-18
  • 打赏
  • 举报
回复
哇噻,好厉害啊,继续继续,不要停


嘿嘿,接着顶。
robbit2002 2004-08-16
  • 打赏
  • 举报
回复
实际上组件体系结构的发展还是在不断成熟当中,软件的发展朝着技术可重用性的方向发展,
而在探索发展技术可重用性的道路上也产生了很多分支,同时也走了不少的弯路,组件体系结构的出现是一个亮点,但它不是银弹,我们还有很多很多的问题要解决,其中一部分问题不是技术本身的问题,还有很多非技术因素。
技术基础设施的搭建是容器体系的核心,但没有标准的支持,我想这种技术也无从发展,标准怎么来?
是要靠所有与这种技术相关的人来共同制定和维护的,sun想自己来统一这个标准,我觉得它的想法很好,同时也有了很好的市场竞争,我但个人觉得标准应该是开发的,应当由所有与其有关系的人来制定,这样的标准才是最符合大众要求的,不然的话就是只能想ejb那样,让人又爱又恨!
shuneng 2004-08-15
  • 打赏
  • 举报
回复
理论研究吗搞? 是不是有必要看看外人的PAPER
紫黑蓝白 2004-08-15
  • 打赏
  • 举报
回复
其实这跟软件的发展历史是有很大的关系的,随着企业级应用系统的复杂度不断的提高,人们在探索软件的可重用性和提高开发效率的道路上又一次飞跃。
面向对象的开发模式解决的是企业应用复杂度到软件系统的转化的问题,而基于构件的开发我觉得就是人们解决可重用性上的一次飞跃。
它使得应用和技术的分离走入了我们的视野,从而发展出了容器和组件这两个相辅相成的软件概念。
可以说容器来解决技术问题,而组件来解决应用问题,这是一个好的设计思想,两者分离,两者独立发展,而两者又不可分割。
=============================================================

基于构件的开发确确实实给解决可重用性带来了。。飞跃。,。也给开发者提出了新的要求。在系统的可扩展性方面,也是种有效的尝试。在设计容器组件系统结构时,为了利于系统的可扩展性组件开发,容器的设计成了核心也是难点。我感觉,为了使系统具有一定的可扩展性,这比设计组件的可重用性更具难度。

类比J2EE,在J2EE服务器容器下,开发者完成一个个EJB的设计,对于可重用性方面,它无疑拥有了很好的容器支持,如何设计EJB自身的应用逻辑使其具备应用独立性和功能完整性成了关键。然而,对于一个实际应用,往往需要多个组件(或EJB)共同协调完成,这也带来了组件间如何处理耦合连接问题。


有点偏题了,不知所云。呵呵。
朋友别哭 2004-08-15
  • 打赏
  • 举报
回复
up
robbit2002 2004-08-15
  • 打赏
  • 举报
回复
其实这跟软件的发展历史是有很大的关系的,随着企业级应用系统的复杂度不断的提高,人们在探索软件的可重用性和提高开发效率的道路上又一次飞跃。
面向对象的开发模式解决的是企业应用复杂度到软件系统的转化的问题,而基于构件的开发我觉得就是人们解决可重用性上的一次飞跃。
它使得应用和技术的分离走入了我们的视野,从而发展出了容器和组件这两个相辅相成的软件概念。
可以说容器来解决技术问题,而组件来解决应用问题,这是一个好的设计思想,两者分离,两者独立发展,而两者又不可分割。
pptuzi 2004-08-15
  • 打赏
  • 举报
回复
工作。。。。。。


minghuitian 2004-08-14
  • 打赏
  • 举报
回复
gz
紫黑蓝白 2004-08-14
  • 打赏
  • 举报
回复
ISAS,这是什么啊?
紫黑蓝白 2004-08-14
  • 打赏
  • 举报
回复
兔兔的说法好抽象,呵呵,不知该说什么了。
pptuzi 2004-08-14
  • 打赏
  • 举报
回复
能有图片和文章的超连接也可以
本课程是一门具有很强实践性质的“项目实战”课程,即“企业中台系统实战”,其中主要包含三大块核心内容,如下图所示(右键可以在新标签页中打开图片放大查看): 即主要包含以下三大块内容: ① 企业内部应用系统菜单资源和操作权限的统一管理; ② 分布式应用系统通信时的统一授权,即基于AccessToken的授权与认证; ③ 分布式服务/系统通信时的两大方式(基于dubbo rpc协议和基于http协议的restful api实战)。   值得一提的是,这套中台系统由于讲解了如何统一管理企业内部各大应用系统的“菜单资源列表”、“操作权限”,故而本门课程的“代码实战”是建立在之前debug录制的“企业权限管理平台”这套课程的基础之上的,故而在这里debug建议没有项目开发基础的小伙伴可以先去学习我的那套“企业权限管理平台”的实战课程,之后再来学习我的这套中台系统的实战才不会很吃力(课程链接:)   本课程的课程大纲如下图所示(右键可以在新标签页中打开图片放大查看):   除此之外,这套“中台系统”由于统一管理了企业内部各大应用系统的“菜单资源和操作权限”以及“应用系统之间通信时的统一授权”,故而难免需要涉及到“中台系统”与“中台子系统”、“中台子系统”与“中台子系统”之间的通信(即分布式服务之间的通信),在这里我们是采用“dubbo + zookeeper”的方式加以落地实现的,详情如下图所示(右键可以在新标签页中打开图片放大查看):   而众所周知,作为一款知名以及相当流行的分布式服务调度中间件,dubbo现如今已经晋升为Apache顶级的开源项目,未来也仍将成为“分布式系统”开发实战的一大利器,如下图所示为dubbo底层核心系统架构图(右键可以在新标签页中打开图片放大查看): 而在这门“中台系统实战”的课程中,我们也将始终贯彻、落地dubbo的这一核心系统架构图,即如何将中台系统开发的服务注册/发布到注册中心zookeeper,中台子系统如何订阅/消费/调度中台系统发布在zookeeper的接口服务,中台子系统在走http协议调度通信时dubbo如何进行拦截、基于token认证接口的调用者等等,这些内容我们在课程中将一一得到代码层面的实战落地!   下图为本课程中涉及到的分布式系统/服务之间 采用“http协议restfulapi”方式通信时的Token授权、认证的流程图(右键可以在新标签页中打开图片放大查看): 而不夸张地说,基于AccessToken的授权、认证方式在现如今微服务、分布式时代系统与系统在通信期间最为常用的“授权方式”了,可想而知,掌握其中的流程思想是多么的重要!   以下为本门课程的部分截图(右键可以在新标签页中打开图片放大查看):     核心技术列表: 值得一提的是,由于本门课程是一门真正介绍“中台思想”以及将“中台思想”和“分布式系统开发实战”相结合落地的课程,故而在学完本门课程之后,可以掌握到的核心技术自然是相当多的。主要由SpringBoot2.0、SpringMVC、Mybatis、Dubbo、ZooKeeper、Redis、OkHttp3、Guava-Retrying重试机制、JWT(Json Web Token)、Shiro、分布式集群session共享、Lombok、StreamAPI、Dubbo-Filter以及ServiceBean等等。如下图所示(右键可以在新标签页中打开图片放大查看):

67,513

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧