ZapThink should rethink SCA and JBI

A ZapThink senior analyst, Jason Bloomberg, recently used an interview with TechTarget to make some rather unkind remarks about SCA and JBI. His bottom line was this: SCA and JBI aren't very helpful ("marginally helpful" was his phrase) for folks building SOA systems.

Bloomberg is certainly entitled to his opinion, but that is the problem with this piece: it is mainly raw opinions, with nothing concrete to back them up. And where he cites some facts, they are incorrect, and misleading. For example, he conjures up an imaginary world of two "camps", namely SCA and JBI, and even lists which companies belong to those camps. This is, of course nonsense. There are some 17 members of the Open SOA collaboration, including those organizations Bloomberg lumps into the JBI "camp". He is obviously trying to draw a division where none exists: JBI and SCA are in fact complementary technologies, as discussed the the Open SOA white paper entitled "Relationship of SCA and JBI".

Bloomberg's descriptions of JBI and SCA are similarly deficient. For instance, he states "JBI is more of a plug-in architecture where you can take Java-based components and plug them into a Java-based integration framework. Sure you can expose them as services, but it's really a single platform story.". He obviously doesn't realize that the interaction of all JBI components is based on a standard services model; all interoperation in JBI is through services only. He obviously has missed the core value proposition of JBI.

Bloomberg doesn't supply us with his definition of the term 'service', so this readers are left wondering exactly what he is thinking. From his JBI description, I suspect he is equating 'service' with SOAP-over-HTTP.

Bloomberg doesn't seem to recognize the need for service composition, dismissing SCA's elegant recursive composition model by stating, "SCA is more about building components that consume services." He appears to be worrying about service creation only; certainly he doesn't discuss how he would approach the composition problem. Why exactly are we supposed to be building those services, if not to compose them to create useful applications and services?

My main complaint about this piece comes from Bloomberg's statement, "If you really wanted to sit down with a blank sheet of paper and say, how am I going to build a component architecture for services, you wouldn't come up with either SCA or JBI." That's quite a statement, considering both technologies are currently at the 1.0 stage, and were started with an empty word processor document (sorry, no paper was involved :-). So what would be a better way, Mr. Bloomberg? How would you fill in that blank sheet? I would like to seem him share some constructive ideas, or better still join the standards-setting efforts going on at the Open CSA section of OASIS (Sun is a foundational member, by the way), or at the Java Community Process.

Whether or not Bloomberg wants to participate in the public standards-setting process, I encourage him to take a closer look at both SCA and JBI. I'd also suggest he look at some of the on-going projects involving JBI 1.0 (which has been around a couple of years now, so things have had more time to cook than SCA 1.0, which is only a few weeks old). He'd see a lot of interesting activities, including production deployments. Oddly, these systems have architectures that feature strong service orientation, and JBI is a key enabling technology allowing these systems to be built. Not "marginally helpful", but key.

Finally, I'd like to ask Bloomberg to revisit his assumption that JBI and SCA are in conflict. In my experience, this opinion reflects a lack of understanding of the technologies, a misapprehension that I'm sure will correct itself upon further study of the specifications.

Comments:

Post a Comment:
Comments are closed for this entry.
About

rtenhove

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today