SCA比Spring的优势? [英] Advantages of SCA over Spring?

查看:168
本文介绍了SCA比Spring的优势?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有使用Spring开发Java Web应用程序的经验,但是对SOA领域却没有太多的经验.我正在阅读有关SCA- SCA4J的信息- http://www.service-conduit.org/user -guide.pdf -似乎与Spring非常相似.

I have experience developing java web applications with Spring, but not so much with the world of SOA. I was reading about SCA- SCA4J - http://www.service-conduit.org/user-guide.pdf - and alot of this seems very similar to Spring.

我试图了解SCA在什么情况下会有用,但仍然不了解SCA与使用Spring独立版相比具有哪些功能/优势.

I was trying to learn about what situations SCA would be useful, but still dont understand what features / benefits SCA offers over using Spring standalone.

我找到了这个旧博客帖子- http://rajith.2rlabs.com/2007/08/05/sca-vs-spring-a-reply-to-dans-post/-但从SOA行话.

I found this old blog post - http://rajith.2rlabs.com/2007/08/05/sca-vs-spring-a-reply-to-dans-post/ - but nothing really stood out to me from the SOA jargon.

如果任何人都可以对Spring开发人员(在SOA术语/方法论领域非常绿色)进行解释,我将不胜感激.

I'd appreciate it if anyone could give an explanation geared more towards a spring developer (who is very green in the world of SOA terminology / methodology).

谢谢

推荐答案

我对Spring并不是最了解,但是由于在IBM WebSphere Integration Developer IDE中使用过SCA及其所部署的环境而对SCA非常熟悉. :WebSphere Enterprise Service Bus和WebSphere Process Server.

I'm not the most knowledgeable about Spring, but am pretty familiar with SCA from having worked with it in IBM's WebSphere Integration Developer IDE and the environments it deploys to: WebSphere Enterprise Service Bus and WebSphere Process Server.

这实际上与抽象和允许开发人员专注于最重要的东西-业务逻辑有关.我们都熟悉面向对象编程的概念,以及该抽象如何更好地表示现实世界".然后是Web服务和面向服务的体系结构方法. Web服务通过减少对逻辑背后的语言的依赖来进一步抽象我们的逻辑.现在,C ++或.Net或Java甚至RPG或COBOL或我们的Web服务背后可能存在的任何东西.我们可以使语言和系统以不依赖于CORBA和库以及不依赖于CORBA和不依赖库的方式相互对话.

It really all has to do with abstraction and the thought of allowing developers to focus on what is most important - business logic. We are all familiar with the concept of Object-Oriented Programming and how that abstraction better represents the "real world". Then along comes web services and the service-oriented architecture approach. Web services further abstract our logic by making it less dependent on what language is behind our logic. Now C++ or .Net or Java or even RPG or COBOL or whatever could be behind our web service. We can get languages and systems to talk to each other in a way that doesn't depend on CORBA and libraries and what not.

SCA(服务组件体系结构)试图将SOA提升到一个新的水平.它试图抽象用于与另一个系统或服务进行通信的协议和地址.原因如下:使用Web服务时,作为开发人员,您仍然需要使用协议并编写或连接很多样板代码.您必须知道您是http还是https.您必须知道自己(在Java世界中)是JAX-RPC,JAX-WS 2.0,JAX-WS 2.1,JAX-WS 2.2甚至是JAX-RS(基于REST).您需要知道您使用的是JSON,XML还是SOAP,如果是SOAP,它是1.0、1.1还是1.2?有时,您甚至必须知道应用程序服务器的供应商如何实现某些事情(您不应该这样做,但是可以是这种情况).然后,如果您希望您的Web服务与另一个服务对话,会发生什么.但是第二项服务恰好是基于消息传递的.这是否意味着JMS? MQ?通过MQ的JMS?其他?那么单纯的HTTP POST和GET呢?

SCA (Service Component Architecture) attempts to take SOA to the next level. It attempts to abstract the protocol and address used to talk to another system or service. Here's the why: With working with web services, you as a developer still need to work with protocol and write or hook in a LOT of boilerplate code. You have to know if you are http or https. You have to know if you are (in the Java world) JAX-RPC, JAX-WS 2.0, JAX-WS 2.1, JAX-WS 2.2 or even JAX-RS (REST based). You need to know if you are working with JSON, XML, or SOAP and if SOAP, is it 1.0, 1.1, or 1.2? And sometimes you even have to know how the vendor of your application server implements certain things (you shouldn't, but it can be the case). And then what happens if you want your web service to talk to another service. But that second service happens to be messaging based. Does that mean JMS? MQ? JMS over MQ? other? And what about just pure HTTP POST and GET?

这是SCA出现的地方.SCA试图抽象服务的端点,并向开发人员隐藏协议实现.当您需要服务时,您只需通过SCA API查找它,然后调用该服务(我认为该方法是可执行的?至少在IBM的SCA扩展中).但是无论如何…….现在您不必知道与之通信的服务是JAX-WS 2.1或REST甚至是MQ.您不必知道您正在使用SOAP/HTTP或JSON/XML或SOAP/JMS或其他任何东西. SCA对您隐藏了这一切.它允许您将不同实现的服务彼此连接,以便它们都可以通过一个公共的服务接口"彼此对话.

This is where SCA comes in. SCA attempts to abstract the end points of your services and hide the protocol implementation from you the developer. When you need a service you just look it up via the SCA API's and then invoke the service (I think the method is execute? At least it is in IBM's extension of SCA). But anyway....Now you do not have to know that the service you are communicating with is JAX-WS 2.1 or REST or even MQ. You don't have to know that you working with SOAP/HTTP or JSON/XML or SOAP/JMS or whatever. SCA hides this all from you. It allows you to connect services of differing implementations to each other so they can all talk to one another via a common "service interface".

您可以想象,这是现有抽象技术之上的另一层抽象和技术.但是我自己看过它,所以我认为值得研究.我知道IBM和Apache(而且我认为目前还没有想到的其他人)正在努力提出SCA标准. (实际上,IBM的SCA版本现在是基于Apache提出的开放标准构建的.希望其他支持SCA的供应商也可以这样做.)

As you can imagine, this is another layer of abstraction and technology on top of existing abstracted technologies. But having seen it myself, I believe it is worth looking into. I know IBM and Apache (and I think others that just don't come to mind at the moment) worked on coming up with the SCA standard. (And actually IBM's version of SCA is now built on the open standard that Apache presented. Hopefully other vendors that support SCA do the same.)

我认为值得花时间去研究.它可以帮助您将重点放在基于服务的协议的服务集成上,而不仅仅是服务的业务逻辑,这实际上就是它们带来的价值.

I think it is worth taking the time to look at. It can help you to focus not so much on the integration of services based on their protocols, but rather the business logic of the services, which is really the value they bring to the table.

这篇关于SCA比Spring的优势?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆