RE: [opencsa-ms] Questions for InfoQ interview

Hi Mark,

 

Please see inline for a few answers from SAP. In 
general, we have tried to avoid repeating what has already been 
expressed.

 

Thanks,

Sanjay

  

  
  Von: Michael Rowley [mailto:] 
  
Gesendet: Mittwoch, 12. September 2007 21:17
An: Mark 
  Little 
Cc: 
Betreff: RE: 
  [opencsa-ms] Questions for InfoQ interview
Wichtigkeit: 
  Hoch

  

  

  
 

  
<MR>My 
  responses to some of the questions.</MR>

  
 

  

  

  

  
  

  
From: Mark 
  Little [mailto:] 
Sent: Monday, September 10, 2007 6:25 
  AM
To: 
  
Subject: Re: [opencsa-ms] Questions for 
  InfoQ interview

  
 

  
Mike, thanks for the responses. I'd like 
  to get this out before the Plenary, so could everyone else who said they'd be 
  interested in providing answers please do so before the end of this week? If 
  not, let me know when.

  

  
 

  

  
Mark.

  

  
 

  

  
 

  

  

  
On 5 Sep 2007, at 14:11, Mike Edwards 
  wrote:

  
 

  

Folks, 

My input 
  as 

<mje>...</mje> 
  

Yours, 
   Mike.

Strategist - Emerging Technologies, SCA & 
  SDO.
IBM Hursley Park, Mail Point 146, Winchester, SO21 
  2JN, Great 
  Britain.
Phone & FAX: +44-1962-818014 
     Mobile: +44-7802-467431  
Email: 
    
  

  
    
    

      
        
Mark 
        Little <> 
        

        
03/09/2007 
        12:01 

      
        
          
          

            
              
To

            
              
 
              

          

            
              
cc

            
              
 

          

            
              
Subject

            
              
[opencsa-ms] 
              Questions for InfoQ 
          interview

        
 

        
          
          

            
              
 

            
              
 

        

  

Here 
  are the questions for the InfoQ interview. Please feel free to answer any and 
  all. If you do answer any question, please put your full name and position 
  within your company and role within SCA/OpenCSA at the start of any reply: 
  that way I can link the information into the finished article. Please send 
  answers to me directly and then I'll follow up on a one-on-one basis if 
  necessary. 

Thanks, 

Mark. 

Q: Why do you think it 
  has taken so long for SCA to get to a standards body? 
  

<mje>I 
  don't think that SCA has taken long to get to a standards body.  SCA 
  started from scratch to address problems 
and 
  opportunities in the SOA space.  It was evolved by a group of 
  collaborators and this involved not only creation 
  
of 
  the specifications but also implementations in parallel to check the 
  specifications and provide useful feedback. 
Only 
  once the specifications were mature and we had the confidence that the 
  specifications were pretty solid did it 
make 
  sense to move forward to a standards body.  That time is 
  now.</mje> 

Q: Why OASIS and not W3C? 
  

<mje>The 
  choice of a standards body to use for any specification is not a 
  straightforward one.  However, SCA is 
primarily 
  about a programming model, rather than on-the-wire protocols, and we felt that 
  OASIS has a good track 
record 
  in this area - for example the WS-BPEL specification - and that OASIS also 
  offered a structure well suited 
to 
  the parallel group of technical committees that SCA 
  needs.</mje> 

Q: Why is SCA-J not being 
  worked on within the JCP? 

<mje>SCA 
  as a whole is not a Java specification - it is an SOA specification spanning 
  many techologies both Java 
and 
  non-Java.  It did not seem to make much sense to split away the SCA Java 
  specifications from the other SCA 
specifications, 
  making liaison between the Java group and the other groups more difficult. 
   It also keeps all the 
SCA 
  specifications available under one, easy to understand 
  license.</mje> 

  

Q: If you had 
  to summarize what SCA brings to this space in two sentences, what would they 
  be? 

<mje>A 
  language for describing composite services applications.  A simple 
  approach to the construction of service 
components, 
  concentrating on business function and keeping infrastructure concerns well 
  separated.</mje> 

  
<MR> I would 
  describe it as technology for creating, assembling and deploying service-based 
  applications out of multiple languages and multiple communications protocols. 
   Our most important design principal has been that the technology should 
  be as simple as possible, even if it means sacrificing some functionality for 
  simplicity when the two are in 
  conflict.</MR>

  

Q: Why 
  is your company interested in SCA? 

<mje>We 
  believe that SCA is an important building block in the use of SOA to build 
  business applications.  It will 
make 
  SOA more consumable and it will create a common pool of skills that companies 
  can draw on to build 
their 
  systems.</mje> 

  
<MR>BEA 
  believes that the industry is moving away from pure Java server-side 
  applications to a model where applications are built out of a variety of 
  higher-level technologies, such as BPEL, data integration technologies, XPDL, 
  ESB pipelines, etc.   We also believe that users want the composite 
  services that bring these technologies together to be specified declaratively, 
  in XML, rather than through APIs and programming.  However, there will 
  still be many critical leaf-level services created in Java.  SCA makes it 
  possible to create and deploy these mixed-technology applications in a 
  standard way.  It also provides a Java programming model that allows 
  services to be written without limiting the transport technology that will be 
  used to communicate with the service, which fits well with SCA’s assembly 
  model.</MR>
 

  
<SAP>We would like to second that and 
  would like to add that we believe that SCA provides a 
  framework suitable for integration with existing runtime and deployment 
  technologies such as Java EE and 
  OSGi.</SCA>

  

Q: Do you see any overlap between SCA and JBI? 
  

<mje>In 
  a word, no.  SCA is primarily concerned with building end-user 
  applications using a very wide range of 
technologies. 
   JBI is more concerned with building the infrastructure for heterogeneous 
  service applications on 
the 
  Java platform.  SCA can be used on a JBI runtime, but it is also possible 
  to use SCA without JBI and JBI 
without 
  SCA.</mje> 

  
<MR>Technically 
  there is no overlap.  JBI can be used as the infrastructure for creating 
  runtimes that can deploy and execute applications described using SCA 
  composites.  However I’ll be a little controversial and say that there is 
  some question, in my mind, about whether JBI is the best technology for accomplishing this. 
   JBI is based around a messaging paradigm that makes routing and 
  processing decisions on normalized messages at runtime.  However, SCA 
  makes it possible to use a more efficient infrastructure where the routing and 
  binding decisions are determined at deployment time so that message 
  communication can occur without normalization and with a minimum of 
  infrastructure overhead.  This is one of the reasons that neither of the 
  open source SCA runtimes that I’m familiar with (Fabric3 and Tuscany) have been 
  based on JBI. </MR> 

  
 

  

Q: Is there an equivalent 
  of SCA within Microsoft's arsenal of SOA technologies? 
  

<mje>Windows 
  Communication Framework (WCF) has some of the features of the SCA service 
  component model, 
but 
  there is no real equivalent of the SCA assembly model for the composition of 
  applications.</mje> 

Q: How do you see SCA 
  evolving now it is in a standards process? Will it change much, or do you 
  think it is close to being complete as it is? 

<mje>Our 
  expectation is that SCA will not change a great deal from the current 1.0 
  specifications.  The major task of the 
OASIS 
  technical committees is to create detailed conformance statements and 
  associated test suites that will help assure 
portability 
  and interoperability between conforming implementations of SCA from different 
  suppliers.  That is going to 
be 
  something of real value to end-users.</mje> 

  
<MR>I believe 
  that the major ideas in SCA have been fairly well thought out, so I’d be 
  surprised if they changed much.   However, I also believe that the 
  OASIS TCs will not just be hardening the design decisions that have already 
  been made, but will be able to make significant improvements to the design as 
  well.  The TCs will also have the benefit of the OASIS members that have 
  gained implementation experience with the SCA 1.0 specifications and will have 
  feedback from the efforts to create test suites for the 
  technolgy.</MR>

  

Q: One of the objections to SCA that 
  was leveled early on was that it competed against JEE. Now that Sun are 
  involved it would see that any such comments were unfounded. Is that correct? 
  

<mje>It 
  is perfectly possible to use JEE components and applications within an overall 
  application composed using SCA, 
where 
  other technologies are also used.  SCA even has a specification for doing 
  this.   So I'd say that SCA works with JEE 
rather 
  than competing.  SCA does acknowledge that there is more in a typical 
  business environment than JEE - that is very 
much 
  part of the world of SOA.</mje> 

  
<MR>I’d say 
  that there is some overlap with some parts of JavaEE, but not with most of 
  it.  Imagine a JavaEE application created out of EJB session beans, 
  JAX-WS (or JAX-RPC) services, message driven beans, and some deployment 
  descriptors.  It should be possible to create that same application by 
  creating component implementations using SCA’s Java programming model and 
  configuring them using SCA’s composite files.  The runtime might still 
  use JMS and one of the JAX SOAP stacks, but their APIs would not be visible to 
  the developer.

  
Areas 
  where there is no overlap include the JavaEE technologies for the presentation 
  tier (servlets, JSPs, JSF, etc) or the data tier (JDBC, JPA). 
   Technologies such as JCA and JMS still get used, but their APIs are not 
  use directly by the component developer.  Instead the infrastructure uses 
  those technologies to provide configurable bindings that provide access to 
  back-end systems or messaging systems, 
  respectively.</MR>

  
 <SAP> We  see SCA as a valuable 
  addition to Java EE. It will preserve the Java EE investment for developers 
  and vendors, and at the same time provide a framework which allows plugin of 
  new component models. In order to do that, we want to create an evolutionary 
  model for SCA that makes Java EE more SOA ready by extending the Java EE 
  application model and allowing access to new implementation technologies (such 
  as  BPEL for example) and  new protocol bindings. 
  

  
We see a 
  model that allows enhancement of Java EE applications with SCA artifacts and 
  artifacts of other, SCA-supported implementation technologies in one 
  assembly.

  
</SAP>

  

Q: Are there other areas of SCA that have 
  not yet reached a level of maturity for donation to OASIS? If so, can you give 
  us an idea of what they might be? 

<mje>The 
  Open SOA collaboration is continuing to discuss aspects of SCA that have not 
  reached maturity.  Some will directly 
be 
  part of the OASIS technical committee discussions.   Examples include a 
  Pub/Sub and Eventing model for the Assembly 
specification. 
   Others, such as the relationship of SCA to management facilities and SCA 
  specifications for some Scripting languages 
are 
  at a much earlier stage of discussions and will evolve initially outside OASIS 
  until they are suitably mature.</mje> 

  
<MR>Another 
  area where we expect the OASIS TCs to do work, but where we don’t yet have an 
  input document to provide, is a specification describing how JavaEE 
  applications can be integrated with SCA.  We do, however, have a Wiki page that 
  describes use cases that we care 
about.</MR>

  

Q: Is you 
  company an SCA developer, user, or both? 

<mje>Both. 
   IBM builds products that provide SCA, but IBM also has a services arm 
  that builds solutions using SOA 
for 
  our customers.</mje> 

  
<MR>BEA is an 
  SCA developer.</MR>

  
<SAP>SAP is 
  an SCA developer</SAP > 

  

Q: Where do you see SCA fitting within your company's 
  SOA strategy? 

<mje>It 
  is an important aspect of the core products that support building SOA 
  applications.</mje> 

  
<MR>We see it 
  fitting in in two basic areas.  One is that it will be integration 
  technology that will simplify the development, configuration and deployment of 
  applications that use multiple BEA technologies from our AquaLogic and 
  WebLogic product lines.  It will also provide a new simplifed programming 
  model that allows new services to be created in Java and deployed in 
  WLS.</MR>

  
 <SAP > Simplification of design and deployment of 
  composite applications is an important factor in realizing the benefits of 
  Enterprise SOA. Service Component Architecture (SCA) aims to achieve the 
  simplification of SOA-based service 
  composition.  SCA  also  has a great 
  potential  to provide standards 
  based  extensions of SAP NetWeaver with various application programming models and 
  communication  mechanisms used by our ecosystem of partners and 
  customers.</SAP >

Q: 
  Why isn't Microsoft involved? Since SCA is supposed to be language agnostic 
  and embraces many of the WS-* technologies that Microsoft has been involved 
  with, it would seem that their support would be necessary to make this a 
  meaningful standard? 

<mje>Microsoft 
  are free to join the OASIS SCA activities at any time and we would welcome 
  them.  SCA is a meaningful standard without Microsoft's involvement and 
  SCA is able 
to 
  support implementations on the Microsoft platforms, even if not  supplied 
  by Microsoft.</mje> 

Q: What is 
  your role within the various OpenCSA technical committees? 

<mje>Is 
  this meant to be a personal question or a company 
  question????...</mje> 

  
<MR>I am a 
  co-chair of the SCA-J TC, and a member of 4 other SCA-related TCs.  I am 
  also a member of the steering committee that oversees the OpenCSA 
  work.</MR>

  
 <SAP> SAP is 
  co-chairing the SCA-J TC and the SCA-BPEL TC. In addition, SAP 
  intends to continue being an active technical contributor, and also 
  volunteer for TC roles such as specification editor, etc. 
  </SAP> 

Q: Do you see SCA collaborating 
  or influencing other standards activities elsewhere? 
  

<mje>Yes. 
   There are a variety of other standards which relate to SCA.  Some 
  of those will influence SCA, 
others 
  SCA may influence.  An example are the standards involved in management 
  of systems, since when 
an 
  SCA application is managed. it will be most useful for the management 
  interfaces to reflect the SCA 
strucuture 
  of the applications.</mje> 

Q: The OpenCSA 
  Plenary week is coming soon. What do you hope will be the output from that 
  series of meetings? 

<mje>The 
  Open CSA plenary week will see the launch of the 6 SCA technical committees. 
   The output of the week will set 
the 
  pattern of the work on SCA for the next year or so.  In addition, for 
  those folk new to SCA, the plenary week will offer the 
  
opportunity 
  for some great free education on SCA from experts who have been involved from 
  the start.</mje> 

  
<MR>I am 
  looking to quickly deal with procedural issues and then start constructing the 
  list of meaningful technical issues that the TC members are already aware of 
  with the input specifications.  I’m hoping that these first days of 
  meeting face-to-face will put us on a solid trajectory of effective technical 
  progress that we will be able to maintain in the teleconference-based meetings 
  that follow.</MR> 

  
<SAP> In addition, we hope to see a 
  broader OASIS membership joining the SCA effort to validate and 
  drive further the development and adoption of SCA 
  technology.</SAP> 

  
Michael 
  Rowley
BEA Systems, Inc.

  

---- 

Mark Little 
 

JBoss, a Division of Red 
  Hat 
Registered 
  Address: Red Hat UK Ltd, Amberley 
  Place, 107-111 Peascod Street, Windsor, Berkshire,  
SI4 
  1TE, United 
  Kingdom.  
Registered in UK and Wales under Company Registration No. 
  3798903  
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) 
  

  

  

  
  

  
 

  
Unless stated 
  otherwise above:
IBM United Kingdom Limited - Registered in 
  England and Wales 
  with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
  3AU 

  

  
 

  

  

  
----

  

  
 

  

  
Mark 
  Little

  

  


  

  
 

  

  
JBoss, a Division 
  of Red Hat

  

  
Registered 
  Address: Red Hat UK Ltd, Amberley 
  Place, 107-111 Peascod Street, Windsor, Berkshire, 

  

  
SI4 
  1TE, United 
  Kingdom. 

  

  
Registered in 
  UK and Wales 
  under Company Registration No. 
3798903 

  

  
Directors: 
  Michael Cunningham (USA), 
  Charlie Peters (USA) and 
  David Owens (Ireland)