4

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.

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.

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.

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).

Thanks

Andrew B
  • 1,618
  • 2
  • 21
  • 30
  • I recommended you to read article from SOA expert Udi Dahan about SOA Concept: http://feedproxy.google.com/~r/UdiDahan-TheSoftwareSimplist/~3/NO6pf7RP8OE/ – Adi Sembiring Apr 20 '11 at 14:42

3 Answers3

9

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.

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 (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?

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".

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.

Chris Aldrich
  • 1,904
  • 1
  • 22
  • 37
  • Thanks for the reply - it is still unclear to me tho. So on a functional level - SCA doesnt really bring anything to the table over Spring, but allows you to build a system using SOA terminology / concepts? I am just trying to understand in what situations a SCA really offers value / functionality to the developer, or is it something geared more towards SOA architects? You mentioned the amount of boilerplate code required for web services, does SCA offer value here? (I have never had much if any boilerplate code to write when using Spring Web Services). – Andrew B Apr 21 '11 at 10:33
  • 2
    The "sweet spot" of SCA is abstraction of your protocols. With Spring you can abstract implementations of classes. So you could swap out a call to a JMS message service with a call to a SOAP/HTTP web service. But you would still have to code *how* to call the service, ie. you would have to deal with the protocol. With SCA, you have "one implementation", ie, in Spring you would call the SCA binding to the service. Now if the service changes from SOAP/HTTP to REST or JMS it doesn't matter. You still only invoke it with SCA. Does that make more sense? – Chris Aldrich Apr 21 '11 at 13:00
  • I think I am getting it a bit more now; so providing all your services are defined in your SCA architecture, if a service protocol changes from say SOAP to REST, because everything is wrapped / abstracted in this additional SCA layer - all the components which call this service are insulated to the protocol change - you would only need to change the binding / configuration in your SCA runtime...? – Andrew B Apr 21 '11 at 14:00
  • 2
    You got it. That is the thought behind it. You, the developer, are supposed to be isolated from "boilerplate" protocol logic and focus on writing your business logic. So Spring and SCA are not really in competition. They just solve different problems and thus they could be used in tandem with each other. – Chris Aldrich Apr 21 '11 at 16:32
  • @ChrisAldrich : please try finding some time to answer this question --http://stackoverflow.com/questions/28285102/differences-between-sca-service-component-architecture-and-esb-enterprise-se – Bruce_Wayne Feb 05 '15 at 12:36
  • 1
    @Bruce_Wayne - did so. Please see my answer there and see if it helps. – Chris Aldrich Feb 05 '15 at 15:45
3

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

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

  • interface: defines available operations
  • component: describes an implementation artifact in terms of which "services" it offers, which "references" it requires, and which configurable "properties" it exposes
  • binding: declares the communication protocol used by a service or reference
  • policy: captures non-functional requirements for services, references, or implementations

To build SOA applications, concrete "types" of these entities are assembled into composites. For example:

  • 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 to invoke components both synchronously and asynchronously (including one-way). For Java this includes annotation-based reference injection.

Combining these capabilities enables you to easily create distributed applications from heterogeneous technologies and evolve them by adding or swapping binding, implementation, interface, or policy technologies.

Ben
  • 31
  • 1
  • while you have alluded to how SCA differs from Spring, you have not explicitly highlighted them. For example, you've mentioned the policies, but didn't highlight the philosophical differences of how Spring and SCA allows for authoring of policies. – Dilum Ranatunga May 10 '11 at 17:27
1

It is worth looking at Spring Integration (http://www.springsource.org/spring-integration) as opposed to basic Spring when comparing to SCA, since Spring Integration offers a very nice framework for transparently wiring together remote components.

Robert Morschel
  • 341
  • 3
  • 11