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: RE: [fwsi-comment] Public Comment



Greetings James, we thank you for your feedback.

Please see our comments:

Regarding Specification:  FWSI Functional Elements Specification v1.0

The scope of this specification appears to be limited to 'data provision' services.  That is, services where data is made available to clients that wish to receive that data.

[Response:] Services in general are about exchange of information/data, be it transactional, status or pure notifications. In essense, yes it is about data. However if you take a closer look at some of the FEs specified, like user mgmt, group mgmt, role&access mgmt for example, you will realise that it is also about mgmt and handling of information. Other examples like that of identity mgmt, handles the mgmt of identities of users across different applications. When the TC initiated the specifications, we use the 80-20 rule of what a typical application will need, and hence, yes it is data bias somewhat.



I am a newcomer to the work of this TC, but it seems (imho) that this specification should also address delivery of 'command & control' services.  That is, services which enable clients to submit data or commands to a third system.  In a sense, the service acts as a proxy
for the 'commanded' or 'controlled' system.

This type of service seems to be the natural complement to a 'data provider' service in that it allows data to flow in the opposite direction.
Is this on the agenda for this TC at some point?


[Response:] You are right, this is our first version. The TC is currently looking into several other services; one of them that we are working on for the next FE Specification V2.0 (to be completed in November 2005) is the "Service Router" FE. In this FE, the TC is looking at defining how a service can act as a proxy, middle-man or even fašade to other services, with the ability to configure any pre & post processing events. For example, the Service Router can act as a fašade to a set of actual services (hiding the actual location of diverse/sensitive services) and filter invocations accordingly, based on set pre & post-processing activities. Such activities could include security requirements like encryption/decryption & authentication for example.


Regards,
Eng Wah Lee
Co-chair FWSI TC





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