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:57:22 -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?
[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 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?
[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 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.
[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 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.
[A] Pls see answer above.
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?
[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, 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?
[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 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.
[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? 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.
[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 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.
[A] Noted, pls see earlier answer
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.
[A] Noted, pls see earlier answer
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.
[A] Noted, pls see earlier answer
Line 3750 - Policy Management - Related Technology - the OASIS ebXML
Registry should be mentioned here as supported policy management with
XACML.
[A] Noted, pls see earlier answer