RE: Comments on committee draft - FWSI

Tan, 
  
OK - this helps clarify somewhat - however I'm still not sure that the
FWSI world view is entirely shared by the community at large?!? 
  
I think it is important to have a common understanding.  For example -
you assert that web services are a subset of SOA.  Since web services
were conceived long before SOA - and web services are the atomic
component - it seems the reverse is true - that SOA is a specialization
of web services?  Particularly as you need web services to do SOA - but
you do not necessarily need SOA to do basic web services?  Similarly
with ESB - clearly classic ESB goes back to the EDI days - and so it
would be better to point out that FWSI is an approach to SOA using
ESB-style architecture with web services? 
  
Tying your overall work into the fabric of the OASIS work is important -
and it is good that you are now looking at work such as ebXML Registry -
however - note that this registry work pre-dates the FWSI work by some 5
years - although of course the new V3.0 registry specification is just 2
years old now. 
  
I'm not convinced that providing a "primer" solves the inherent problems
in the organization of the specification.  Other TCs have tried that and
it fails - because you need the specification itself to be well
organized, clear and simple.  People after all are voting on the
specification - not the primer!!! 
  
I still have no idea what you mean by "pure built only" as opposed to
the alternative (what is the alternative)?  It's often tough for a TC
to create specification language that can be comprehended outside its
own team members - you should consider that when reviewing your terms
and usage. 
  
Error handling - other TCs are creating external error signalling
mechanisms - ebBP BPSS has an explicit "signal" toolset - and there are
specific web services one's too.  If your error handling is internal
only - then this should be stated and external mechanisms referenced as
notes. 
  
Hope these additional pointers are helpful. 
  
Thanks, DW
 

 -------- Original Message --------
Subject: RE: Comments on committee draft - FWSI
From: "Tan Puay Siew" <>
Date: Tue, September 05, 2006 1:11 am
To: <>
Cc: <>, <>

 
  
 Hi David Sorry for the late reply, but we were awaiting other feedbacks
before replying them at one go. I hope this email helps to answer your
queries.   Please see the answers below, prefix by [A].   Regards -ps- 
   
 ----------------------------------------------------------------------------------------------------------

 Subject: Comments on committee draft - FWSI ·        From: "David RR
Webber \(XML\)" <>  ·        To:
  ·        Date: Thu, 27 Jul 2006
09:57:22 -0700  
  Just reviewing your
 specification - please see individual items below.
   Overall I found it not clear what you are attempting to
 build?  Betterweb service functional components?  SOA functional
 components? ESBfunctional components?                   
  I had assumed
 the first option - so I was expecting simple templates
 andpatterns -
 instead it seems you are trying to solve wider sets
 ofproblems -
 rather than making simple and robust web services as
 thepriority?
                   
 [A] Yes, we are attempting to define common web service functional
 elements, which can be implemented as functional
 components.  Perhaps you need to divide the specification into two
 parts?  Simple webservices for easy adoption - and then all these
extended advanced
 parts(optional) such
 as QoS, Policy Management, Event notification and so
 on- that clearly
 require way more support and capabilities and are
 likelyto deter
 adoption - not ease adoption?   If so then you need to focus on these
core
 functions - for exampleperhaps aggregation should be in the first part
of the
 specification -not relegated to the back?  
                   
 [A] David, in fact you bring up a good point here. We have had
 discussions on this, and decided recently that we will not
 “clutter” the specification by dividing them etc. Instead,
 we are defining a Primer for the specification which will amongst other
 things, clarify and explain this aspect.  Thanks, DW   
http://docs.oasis-open.org/fwsi/v2.0/fwsi-fe-2.0-guidelines-spec-cd-02.pdf
  Line 28 -  The Framework for Web Services Implementation
 (FWSI) TC aims to enable robust implementations by defining a practical
and
 extensiblemethodology
 consisting of implementation processes and
 commonfunctional
 elements that practitioners can adopt to create high
 qualityWeb Services
 systems without reinventing them for each implementation. 
   However - in the specification you talk repeatedly about
 SOA.  This isconfusing.  What it appears you are actually describing is
a
 classicEnterprise
 Service Bus (ESB) style toolset including data
 repositoryand
 transformation with web services.                   
 [A] The basis of our work is still very much Web Services. However we
 use the term SOA more broadly, as Web Services is a specific
 implementation of SOA, and although we are very much WS-based, a lot of
 work that is done here could be used in other SOA implementations also.
 Also, on the ESB part, we see that ESB is another form of applications
 that could make use of the FEs that are identified in this specs. In
fact,
 it is our hope that others, like your good self, will refer and make
 use of this specs. J  Line 284 - Is this really your aim for
 FWSI?  This seems to be highlysubjective?  It appears instead that you
 are creating a framework forESB using web services?
   It
 aims to solve the problem of the slow adoption of Web Services due
 toa lack of good
 Web Services methodologies for implementation, cum a
 lackof
 understanding and confidence in solutions that have the
 necessarycomponents to
 reliably implement Web Service-enabled applications.
                   
 [A] Pls see answer above. Line 342 - You do not define what the
"loosely coupled model"
 actuallymeans? What is
 "loosely coupled" and why is an SOA assumed to be so?
 It's also not clear how FWSI
 supports this? Again term 'pure builtonly' could be better expressed -
perhaps -
 custom coding of bespokecomponents?
                      
        [A] Again, we
 are using terminology from SOA, and in our case, each FE are basically
 “stand alone” functionalities, unless where dependencies to
 other FEs are specified. So hence the use of the term “loosely
 coupled model”. Based on the SOA model, the idea is to reuse
 existing components/services where possible, versus that of the
 traditional model where most stuff are built from the ground –
 hence the term “pure built only”.  In a Service-Oriented Architecture
(SOA)
 environment, newapplications/services are created through the assembly
of
 existingservices. One
 of the key advantages of this loosely coupled model
 isthat it allows
 the new application/service to leverage on 3rd
 partyservices. As a
 typical 3rd party’s implementation of the services
 isdone via the
 software component approach, this specification
 furtherproliferate new
 applications/services by defining a framework for
 WebServices
 implementation consisting of Functional Elements.
 Throughthese
 Functional Elements, which are implementation neutral,
 thisSpecification
 hopes to influence future software development
 towardsassembly of
 services rather than ‘pure built only’. 
   Line 368 - This seems classic ESB approach?  Some may argue
 that ESBdata alignment
 is not loosely coupled but actually tightly coupled
 viathe data model
 that constricts information agility significantly?
   [A] As mentioned, ESB is
 definitely one possible usage scenario for this, but not necessarily
 restricted to ESB. We view ESB as one possible implementation
 application. Providing
 unified data view of enterprise across various
 datasourcesEnabling
 the partitioned view of data for differentgroups/departments based on
defined logical
 views, andPerforming dataprocessing or transformation before presenting
the defined
 logical dataview(s). 
   Line 428  - This should include references to OASIS ebXML
 Registry asmeans to
 implement the repository control and data view model and
 rulemanagement and
 OASIS CAM as a means to implement data views,
 rules,mapping and
 content selection and validation.         
 [A] Noted, we are looking into it and including new
 standards where appropriate. When we first defined these
 FEs, these new
 standards/inclusions weren’t there. Thanks for pointing out.
 ebXML registry is definitely one of them.  2.1.5 Related Technologies
and Standards
 RDBMS, LDAP, XML
 Database    Line 841 - This seems at odds with SOA neutral approach
 metaphor?  Theerror management described is actually internally facing
- within
 theweb service
 hosting system - rather than externally facing to
 theinvoker of the
 service?  So - this is more a internal
 systemsmanagement
 function to determine the status of each web service that
 isrunning. 
 So this is an internal reporting, monitoring and
 eventmanagement
 functionality?  Again ESB comes to mind here as a model.
 Line 1298 diagram appears to
 re-inforce this view.    [A] David, we look at it from
 someone/some company trying to develop an application based on the SOA
 approach. As such, errors arising from both internal as well external
 services are impt, in particular, knowing whether the error is
 externally generated, and not in the application developer’s
 control for example.  Error management is an important aspect in any
software
 applicationdevelopment. In
 particular, it is important to know the cause of
 errorin the Service
 Oriented Architecture (SOA) environment as anapplication can consume
any service provided
 from any domain spacespans across the Internet space. When an error
occurs, it can be
 fromwithin the same
 application domain or from different domain space.
   Line 2099 and Line 2281 - Federated identity management -
 theapplicability
 of the OASIS ebXML Registry federated management
 servicesshould be noted
 here including support for SAML.   [A] Noted, pls
 see earlier answer Line 2526 -
 Event driven reporting model with subscriptions
 andimplementation.  Again the OASIS ebXML Registry supports
 this use caseand should be
 mentioned here as related technology.   [A] Noted, pls
 see earlier answer Line 2865 - Key
 Management - this section contains no "RelatedTechnology" reference
section.  It should
 be noted that the OASIS ebXMLRegistry specification supports management
of
 certificates - and cantherefore provide equivalent functionality here
that can be
 re-used /extended.
  [A]
 Noted, pls see earlier answer  Line 3750 - Policy Management - Related
Technology - the OASIS
 ebXMLRegistry should
 be mentioned here as supported policy management
 withXACML.
   [A] Noted, pls see earlier
 answer