| QUESTION & ANSWER |
ZapThink: SCA and JBI bring nothing to the SOA table |
 |
By Rich Seeley, News Writer
31 May 2007 | SearchWebServices.com |
|
|
Despite being positioned by vendors at standards for service-oriented architecture, Service Component Architecture (SCA) and Java Business Integration (JBI) will have little or nothing to add to SOA development, argues Jason Bloomberg, senior analyst with ZapThink LLC. In this Q&A, he explains the ZapThink view that SCA and JBI are mostly about vendor politics and hype and can pretty much be ignored by architects and developers working on SOA implementations.
So what is your take on the value of SCA and JBI to SOA architects and developers?
Jason Bloomberg: This is more about vendor politics and it is about technology or architecture.
How so?
Bloomberg: On the one hand you have JBI, which is essentially a Java plug-in architecture that you could use to build a Java-based ESB. You have Sun and Tibco leveraging JBI technology to provide a Java runtime infrastructure services.
On the other hand, you have the SCA camp, which is IBM, BEA, SAP, and some other players like Rogue Wave Software, who are building a component architecture for building service components, which are pieces of software that could consume or provide services. Now, they are not necessarily Java in the SCA world. There's a C++ implementation and a Python implementation, but notably missing is a .NET implementation. So it's not totally Java, but it's clearly driven by the big Java vendors outside of Sun and Tibco.
Is this just mudding the waters for SOA?
Bloomberg: The waters are plenty muddy already. This is not doing anything to clear it up. On the one hand you could think of SCA as a way for this group of Java vendors to diminish the role that Sun has with Java. That may or may not be true. That's just one perspective. Neither JBI nor SCA is particularly well suited for SOA. That's the odd story here.
So what are they good for?
Bloomberg: 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.
SCA is more about building components that consume services. So its for doing traditional development where you consume services, if that's part of what you want to do, but it's not about building services. It's not really focused on building services. It's focused on building components. It's a component architecture not a service architecture.
So is neither one a plus for SOA developers?
Bloomberg: That's the odd thing. 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. So this is more about the politics of Java than it is about the architecture of services.
One of the challenges when you talk about SOA infrastructure is that SOA is platform and technology neutral. So you can use any number of different technologies to build SOA implementations. You can use either one of these (JBI or SCA) as part of your SOA story, but it makes it more difficult to come up with a truly service-oriented approach. Because on the one hand JBI is saying build all your services in Java so we can plug them into this Java infrastructure. The SCA world is saying well let's think of services as components, so we can do traditional component development. It's not a service-oriented approach either.
By traditional development what are we talking about?
Bloomberg: It is object-oriented development. We're going to build objects. Objects are going to have interfaces. Sometimes the interfaces are service interfaces, sometimes they're other kinds of interfaces. We're working in the object-oriented paradigm where we are not able to support services in the OO paradigm as opposed to saying let's work in the service-oriented paradigm and think about how we are going to deal with objects in the service-oriented world. We're not doing that. We're saying let's live in the object-oriented world and see how we can deal with services there.
Where does Windows Communication Foundation (WCF) fit into this picture?
Bloomberg: Windows Communication Foundation is related. It's a little closer to SCA than JBI, partly because SCA is not Java-specific, even though it's dominated by the Java players. But keep in mind that WCF is part of an operating system. It's a foundational set of APIs for Windows. So while it does some of the same things, it's built for a different purpose altogether. It's built to unify Microsoft's operating system APIs. SCA is not about any particular operating system.
So what are SOA architects and developers going to do with JBI and SCA?
Bloomberg: JBI would be appropriate if you're an all Java shop and you're trying to come up with a way to improve the way you do integration. You may not be doing SOA at all and it could be useful. But you have to be an all Java shop. You may happen to be struggling with integration issues. You may be focused on solving integration issues in a single platform environment. In a Java environment. So it's of limited use.
In the SOA world, when we talk to enterprise architects, they are fundamentally heterogeneous. They are not thinking of all Java or all .NET or all anything. They're thinking of all mixes of stuff. If you have that context and you're an enterprise architect and you have a context of heterogeneity JBI has no role.
For SCA, it does not provide much value to the architect. It's really more the vendors trying to figure out a way to build components so their different components are built the same way. So it's really a question of how SCA will work it's way into products more so than how can an enterprise architect leverage SCA.
Is there another option for the SOA architect?
Bloomberg: If an SOA architect is really thinking in SOA terms, they're saying we have all this different stuff. We can incorporate these different runtimes, different platforms, different operating systems into a service-oriented architecture by abstracting all of the underlying technologies.
If all the application components are converted into services then they can work together?
Bloomberg: Now, I can start thinking about service-oriented approaches to meeting the business needs by composition, governance and metadata management, SOA best practices. So in the SOA world you're not focused on making sure all the runtimes are the same. You're saying whatever the runtime is that's fine. I'll live with that I'll abstract some capabilities and services, leave the capabilities where they are, incorporate those services into the architecture by adding the appropriate loose coupling infrastructures – security, management, governance, SOA quality. That's what the enterprise architect is focusing on. The enterprise architect is not focusing on service components. They're not focusing on integration infrastructure. They're focusing on architecture, service governance, management and quality issues.
So is it the case that JBI and SCA are about vendor issues and vendor politics and for somebody concentrating on SOA, it's not something they need to worry about?
Bloomberg: SOA architects just chuckle at the vendors and the games they play. Name your particular vendor. Each one plays their own games.
SCA and JBI will be marginally helpful at best. SCA because it's not language or platform specific is going to be a bit more helpful than JBI because JBI is one hundred percent Java. But even so, SCA is only marginally helpful.
|
