Discussions

News: SCA and SDO seek a standards home

  1. SCA and SDO seek a standards home (13 messages)

    The Open SOA group has increased its ranks with seven new vendors including Sun Microsystems, Red Hat and Tibco Software. Members of the vendor-led initiative have vowed to get both specifications into a standards body. They even tipped that the Object Management Group might be an appropriate home for SCA. The group has also put together a homesite for the two specifications complete with news sets of white papers. SearchWebServices.com columnist Daniel Rubio has also put together primers on SCA and SDO. Are these specifications worth much consideration until they become full-fledged standards? Are they aiming at fixing actual problems that developers and architects currently face or is this a case of specification overkill?

    Threaded Messages (13)

  2. Simplicity...finally[ Go to top ]

    This is great! Restful services over SSL is sooo complicated. I'm glad 8 large corporations are getting together to simplify things.
  3. Re: Simplicity...finally[ Go to top ]

    To be fair, that's a really simple hello world example. The real target problem domain here is SOA. SCA Assembly standardized interaction links between services. Some simple examples of where this might help: 1) Today, you use a BPEL product and you can define standard business process definitions. All the cruft around it to enable specific bindings for the business interface and partnerlinks are wrappered with proprietary metadata and put in proprietary packaging. With the SCA Assembly model, this will be standardized. 2) Since SCA allows the description of relationships between services, you can start to model the SOA aspects of your datacenter using a standard model. You can imagine ESB metadata and tooling be modeled in terms of SCA. With the policy framework, we're heading down the path of providing standardization around the web services management space. 3) For Java developers, there's also a Spring spec. If you're simply building Java business logic with POJOs, you can use Spring now and get integration with an SCA SOA environment for free. My opinion is that the people will care about this will be focused on SOA efforts. If you're doing web application development, you're probably not going to be bowled over by SCA at this point in time. Greg
  4. MDA Approach?[ Go to top ]

    Hi Greg, It sounds like you are pointing out that SCA is offering a medium of design somewhat akin to what UML offers OO? If this is the case this would lead to more of an MDA based approach where something like JBI would fit nicely into the Platform Specific Implementation. Jason
  5. This is a good news. These days many server vendors offer some sort of ESB solution. With the definition of ESB being so unclear, hopefully, these specifications will standardize it or at least provide a foundation to build ESB servers on. It will be interesting to keep an eye on how (and if) JBI and these specifications coexist. IBM and BEA didn't vote on JBI, I am interested in seeing the role Sun plays in SCA/SDO group. C http://ChintanRajyaguru.com
  6. Chintan, The good news is that Sun has joined as a development partner for SCA with the rest of the Open SOA community. I expect they'll be fully engaged on the implications for the Java platform. Greg
  7. SCA and ESB are not competing technologies and there is not a lot in common. SCA is a model for building and assembling services in a number of technologies while ESB is a service mediation platform. The searchwebservices.com article is completely off base in saying vendors that are backing SCA are staying away from ESB. Far from it - WebSphere ESB and WebSphere Process Server which embeds WebSphere ESB allow services to be built on an SCA model but handles the mediation (protocol conversion or data transformation) between services through the ESB. BEA's ESB product, ALSB has been out for quite a while and we'd expect to see an SCA implementation from them soon. ESB is more of an SOA infrastructure whereas SCA is more of a standardized SOA development platform. Of course, the overlap between JBI and ESBs is huge but seems like JBI is more of an attempt from Sun to standardize a space (ESB) they did not get a head start in.
  8. The searchwebservices.com article is completely off base in saying vendors that are backing SCA are staying away from ESB.
    The article says nothing remotely like that. ESBs aren't even mentioned in it. In fact most of the vendors backing SCA sell ESBs.
  9. "ESBs aren't even mentioned in it"... Maybe you and I were reading different articles then. Here is the relevant extract from the SCA article on searchwebservices.com: "At a vendor level, while it may be a question of product line vision or simple coincidence, many SCA supporters who are also involved in the Java space have opted not to participate in the JBI/ESB approach, which puts into question not only the need for JBI/ESB, but more importantly the role SCA will play in the evolving battle for what approach is better suited to form the basis of an SOA."
  10. Satadru, my apologies, I thought you were referring to the most recent news story not the SCA column from Daniel Rubio. Though I read Rubio's comments as being more JBI focused, as in IBM and BEA haven't built support for JBI into their ESBs. Seeing that IBM has always insisted an ESB really is a set of design patterns more than a product and that SCA is a design pattern, I think your earlier comments about the relative importance of SCA to WebSphere and AquaLogic are probably dead on.
  11. JBI & ESB[ Go to top ]

    ESB is more of an SOA infrastructure whereas SCA is more of a standardized SOA development platform. Of course, the overlap between JBI and ESBs is huge but seems like JBI is more of an attempt from Sun to standardize a space (ESB) they did not get a head start in.
    But OTOH, JBI could hasten the commoditization of SOA infrastructure, which is maybe why the big vendors don't like it? Those pesky open source kids again ... Kit
  12. Re: JBI & ESB[ Go to top ]

    As I understand it, some of the major vendors' concerns with JBI have more to do with the JBI focus on running things within a single Java server process (JVM), whereas SOA typically involves multi-process (and even multi-language, i.e. languages other than Java) interaction between services. Randy
  13. I don't understand why all the programmers out don't call B.S. on all these WS-* standards that make the big companies money and yet hinder most programmers ability to get things done.
  14. I don't understand why all the programmers out don't call B.S. on all these WS-* standards that make the big companies money and yet hinder most programmers ability to get things done.
    Yes, it's almost impossible to keep up with all the industry specifications. Many of them seem to be just theory. However, SDO and SCA already have several implementations: http://www.osoa.org/display/Main/Early+Implementation+Examples+and+Tools PJ Murray CodeFutures Software Data Access Objects and Service Data Objects