Geek Answers Handbook

Advantages of SCA over Spring?

I have experience developing Java applications with Spring, but not so much with the SOA world. I read about SCA-SCA4J - http://www.service-conduit.org/user-guide.pdf - and a lot of this seems a lot like Spring.

I tried to find out in what situations SCA would be useful, but still did not understand what features / benefits SCA offers using stand-alone Spring.

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

I would appreciate it if anyone could give an explanation more focused on the Spring developer (which is very green in the world of SOA terminology / methodology).

thanks

+4
source share
3 answers

I'm not very knowledgeable about Spring, but I'm pretty familiar with SCA from working with it in the IBM WebSphere Integration Developer IDE and the environments in which it is deployed: WebSphere Enterprise Service Bus and WebSphere Process Server.

It really is all about abstraction and the thought of letting developers focus on what is most important - business logic. We are all familiar with the concept of object-oriented programming and how this abstraction better reflects the "real world". Then comes web services and a service-oriented approach. Web services further abstract our logic, making it less dependent on what language is behind our logic. Now C ++ or .Net or Java or even RPG or COBOL or something else may be behind our web service. We can get languages ​​and systems to talk to each other in a way that is independent of CORBA and libraries, and what is not.

SCA (Service Component Architecture) is trying to take SOA to the next level. He tries to abstract the protocol and address used to talk to another system or service. Here's why: when working with web services, you, as a developer, should still work with the protocol and write or connect to LOT templates. You need to know if you are http or https. You need to know if you (in the Java world) are JAX-RPC, JAX-WS 2.0, JAX-WS 2.1, JAX-WS 2.2 or even JAX-RS (based on REST). You need to know if you work with JSON, XML or SOAP, and if SOAP is 1.0, 1.1 or 1.2? And sometimes you even need to know how your application server provider implements certain things (you should not do this, but it may be). And then what happens if you want your web service to talk to another service. But this second service is based on the use of messages. Does this mean JMS? Mq? JMS over MQ? Others? What about just pure HTTP POST and GET?

Here is the SCA. SCA tries to abstract the endpoints of your services and hide the protocol implementation from the developer. When you need a service, you simply view it through the SCA API and then call the service (I think the method is executing? At least it's an IBM SCA extension). But anyway ... Now you don’t need to know that the service you are talking to is JAX-WS 2.1 or REST or even MQ. You do not have to know that you are working with SOAP / HTTP or JSON / XML or SOAP / JMS or something else. SCA hides it all from you. This allows you to connect services of different implementations to each other so that they can talk to each other through a common "service interface".

As you can imagine, this is another layer of abstraction and technology on top of existing abstract technologies. But, seeing this myself, I find it worth a look. I know that both IBM and Apache (and I think others that just don't come to mind at the moment) worked to come up with the SCA standard. (And in fact, the version of IBM SCA is now built on the open standard introduced by Apache. We hope that other vendors supporting SCA will do the same.)

I think it's worth taking the time to watch. This can help you focus not so much on the integration of services based on their protocols, but on the business logic of the services, which really represents the value that they bring to the table.

+9
source

SCA is standardized through OASIS ( Build Specification ), so you can choose from different implementations (e.g. Apache Tuscany or Fabric3).

SCA defines applications in terms of the following main building blocks:

  • interface: defines available operations Component
  • : describes an implementation artifact for which it offers “services”, what “links” it requires, and what custom “properties” it provides
  • binding: declares a communication protocol used by a service or link
  • policy: captures non-functional requirements for services, links, or implementations.

To create SOA applications, the specific "types" of these objects are compiled. For instance:

  • interface: WSDL port type, Java interface
  • component implementation: Java class, BPEL process, Python, Spring
  • binding: JMS, web service, RMI / IIOP
  • policy: transaction, security

In addition, SCA defines unified client APIs for invoking components both synchronously and asynchronously (including unilaterally). For Java, this involves binding to an annotation-based database.

Combining these capabilities allows you to easily create distributed applications from heterogeneous technologies and develop them by adding or replacing binding, implementation, interface, or policy technologies.

+3
source

It is worth looking at Spring integration (http://www.springsource.org/spring-integration) as opposed to the base Spring compared to SCA, as Spring Integration offers a very nice framework for transparent wiring along with remote components.

+1
source

More articles:


All Articles