With all respects to the Gurus of technology I would like to putforward my thoughts around "JBI & SCA". If any of my perceptions are wrong kindly send your valuable comments for my further learning….as you know Learning is a Never ending aspect for everyone.

I prefer to see JBI(Java Business Integration) & SCA(Service Component Architecture) as two complementary entities while building Service Oriented Business Integration. I define Service Oriented Business Integration as "Pragmatic Integration Architectural approach,to develop Collaborative, Standards oriented  Business Integration Solutions by leveraging SOA Principles, Applications, Computing Resources & Environments etc"
    
    Some of the industry technology analysts viewed JBI & SCA as competitive to each other, to a certain extent it is & it is not???  Fundamentally it is how you look into the usage. Some of the comments circled around JBI comparing against SCA are
   
   
    JBI falling out like another Hub-and-Spoke (HaS) environment: Truly not. One has to understand traditional HaS Model of EAI and the latest ESB architecture based on SOA Standards and Level of Abstraction it offers. Some how I feel who ever is comparing Traditional HaS models with Modern ESB is as good as comparing "Ape Man Vs Modern Man". Nothing varied much in appearance (hands, legs, head, heart) But lots of Modernization in behavioral aspects.
   
     Hub-and-Spoke(HaS) systems contains centralized hub that is responsible for connectivity, Message transitioning relating to requests/responses, coordination with spoked-in applications. Spoking to Hub from each application happens thru a Connector.
   
    Bus in the ESB – is a central unit which has abilities to keep Delivery channels to Congregation of Service Containers. Most of the latest ESBs provides distributed services infrastructures for development and deployment of services in any of the containers of the choice. ESBs also offers messaging, routing, and data transformation through XML.
   
    The key difference of traditional Bus based HaS integration systems Vs modern day ESB’s are abilitty to support SOA mechanism

•         Service Interface Design
•         Service Composition / Composite Application Development
•         Service Delivery
•         Service Access
•         Service Control
•         Service Governance
•         Service Standards
•         Service Orchestration / Choreography
•         Activity monitoring
•         Deployment monitoring

     More over mostly an intelligent ESB manages Containers by providing a common place for all service containers to live & perform, making an ESB as a Container of Containers rather than a Congregation point of direct Applications to be managed. Another advantage of ESB all its operational management is truly distributed unless its older look-a-like HaS as Cenrally manageable.
   
    Any environment which provides all these in a well structured distributed environment is definitely a good choice to do Business Integration. With JSR-208 JBI and OpenESB Community all the above said are well taken care proving JBI as an irrefutable environment for Business Integration application development & deployment.
   
    In the same context Service Component Architecture (SCA) initiative brings most of the Architectural principles on how to develop Service Architectures and components. This initiative offers lots of specifications for Service development & implementation. SCA emphasizes the bifurcation of service implementation assembly from the intricacies of Service Runtime Infrastructures. This decoupling of Implementation and Assembly from Runtime environments gives a different perception to develop SOA services – and deployable across many Integration Environments. More over SCA highly encourages to decouple middlewear with Service components business logic development.
   
    But in my view SCA is not meant to replace any of the technologies like EJB, Webservices etc, the model offers a clean way of developing Service Interfaces using your choice of technology, and implementation of each individual component or a service using any of the technologies of our choice depending on the Problem scenario.  SCA also puts standards across how services are WIRED with other services. For wide varieties of data integrations SDO (Service Data Objects) offers the technology to show a Unique model of the data to the services business logic.
   
    With all this said – is SCA Not sounding like a Well Defined Architectural Practices guidelines for SOA Development? Yes it is. Given the fact that one follows SCA Standards at a Developer level – still we can leverage capabilities of JBI to a bigger context to deploy,manage, integrate SCA oriented services in Business Service Integration technologies like OpenESB.
   
      

•     Coming to the OTHER CRY of industry that "JBI is a pure Java community View of Integration world" – So What! it is offering all the ideologies of an integration environment as mentioned above, and it is not enforcing anyone to write their fundamental/elemental business services only in Java. It is specifying a better way to hook the services to a JBI environment like OpenESB by providing SPI’s (Service Provider Interfaces) – I don’t think anything wrong in this methodology. If you see that JBI is forcing a service vendor or a developer to write their fundamental/elemental services as JBI, the perception is wrong! It is providing a way to integrate into a larger Integration environments. If this is the case I believe SCA & JBI/OpenESB are complementary to each other rather than competitors on any aspect.

• One other issue pointed in general discussions are "JBI is enforcing a J2EE container" to live, like on GlassFish, Sun Application server etc. To a matter of fact every software of this complexity defintiely requires a CORE or a kernel to work- why not a a J2EE container can offer JBI services to the BIG integration challenges. How many are really having issues of hosting a J2EE container as a matter of fact in their big enterprise installation?  I may anticipate JBI to run on its own in the future to avoid J2EE dependency if acceptance and adoption of J2EE containers is a challenge for Business Enterprises.