Re: Intermediary Text

Hi Mike,

Thanks for your time reviewing my comments. I essentially agree with 
your response. Additional information below.

Jean-Jacques.

michael.mahan@nokia.com wrote:

> Jean-Jacques,
> 
> Thanks for the comments. A few notes:
> 
> - The intermediary text will be inserted at different points in the 
> spec document. So the ordering of the text in the email was adhoc
> rather than intentional. Sorry for the confusion this caused - this
> should have been explicit in the intro..

OK; I'm sorry I hadn't realized this.

> - Your points about leading off the list of intermediaries with
> gateways, along with classifying gateways as intermediaries at all is
> well taken. I think either removing the text or saying what gateways
> are and what they are not is the correct action. Another comment on
> this towards the end.

OK.

> - I think that 'forwarding intermediary' is redundant. If a
> intermediary is not 'forwarding' the message, then it is by
> definition the ultimate receiver. Furthermore, 'active
> intermediaries' are a specialization of forwarding intemediaries,
> rather than being mutally independent. Thus I find that the
> qualification 'forwarding' is of low value. That said, I do realize
> the value of staying consistent with the 1.2 spec though.

Yes, this was my point, really. As a reader, I had the impression you 
were describing intermediaries from a SOAP 1.2 perspective -although not 
quite-, hence the importance of reusing existing terminology, even 
though I agree it could be improved.

> - It seems that SOAP 1.2 active intermediaries may even act on the 
> message body - not just 'untargeted' headers. However, my
> understanding may be erroneous, and is based on the text in the
> active intermediaries section:

Yes, you are right, an intermediary cannot act as an ultimateReceiver 
(i.e. cannot process the SOAP body), but it can modify the SOAP body. 
This is clearly stated in the resolution for Last Call issue 335 [1] 
(had to dig that one out!).

[1] <http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html#x335>

> "The potential set of services provided by an active SOAP
> intermediary includes, but is not limited to: security services,
> annotation services, and content manipulation services."
> 
> For instance, if a SOAP processor encrpts a SOAP message body and
> relays the encrypted message to another processor, is it an active
> intermediary, or no longer an intermediary by definition (thou shall
> not touch the message body...)? Would it then be an ultimate receiver
> who just so happened to relay the contained infoset to another SOAP
> processor?
> 
> - I think functional and optimizing is a different dimension than 
> forwarding and active. This categorization was harvested from a
> source that predated SOAP 1.2 spec. I think our text can better
> support both categorizations and dig into clarifying the space with
> some examples. The WSA editors have an AI to do this.

OK. I think it would be worth indicating you are using a different 
dimension, so as to clearly show the differentiation from SOAP.

> - I will have to revisit my notes on store/forward, partial
> messaging, and aggregation. I had thought that these were not
> gateways, but I shall have to do some extra research before
> re-establishing a position. I agree that orchestrator is a gateway
> pattern rather than an intermediary.

OK.

> - Note: I wonder if it would add value to the arch spec if it also
> iterated these valid system patterns even though they are strictly
> not SOAP intermediaries? I think no is a valid answer here, but it
> would be helpful to our audience to describe common system
> architectural patterns used in the deployment of web services
> (gateways, proxies, composing gateways, workflow). Anyways, this
> feels like valuable system arch work.

Yes, I think it does add value, as long as we can clearly separate SOAP 
type intermediaries from other types of intermediaries or gateways.

> - SOAP 1.2 says: "While SOAP does not itself define any routing or
> forwarding semantics, it is anticipated that such functionality can
> be described as one or more SOAP features". Question: has the WSD
> group discussed how these features could be described by WSDL?

The WSDL 1.2 spec now has syntax for describing (SOAP) features. The 
syntax simply consist in writing down the URI of the feature that is 
supported or required by the service.

 > Is
> WS-Routing the only attempt at defining explicit routing or
> forwarding semantics? It seems like WS-Addressing does define 'next 
> hop' forwarding semantics, but that is all. Maybe that is all that is
> needed.

My understanding is that WS-Addressing is essentially a URI with 
additional (meta-) data. In itself, I don't think it allows describing 
complete SOAP message path, as WS-Routing did.

> r, MikeM
> 
> 
> 
> 
>> -----Original Message----- From: ext Jean-Jacques Moreau
>> [mailto:jean-jacques.moreau@crf.canon.fr] Sent: September 26, 2003
>> 06:15 AM To: Mahan Michael (NRC/Boston) Cc: www-ws-arch@w3.org 
>> Subject: Re: Intermediary Text
>> 
>> 
>> Hi Mike,
>> 
>> Excellent categorization! It will certainly help people understand
>>  intermediaries. Comments interspersed below.
>> 
>> Jean-Jacques.
>> 
>> michael.mahan@nokia.com wrote:
>> 
>> 
>>> MikeM and MikeC have come up with the following text on 
>>> intermediaries for consideration in today's agenda....
>>> 
>>> 
>>> 
>>> BACKGROUND/MOTIVATION
>>> 
>>> [Ed Note: Some history on the role of intermediaries in the
>>> evolution of the SOAP spec would be helpful.]
>>> 
>>> Intermediaries are a relatively poorly understood component of
>>> the Web services architecture.  One often hears the critique that
>>> SOAP offers little value over XML messages exchanged via HTTP.
>>> This ignores the role of intermediaries in the SOAP processing
>>> model to provide additional services to enhance the security,
>>> reliability, scalability, etc. of a services infrastructure
>>> without requiring modifications to the ultimate Web service being
>>> provided or the application requesting the service.
>>> 
>>> In fact, the emerging SOAP-aware networking infrastructure
>>> products such as firewalls, routers, ... are examples of Web
>>> service intermediaries.
>>> 
>>> Intermediaries also support Web services applications that are 
>>> designed as asynchronous processing pipelines rather than
>>> synchronous remote procedure calls.In this model, a sequence of
>>> intermediaries act as filters, and supply the pipes that direct
>>> the flow of data, much as in the classic Unix tool model.
>>> 
>>> In the Web services context, the intermediaries are active agents
>>>  that can act on the messages they transport.
>> 
>> Yes, as per your ednote, I wonder as well if we need to qualify the
>> word agent with "active".
>> 
>> 
>>> An active intermediary reliably stores and forwards messages from
>>> one Web service to another.
>> 
>> The adjectif "active" is more problematic here. SOAP defines to
>> types of intermediaries: forwarding intermediaries[1] and active[2]
>>  intermediaries. Forwarding intermediaries are intermediaries that
>> obey the rules, i.e. they process only the header blocks targeted
>> to them. Active intermediaries are the bad guys; they also process
>>  header blocks *not* targeted to them (and worse, they may not even
>> tell you what processing they've performed, although the spec
>> strongly encourages them to do so). This is the only difference
>> between the two types of intermediaries. In view of this, I think
>> you should remove the word "active" above.
>> 
>> [1] <http://www.w3.org/TR/soap12-part1/#forwardinter> [2]
>> <http://www.w3.org/TR/soap12-part1/#activeinter>
>> 
>>> Along the way, it can filter, transform, log, and analyze the
>>> message flow.
>>> 
>>> <Ed Note - why qualify the word agent with 'active' above? I
>>> admit getting somewhat confused by the SOAP 1.2 primer
>>> distinction between active and forwarding intermediaries - and
>>> the below distinction between func. and optimizing>
>>> 
>>> Intermediaries can be categorized as being either functional or 
>>> optimizing.
>> 
>> I think you need to be careful with the terminology here. Whilst I
>> don't disagree with your possible caracterization, I think we need
>> to be explicit this is new (albeit valid) terminology, i.e.
>> terminology not present in the SOAP 1.2 spec. SOAP 1.2 only talks
>> about forwarding and active intermediaries, not functional or
>> optimizing intermediaries.
>> 
>> 
>>> Functional intermediaries provide some functional processing that
>>> is required for the application to work. Optimizing 
>>> intermediaries enhances application yet are not required to exist
>>> for application to work. Optimizing intermediaries can often be 
>>> introduced at runtime rather than at design time - a significant 
>>> capability to enable a provider to 'tune' the service 
>>> post-deployment. Optimizing intermediaries typically enhance 
>>> scalability, reliability, or perceived performance of the
>>> provided service.
>>> 
>>> Intermediaries are often arranged in common configurations, or 
>>> deployment patterns, in order to address a technical or business 
>>> problem. Common deployment patterns of Web services
>>> intermediaries include:
>>> 
>>> - Gateways. These are intermediaries deployed by which reside at
>>> the trust boundary of web services provider. Gateways enable an 
>>> enterprise to provide a single point of contact to all requesters
>>>  outside its trust domain for all the Web services that it hosts.
>>>  Gateways may implement some business logic such as
>>> authentication, authorization and privacy handling. Gateways can
>>> assume the role of ultimate receiver of the message, or can be a
>>> true intermediary. - Proxies/Adapters. These are intermediaries
>>> which assume the roles of requester and provider respectively, in
>>> order to enable legacy systems to participate in a web services
>>> application. (These are not intermediaries in the strict sense of
>>> the SOAP processing model).
>> 
>> Yes, gateways are not SOAP intermediaries (there was a discussion 
>> earlier on this list; see for example [3]). So it's a bit odd to
>> start with an introduction on intermediaries and then expand to
>> non-SOAP intermediaries, apparently only for this paragraph. Maybe
>> it should be dropped entirely, or at least be toned down and come
>> last?
>> 
>> [3]
>> <http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0180.html>
>> 
>> 
>>> - Router. A Web service message can follow a particular
>> 
>> "path" through
>> 
>>> an arbitrary number of intermediaries where each Web service 
>>> intermediaries would provide a value-added services to the
>>> message and hence to the application. Note that for a
>>> request-response MEP, the message may traverse through different
>>> intermediaries on it request and response paths. Routing
>>> intermediaries could belong to the trust domain of the requester,
>>> the provider, or some third party.
>> 
>> Maybe add a link to WS-Routing?
>> 
>> 
>>> - Dispatchers. These intermediaries allows a Web service request 
>>> message to be routed to one of several instances of a Web service
>>>  provider based on some "filter" criteria applied to the
>>> message's contents/data. The dispatcher typically belongs to the
>>> trust domain of the web services provider. Dispatchers may
>>> perform some form of "load sharing" or "data partitioning" so
>>> that requests for a particular Web service may be filtered on the
>>> presence and/or value of certain data elements in a request and
>>> diverted to an appropriate provider that hosts the resource to
>>> which the data in question is relevant. Dispatching
>>> intermediaries may be used to filter Web service messages on
>>> namespaces used within the message and direct requests for
>>> different versions of an interface to the appropriate 
>>> implementation. - Orchestrator/Composition. This intermediary
>>> offers a composite service interface built from the coordination
>>> of a set of individual Web services. Requesters see the composed
>>> service, not the component services. (This probably is not a SOAP
>>> intermediary - but represents more of a deployment pattern)
>> 
>> Yes, it's not an intermediary, as it looks like the message path
>> for the incoming message would terminate at the orchestrator, and a
>> new, separate SOAP would be sent by the orchestrator to the node 
>> effectively providing the service.
>> 
>> 
>>> Some of the implementation techniques of optimizing
>>> intermediaries are:
>>> 
>>> - Caching. Reuse responses from previous information requests. 
>>> Caching intermediaries should occur in network where there is 
>>> economic balance between # of requesters and localized requests. 
>>> - Store-and-Forward. For large or frequent transfers where acks
>>> are required but are not functional
>> 
>> Again, is this really a SOAP intermediary, or a gateway, as per the
>>  distinction in [3]?
>> 
>> 
>>> - Partial Messaging. Only part of a message should be sent --
>>> where there are to be changes to a cache.
>> 
>> This would be an active SOAP intermediary, if it omits from the
>> outbound message header blocks targeted to a node other than
>> itself. Your description is a little short, though, and I may have
>> misundertstood.
>> 
>> 
>>> - Aggregation. Exploits locality in multiple incoming
>> 
>> messages, to one
>> 
>>> single message. Messages should has a common endpoint - or at
>>> least one. (not sure about this one).
>> 
>> This also looks like a gateway, not a SOAP intermediary.
>> 
>> 
>>> CONCEPT
>>> 
>>> Web services intermediary is an entity positioned anywhere within
>>> a Web services message path that performs a value-added function
>>> on behalf of the initial message sender, the ultimate message
>>> receiver, or both
>>> 
>>> A Web service intermediary is a software agent acts as a node in 
>>> message path that performs a SERVICE on behalf of the message
>>> sender, receiver, or both. An intermediary acts as both a message
>>> SENDER and RECEIVER. Intermediaries may work with information in
>>> message bodies and / or message headers, and can add or remove
>>> headers as appropriate.
>>> 
>>> 
>>> RELATIONSHIPS
>>> 
>>> An INTERMEDIARY IS-A SOAP PROCESSING NODE [not sure if that is
>>> one of our concepts!]. An INTERMEDIARY is explicitly targeted by
>>> a MESSAGE.
>>> 
>>> An INTERMEDIARY optionally adds or removes MESSAGE HEADERS
>>> 
>>> A SERVICE PROVIDER MAY use one or more INTERMEDIARIES to
>>> partition a SERVICE across multiple NODES and/or to provide
>>> additional services that are transparent to the SERVICE
>>> REQUESTER.
>>> 
>>> A SERVICE PROVIDER MAY use one or more INTERMEDIARIES to provide 
>>> POLICY enforcement.
>>> 
>>> 
>>> 
>>> DISCUSSION
>>> 
>>> includes entities ranging from software applications and network 
>>> appliances that function as part of an organization's physical 
>>> messaging infrastructure through third party Web services
>>> networks, traditional VANs, carriers and vertical hubs. The
>>> concept of an insourced intermediary platform under the control
>>> of the benefactor is rapidly becoming a popular method for
>>> managing and enriching a service-oriented architecture.
>>> 
>>> 
>>> [Ed Note: Intermediaries can provide trust functionality .. ]
>>> 
>>> 
>>> <Ed Note: I think we should remove the below para ... or beef it
>>> up, but I am sure where to take it...>
>> 
>> Agree.
>> 
>> 
>>> Intermediary hubs are increasingly becoming useful sources of 
>>> business intelligence both in terms of business activities and 
>>> service quality.
>> 
>>

Received on Monday, 29 September 2003 04:28:58 UTC