OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

fwsi-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on committee draft - FWSI

Just reviewing your specification - please see individual items below. 
Overall I found it not clear what you are attempting to build?  Better
web service functional components?  SOA functional components? ESB
functional components? 
I had assumed the first option - so I was expecting simple templates and
patterns - instead it seems you are trying to solve wider sets of
problems - rather than making simple and robust web services as the
Perhaps you need to divide the specification into two parts?  Simple web
services 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 likely
to deter adoption - not ease adoption? 
If so then you need to focus on these core functions - for example
perhaps aggregation should be in the first part of the specification -
not relegated to the back?   
Thanks, DW 

Line 28 -  
The Framework for Web Services Implementation (FWSI) TC aims to enable 
robust implementations by defining a practical and extensible
methodology consisting of implementation processes and common
functional elements that practitioners can adopt to create high quality
Web Services systems without reinventing them for each implementation.  
However - in the specification you talk repeatedly about SOA.  This is
confusing.  What it appears you are actually describing is a classic
Enterprise Service Bus (ESB) style toolset including data repository
and transformation with web services. 
Line 284 - Is this really your aim for FWSI?  This seems to be highly
subjective?  It appears instead that you are creating a framework for
ESB using web services? 
It aims to solve the problem of the slow adoption of Web Services due to
a lack of good Web Services methodologies for implementation, cum a lack
of understanding and confidence in solutions that have the necessary
components to reliably implement Web Service-enabled applications. 
Line 342 - You do not define what the "loosely coupled model" actually
means? 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 built
only' could be better expressed - perhaps - custom coding of bespoke
In a Service-Oriented Architecture (SOA) environment, new
applications/services are created through the assembly of existing
services. One of the key advantages of this loosely coupled model is
that it allows the new application/service to leverage on 3rd party
services. As a typical 3rd party’s implementation of the services is
done via the software component approach, this specification further
proliferate new applications/services by defining a framework for Web
Services implementation consisting of Functional Elements. Through
these Functional Elements, which are implementation neutral, this
Specification hopes to influence future software development towards
assembly of services rather than ‘pure built only’.  
Line 368 - This seems classic ESB approach?  Some may argue that ESB
data alignment is not loosely coupled but actually tightly coupled via
the data model that constricts information agility significantly? 
Providing unified data view of enterprise across various data
sourcesEnabling the partitioned view of data for different
groups/departments based on defined logical views, andPerforming data
processing or transformation before presenting the defined logical data
Line 428  - This should include references to OASIS ebXML Registry as
means to implement the repository control and data view model and rule
management and OASIS CAM as a means to implement data views, rules,
mapping and content selection and validation. 
2.1.5 Related Technologies and Standards 
RDBMS, LDAP, XML Database  
Line 841 - This seems at odds with SOA neutral approach metaphor?  The
error management described is actually internally facing - within the
web service hosting system - rather than externally facing to the
invoker of the service?  So - this is more a internal systems
management function to determine the status of each web service that is
running.  So this is an internal reporting, monitoring and event
management functionality?  Again ESB comes to mind here as a model. 
Line 1298 diagram appears to re-inforce this view. 
Error management is an important aspect in any software application
development. In particular, it is important to know the cause of error
in the Service Oriented Architecture (SOA) environment as an
application can consume any service provided from any domain space
spans across the Internet space. When an error occurs, it can be from
within the same application domain or from different domain space. 
Line 2099 and Line 2281 - Federated identity management - the
applicability of the OASIS ebXML Registry federated management services
should be noted here including support for SAML. 
Line 2526 - Event driven reporting model with subscriptions and
implementation.  Again the OASIS ebXML Registry supports this use case
and should be mentioned here as related technology. 
Line 2865 - Key Management - this section contains no "Related
Technology" reference section.  It should be noted that the OASIS ebXML
Registry specification supports management of certificates - and can
therefore provide equivalent functionality here that can be re-used /
Line 3750 - Policy Management - Related Technology - the OASIS ebXML
Registry should be mentioned here as supported policy management with

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]