regrep message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Comments on committee draft - FWSI
- From: "David RR Webber \(XML\)" <david@drrw.info>
- To: fwsi-comment@lists.oasis-open.org
- Date: Thu, 27 Jul 2006 09:55:24 -0700
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
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]