SCA Specifications moving to OASIS

Discussions

News: SCA Specifications moving to OASIS

  1. SCA Specifications moving to OASIS (10 messages)

    The Service Component Architecture specifications, initially developed by the Open SOA collaboration are now moving to OASIS for standardization. SCA provides a model for building applications using SOA. A series of OASIS technical committees (TCs) is forming and there is an open plenary session which will take place in Palo Alto on 18th September. For information about the OASIS TCs go to http://www.oasis-open.org/news/oasis-news-2007-08-09.php For details of the plenary session see http://www.oasis-opencsa.org/2007-plenary [Editor's note: is anyone using SCA in anger - meaning, with actual intent and purpose? It's one of those things that shows up in news items from time to time, and it's easy enough to see where it might be useful, but Your Humble Editor knows of only one company actually applying it, and a few vendors. Maybe it's me, but I just don't ... quite... get it. Anyone willing to step up and help?]

    Threaded Messages (10)

  2. Re: SCA Specifications moving to OASIS[ Go to top ]

    I'm also interested in understanding SOA, how the SCA initiative got to where it is today, and where it's heading. There's an interesting article titled "All I want for Christmas is a new SOA component model" on ZDNet by Dana Gardner. He gives a good summary of SOA, and sheds light on the some of the politics of the movement:
    Monty, what do we have behind door number one for our enterprise architect contestants? It’s SCA, which describes assemblies of components written from a variety of programming models and protocols in order to make integrating services and applications easier and without regard to specific middleware APIs or languages. Door number two opens to show us SDO, which offers wide access to business data, be it XML or relational, otherwise known as a standardized way to represent data as it moves to and around a budding SOA service network.
    Regards, Ian -- Ian Hlavats http://www.jsftoolbox.com
  3. SCA in IBM WebSphere[ Go to top ]

    IBM published a series of presentations A Practical Introduction to Web Services, SOA and ESB on z/OS that shows the place of SCA as well as SDO in IBM's WebSphere I haven't read the SCA specification yet, but that presentations give a good introduction to SCA and SDO. Thats interesting how WebSphere's SCA implementation compares to Apache Tuscany?
  4. IBM Websphere 6.0 ESB, WID, SCA and SDO[ Go to top ]

    I have done one project using IBM WebSphere 6.0 ESB,WebSphere 6.0 Adaptor, MQ 6.0 and WID. WebSphere ESB 6.0 use SCA and SDO for service interface definitions. Service interface can be implemented by any type of components such as JAVA, C++, J2EE etc. It is a nice solution but it is very early stage to address detailed features and comparison. Thanks
  5. Yes, SCA support in WID 6.0 was very buggy. However the things are much better with 6.0.2. (Don't be misled by the minor version change -- new version has lots of changes)
  6. The Paremus Infiniflow Enterprise Service Fabric is a distributed self-managing runtime that is itself built upon OSGi / SCA & will transparently support Spring 2.1 in the next release. Hence not only are we (Paremus) using SCA in anger, but our customers & partners - are running OSGi / SCA based distributed solutions; see SAIC quoye on OASIS site. We adopted SCA over a year and a half ago - not because of the potential market hype - "SOA3.0" - "J2EE replacement" - thought these may well be true in due course - but rather because SCA provided Paremus with a standards based approach defining (the wiring diagram) for sophisticated OSGi based composite enterprise applications. We see the move to OASIS as important. We still think the SCA standard needs work in a number of areas - but SCA's success - in some form - is only a matter of time. Cheers Richard
  7. Re: SCA Specifications moving to OASIS[ Go to top ]

    This has been announced in April.
    [Editor's note: is anyone using SCA in anger - meaning, with actual intent and purpose? It's one of those things that shows up in news items from time to time, and it's easy enough to see where it might be useful, but Your Humble Editor knows of only one company actually applying it, and a few vendors. Maybe it's me, but I just don't ... quite... get it. Anyone willing to step up and help?]
    SCA is a marketecture. As an application configure (property setters), assemblying (wiring, include local components as well as remote services), and deployment (exporting local components as services) framework, it is unnecessary complicated and less straightforward than conventional IoC containers. Even if the SCA configure/assembly/deploy model/schema was needed, it could easily be achived as a domain-specific model or language (DSM or DSL) on top of an decent IoC container with less than few hundreds lines of code in few hours.
  8. Re: SCA Specifications moving to OASIS[ Go to top ]

    ...As an application configure (property setters), assemblying (wiring, include local components as well as remote services), and deployment (exporting local components as services) framework, it is unnecessary complicated and less straightforward than conventional IoC containers...
    I'd be interested in hearing some more about what it is that you consider is complex about SCA. Yours, Mike.
  9. Re: SCA Specifications moving to OASIS[ Go to top ]

    We have a SCA container implementation (based on 0.95 or 0.96, not the 1.0) to be released this or early next month. Percisely, this SCA container is merely one of DSM/DSL examples of our IoC container, and is implemented in 500 lines of code (the IoC container and SCA examples will all be in open source). In the release, the SCA bigbank, calculator, etc. examples are all compared side by side to their IoC counterpart (namely, the component wiring, configuring, and service deployment/binding are all made in conventional IoC schema). Even though our SCA implementation has already avoided certain unnecessary complexities of SCA, it is still able to see IoC + DSM/DSL is more straightforward, clear, and consistent than SCA. Sorry I can't give too much detail before the release. As I said, SCA is a marketecture. Therefore, it is understandable that it is intentionally avoided to be straightforward. It is hard to hype something as trivial as IoC and DSM/DSL nowadays.
  10. Ke Jin,
    We have a SCA container implementation ... to be released this or early next month. Percisely, this SCA container is merely one of DSM/DSL examples of our IoC container, and is implemented in 500 lines of code (the IoC container and SCA examples will all be in open source). In the release, the SCA bigbank, calculator, etc. examples are all compared side by side to their IoC counterpart (namely, the component wiring, configuring, and service deployment/binding are all made in conventional IoC schema). Even though our SCA implementation has already avoided certain unnecessary complexities of SCA, it is still able to see IoC + DSM/DSL is more straightforward, clear, and consistent than SCA.
    It will be great to see your work once it is available. I'm glad to see that it has been straightforward to implement SCA. Can you give us an idea of where your open source will be released, so we know where to look for it?
    As I said, SCA is a marketecture. Therefore, it is understandable that it is intentionally avoided to be straightforward.
    Again, I'm interested in understanding what you mean by this. What is not straightforward about SCA? Which complexities have you avoided? Yours, Mike.
  11. Hi, We have been looking at SCA as a serious contender at VocaLink for our service composition, provisioning and governance requirements. VocaLink went through a five year, 100 million technology transition programme to migrate payments processing systems running on legacy mainframe systems to applications running on Java, Spring, Hibernate, Weblogic, Solaris and Oracle. Moving forward to meet the challenges of SEPA (Single European Payment Area), for us it is all about reusing our existing software assets and composing higher level business solutions by mixing them with new and off-the-shelf components. We think the composition-based assembly of SCA sand multiple C & I an approriate solution for our problem domain. Other SCA concepts which are quite key to us include, 1. Policies and intents that enable bottom-up service governance. 2. Bindings that allow the most approriate mechanism to be chosen for enabling component interaction, enabling services for extrenal consumers and consuming services provided by extrenal providers. 3. Domains that provide a unified view of the federated service model spanning the address spaces of our corporate infrastructure. We dont see SCA just as an XML based syntax for describing service composition, rather it also provides an extensible programming model, client and interface definitions, policy enforcement and governance. We have been using proprietary OSS ESBs for our SOA needs, which has worked well for us. However, now that SCA being a standard, the tremendous vendor support fro the likes of Oracle, BEA, IBM, SAP etc and light-weight runtime model adopted by OSS implementations like Fabric3 and Tuscany, have given us the confidence to move away from proprietary point solutions and embrace a more standards based strategic direction. We are starting our proof of concept using the OSS SCA implementation Fabric3, http://www.fabric3.org. The standards based model means, we can either stick with F3 or a vendor-backed SCA solution in the future. Kind regards Meeraj Lead Technologist http://www.vocalink.com