[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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" <pstan@SIMTech.a-star.edu.sg> Date: Tue, September 05, 2006 1:11 am To: <david@drrw.info> Cc: <fwsi-comment@lists.oasis-open.org>, <fwsi@lists.oasis-open.org> 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\)" <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? 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]