RE: [wsbpel] Issue 72 and WS-I BP 1.0

Title: Message

Dear 
Ugo,

 

Not 
really.  The point I was making is that one way to achieve a high 
probability of interoperation between two or more independently implemented 
systems is for the implementers to follow specifications that have no 
options.  So to achieve its goal the WS-I BP has to be very 
restrictive.  If it has get out clauses - and implementers make use of them 
then it does not achieve its goal.  There are alternative approaches 
to achieving interoperability that I suggested and these include a basic 
'no-options' communications stack and the ability to negotiate the use of other 
functions / features dynamically at run time, and a flexible approach coupled 
with the use of 'agreements' between groups that wish to interoperate for a 
particular purpose (which is essentially the CPP/A 
approach).

 

So 
complying with the BP whilst using something else that SOAP over HTTP is a side 
issue.  But while we are on it perhaps you could explain it in more detail 
as I still do not see it.  Please refer to the trail of Requirements that I 
gave - see below.  But in particular I read: 

5.5.1 Use of SOAP Binding

The Profile limits the choice of bindings to the well defined and most 
commonly used SOAP binding. MIME and HTTP GET/POST bindings are not permitted by 
the Profile. 

R2401 A 
wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as 
defined in WSDL 1.1 Section 3. 

Note that this places a requirement on the construction of conformant 
wsdl:binding elements. It does not place a requirement on 
descriptions as a whole; in particular, it does not preclude WSDL documents from 
containing non-conformant wsdl:binding 
elements

This 
seems to make the requirement fairly clear.  It says elsewhere that only 
only Rnnnn statements count when it comes to considering conformance.  The 
note is purely informative but that says you can include other kinds of binding 
in a WSDL document but they are non-conformant.

 

Best 
Regards,

Tony                           

  
  

    
      

    
      
Tony 
      Fletcher

      
Technical 
      Advisor 
      
Choreology 
      Ltd.
68, Lombard Street, London EC3V 9L J  
       UK

  

    
      
Phone:  
      

    
      
+44 
      (0) 870 7390076

  

    
      
Mobile: 
      

    
      
+44 
      (0) 7801 948219

  

    
      
Fax:    
      

    
      
+44 
      (0) 870 7390077

  

    
      
Web:

    
      
www.choreology.com

  

    
      
Cohesions™

  

    
      
Business 
      transaction management software for application 
      coordination

  

    
      

      

Work:  
      

  

    
      
Home: 
      

  

  
-----Original Message-----
From: Ugo Corda 
  [mailto:] 
Sent: 03 October 2003 
  16:11
To: Fletcher, Tony
Cc: BPEL OASIS
Subject: 
  RE: [wsbpel] Issue 47 and WS-I BP 1.0

  
Hi 
  Tony,

  
 

  
It looks like one 
  of your major concerns about using BP 1.0 is its alleged prohibition of using 
  any WSDL bindings other than SOAP/HTTP. Please look at my previous notes for 
  my elaboration on this subject.

  
 

  
Ugo

  
    
-----Original Message-----
From: Fletcher, Tony 
    [mailto:]
Sent: Friday, October 03, 
    2003 7:11 AM
To: Ugo Corda
Cc: BPEL 
    OASIS
Subject: RE: [wsbpel] Issue 47 and WS-I BP 
    1.0

    
Dear Ugo and others,

    
 

    
First I have to say that the opinions expressed in 
    this mail are my own individual opinions based on my current understanding 
    (that is always amenable to update on the absorption of new 
    information!).

    
 

    
Saying that a minimum of one portType must obey the WS-I Basic 
    Profile is an interesting get out, but it raises other issues as Peter has 
    shown and fudges the real issue - see below.

    
 

    
It 
    seems that the application of the BP will not material affect the BPEL 
    language itself except possibly in some details (but this could be 
    significant - the devil is sometimes in the detail!).

    
 

    
However the BP, if applied strictly - which is its whole purpose - 
    will effect BPEL driven communications.

    
 

    
My 
    impression is that the prime motivation for BPEL is portability.  
    If the TC is going to adopt interoperability as a first rank goal, then I 
    think we should recognise this and maybe even have a vote on whether this 
    should be a prime goal.

    
 

    
BPEL demands the use of WSDL and if we then apply the BP then this 
    not only constrains the WSDL but also demands the constrained use of 
    SOAP,  HTTP, and XML.  For instance SOAP over SMTP is clearly 
    non-conformant

    
(BP 1.0a R0001 --> R2401 (R2702)  --> R1141(R1140) 
    R4004 R2800 & R2801

    
 

    
 

    
Let us take a step back for a moment.

    
 

    
It 
    seems to me that if we do accept BPEL instance run time 
    interoperability as a major goal (and as I have stated above I think that is 
    an issue the TC should explicitly decide on) then there are two extreme ways 
    to achieve this - and probably a spectrum of options in 
    between.

    
 

    
At 
    one extreme you specify just one way of doing something and everyone has to 
    implement all that is specified in the complete stack.  Nothing is 
    optional to implement and the meaning of everything is made as clear as 
    possible (this is always good independent of the approach!).  Not 
    everything has to be used on each instance of communication but this is the 
    only kind of optionality permitted.  It must always be possible to 
    initiate a communication and get an understandable response (which is why 
    only one way is supported in this case SOAP over a particular HTTP style and 
    SOAP over SMTP is not supported).  This is the approach taken by the 
    WS-I BP.

    
Pro:  The approach has worked well in the past.  Con:  
    It limits flexibility in the cause of interoperability.

    
 

    
The other extreme is specify whatever might be reasonably implemented 
    and used, and to let partners agree which particular set of options they 
    will use for communication between them.  This is essentially the 
    approach used for EDI (through Message Implementation Guidelines) and this 
    approach has been brought up to date in ebXML with the concept and use of a 
    CPA.  The CPA is an agreed format configuration file that a group of 
    partners agree to apply to their systems when engaging in the specified 
    business process(es).  It can be agreed manually or 
    semi-automatically.  It fixes the options to be used for those 
    instances of communications and different CPAs can be applied dynamically if 
    required.

    
Pro:  Allows flexibility in specification and 
    implementation.  Con:  Automation of this approach is relatively 
    new and it would require the development of a CPP/A for web services (the 
    existing ebXML one could be used as a basis if it was modularised so that 
    unwanted modules could be omitted and new web service relevant ones 
    introduced)

    
 

    
In 
    between these two extreme there is an approach that specifies a basic 
    communications stack that must always be implemented, which allows the 
    dynamic negotiation of additional features on any instance of 
    communication.

    
 

    
Variations on these major possibilities are clearly possible such as 
    having 2 or 3 (or more, but a small number) of 'Basic Profiles' and a very 
    simple pre- communication agreement mechanism (slim line CPA) to agree which 
    to use.

    
 

    
I 
    think this is the territory we have, perhaps somewhat unwittingly, strayed 
    into with the raising of the application of the WS-I BP, or 
    not.

    
 

    

    
Best 
    Regards,

    
Tony                           
    

    
      
      

        
          

        
          
Tony 
          Fletcher

          
Technical 
          Advisor 
          
Choreology 
          Ltd.
68, Lombard Street, London EC3V 9L J  
           UK

      

        
          
Phone:  
          

        
          
+44 
          (0) 870 7390076

      

        
          
Mobile: 
          

        
          
+44 
          (0) 7801 948219

      

        
          
Fax:    
          

        
          
+44 
          (0) 870 7390077

      

        
          
Web:

        
          
www.choreology.com

      

        
          
Cohesions™

      

        
          
Business 
          transaction management software for application 
          coordination

      

        
          

          

Work:  
          

      

        
          
Home: