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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep 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 priority?
 
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
 
 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 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 components?
 
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 view(s).
 
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 / extended.
 
Line 3750 - Policy Management - Related Technology - the OASIS ebXML Registry should be mentioned here as supported policy management with XACML.
 
 
 
 
 
 
 
 
 
 


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