Tracking change and innovation in the enterprise software development community
IBM WebSphere
Virtualize apps
to lower costs,
Increase agility
Learn more!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
QCon San Francisco
Nov 19-21:
+ 80 sessions & tracks
Register now
and Save $400!
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Posted by Stefan Tilkov on May 17, 2007 04:46 AM
In a blog posting, David Chappell (the David Chappell from Chappell & Associates, not to be mistaken for the Sonic/Oracle David Chappell) has posted his impressions from a panel on the Service Component Architecture (SCA) he moderated at JavaOne. David highlights the fact that SCA is composed of two things, namely
[...] a new programming model for creating service-oriented components in Java (and C++), and a way to describe how components are assembled into groups called composites. Composites can contain components built using SCA’s new programming models, but they can also contain components built using other technologies, such as Spring and BPEL. SCA doesn’t define a new programming model for these other technologies, however; it just describes how components built using them can be made part of a composite.
The relative value of SCA and JBI, the Java Business Integration, has been debated here on InfoQ before -- there is now an official statement as to their relation. In previous postings, Chappell has argued that SCA is a threat to Java EE. Both IBM and BEA, whose J2EE/Java EE investment is not being seriously questioned, are big SCA supporters -- but as David points out, this can mean different things:
One more point to take away from this is that when a vendor says they support SCA, you can’t know what they mean until you ask them. When Oracle says it, they seem to mean the technology’s assembly aspects. When BEA says it, they seem to mean the assembly aspects and the Java component model, but not necessarily the C++ component model. When IBM says it, they seem to mean pretty much everything in the current 1.0 specs. When Sun says it--well, I’m afraid I can’t tell what they really mean.
Google's Gregor Hohpe shared his impressions:
The programming model, much like Microsoft's WCF, provides a unified API for all kinds of distributed systems communication. In the Microsoft world this is a big deal, and rightly so. So it was a little surprising that the vendor support for SCA's programming model is at best luke warm. Even a lot of the "official" documents seem to downplay this aspect of the spec. Only IBM and BEA are really supporting both aspects while the others openly stated that the programming model is not their focus.
Hohpe also questions whether SCA really has something do with SOA:
When I looked at SCA before it totally escaped me that the spec assumes that a composite has to run in a single vendor environment. This limitation means to me that SCA has relatively little to do with SOA, which has to deal with an environment that is heterogeneous and not controlled by a single vendor.
Indeed it seems that SCA addresses a topic different from the typical "high-level" SOA aspects. While that doesn't mean it's not a viable technology, it begs the question whether the common-place association with the standards around SOA is really applicable.
The Agile Business Analyst: Skills and Techniques needed for Agile
SOA Development Survival Guide
Software Quality Survival Guide
Scaling a Massively Multi-player Server Casestudy: Terracotta on SmartFoxServer
Spring App Platform, Java Concurrency/Multicore, Eclipse Mylyn and more @ QCon SF Nov 19-21
How does SCA different from OSGI? Seems like very similar goals and it would be nice if the two groups would just join and produce a more stable spec/implementation. OSGI seems to have more implementations to date and they seem to be well implemented and tested.
I met a managing director for a Tanzanian bank that makes microfinance loans, often less than $100. The bank executive made a decision to buy a Java-based software package for $250,000 to handle server-side and client interfaces to the banking management functions. Unfortunately the bank spent another $250,000 on a Java engineer to make the system output the reports they need and integrate with existing bank IT systems. "Why does it cost so much to do integration?" the bank director asked me. This is the cost of Sun, BEA, and IBM fighting among one-another over JBI and SCA. The fight keeps the costs high - and our salaries high - but does little to better the world. And that is a shame. -Frank Cohen http://www.pushtotest.com
1. If you're interested in SCA and OSGi combination see: http://www.osoa.org/download/attachments/250/Power_Combination_SCA_Spring_OSGi.pdf?version=3 2. There are a couple of SCA open source implementations out there. I've used Apache Tuscany and for the most found it a pleasant experience. 3. To Gregor's comment about SCA composites running in a single environment: I don't see this is as so much a limitation as it is a simplification. A more general "Composite" that spans environments essentially amounts creating a Service. Composites don't need to span environments so long as Services do. SCA maps to SOA in that it is a model for programming by contract across technology boundaries. The question arises as to whether it should define more than that.
Somehow, I never liked the idea of server side components. They seem to imply dependencies which are not necessary. Having something more vanilla seems aesthetically pleasing to me. The spec reads similar to EJB. Is this just an attempt to reuse some old technology?
I think your criticism is misplaced. Any fight between JBI and SCA is a misrepresentation. They are solving different problems. Indeed both can bring high quality backend systems within the reach of SMEs like the bank in your example by encouraging commoditisation of Java containers and frameworks. A valid point would be that it still requires a high level of competency to perform the actual integration itself. I suspect the cost came from hiring consultants who advised them on a monolithic system (he says guessing). Kit
Kit, do you know of a JBI binding component or service engine that works in more than one JBI container?
Well, these people do advertise as having tested with OpenESB and ServiceMix: http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=CORBABC . I know what you're getting at, but wouldn't you agree that having an evolving standard is better than having no standard at all? But this misses my point, that "JBI vs SCA" is a travesty and is not the reason why integration is expensive, but that in fact both should make it cheaper (in the long run) Regards Kit
Thanks so much for this! This is exactly what I was looking for mirc mırc eski mirc script indir irc komutları mirc indir kameralı mirc sohbet mirc indir mırc indir mirc mırc mirc yükle mirc download islami sohbet dini sohbet islami site islami chat kelebek kelebek script kelebekscript kelebek.gen.tr kelebek.com kameralı mirc indir kameralı mirc kameralı sohbet chat chat yap chat sohbet chatsohbet çet çet sohbet çet odası sohbet kanalları izmir sohbet kanalları sohbet odaları aşk sohbet odaları chat odaları soru cevap sevgili sevgili bul arkadaş arkadaş ara arkadaş bul arkadaşlık bedava sohbet arkadaşlık sitesi arkadaşlık siteleri partner erkek arkadaş bayan arkadaş oto araba mp3 astroloji zoydak nedir cep telefonları gazete marifetname bedava domain ücretsiz domain bayii parça kontör bayiliği bayii online kontör
Thin client paradigm characterized by web applications is a kludge that needs to be repudiated. Old compromises are no longer needed and it's time to move the presentation tier to where it belongs.
In this presentation filmed during QCon 2007, Jeff Sutherland, the creator of Scrum, talks about his visit at Google to do an analysis of Google's first implementation of Scrum.
In this article, Bryon Jacob and Chris Berry introduce AtomServer, their implementation of a full-fledged Atom Store based on Apache Abdera, which is now available as open source.
It is easy to think that virtualization applies only to servers. In reality the recent resurgence of the concept is also being applied to networking, storage, and application infrastructure.
In this article, Stefan Tilkov explains some of the most common anti-patterns found in applications that claim to follow a "RESTful" design and suggests ways to avoid them.
In this article, Adrien Louis and Marc Dutoo discuss the differences and relative merits of using orchestration vs. routing in a typical ESB setup, and discuss various implementation options.
Wayne Lund discusses batch processing, Spring Batch objectives and features, scenarios for usage, Spring Batch architecture, scaling, example code, failures and retrying, and the future roadmap.
Developer Jay Fields draws on his experiences as a ThoughtWorks consultant to describe effective user story estimation techniques.
8 comments
Reply