DAIS Session 2 - GGF 12 - 22/09/04 ================================== Chair: Dave Pearson Note taker: Mario Antonioletti 1. Representation Options for DAIS Functionalities using WS-Standards: Simon Laws 2. Discussion of Representation Options --- Dave Pearson introduces the second DAIS session. Have tried to frame the specification in such a way that it is independent of the underlying framework but at some point we have to map to a given framework. DAIS decided to do an investigation of the mapping framework. Simon will talk about this now. Simon Laws: For the slides see: http://forge.gridforum.org/projects/dais-wg/document/ggf12-dais-session2-mappings/en/1 When WSRF first came out we wanted to educate ourselves as to what it meant so we went through this exercise of producing a document to discuss how DAIS could map to WSRF as well as other infrastructures. Talked about some of this at GGF10 and it was discussed in more detail at GGF11. We now have to try to find a way of going forward. Objectives for doing this: - play nicely with OGSA. - Want to play as widely as possible though so have considered other approaches: basic WS-I, a WS-Context type approach as well as the WSRF approach. All different approaches for identifying the resources a service is going to interact with. A number of slides are given that highlight the differences between the different approaches. In WS-I have an abstract name for the resource, using the terminology introduced in OGSA v1.0 - although this is still an on-going process. Registry holds a mapping from the abstract name to the address of a service. The message is made up of a header and body and using a Web Service (WS) in pre-WSRF mode you introduce the identity of the resource you are interested in the body of the message to ensure you target the right resource. The result of the registry could be many services - the service can act on many resources and the resource name can be used as the discriminator. So, this is the explicit case where you are passing about the abstract name. That's what we thought was the WS-I approach. Another way of doing this was to use the WS-Context type approach where you use the header to provide the context in which the message operates in. In this same scenario there is some process where the resource that we are interested in is associated with the header of the message. The mechanism for doing this is not identified in the diagram. Slightly different way of doing the same thing. There is no explicit discriminator in this case. In the WSRF case the registry provides an End Point Reference (EPR) - the EPR tells us what the service end point we are going to interact with is and the resource properties that are going to act as the discriminator. When the call is made the SOAP message is formed with the resource properties in the header and delivered to the corresponding EPR. There is a subtle jump in that we are sending messages to specific resources. The EPR in reality can identify as many resources as it likes. Ian Robinson: I still think you are sending a message to a service in the same way as the previous example and not to an EPR. Savas Parastatidis: if you are sending the message to a service and not the resource how come you can't use the body of the message to target multiple resources? Ian: what the service does with the resource is up to itself. In the previous example you don't have something that targets a single resource. From the consumer point of view they see it as a single resource. Dave: are you saying that in the two example what goes down the wire is the same? Ian: what goes under the wire could be the same. The semantics are the same ... ... Have achieved the same thing using different approaches. Since this work was done there are some new kids in the block which may be relevant. These are: - WS-Transfer and [http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-transfer.pdf] - WS-Enumeration [http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-enumeration.pdf] Savas will describe what these are: WS-Transfer: is a simple specification from MS and partners to define 4 verbs for SOAP message interactions with specific semantics. These are: - Create - Destroy - Update - Get These all operate on resources. Follows the same principles as REST. Use only a limited number of verbs to construct an architecture. Similar to http but with different semantics. What you do not get are schema information about the resources. Norman: in WSRF you define your own messages to interact with the resource. Can you define additional messages in WS-Transfer? Savas: you could but this is not specified in this standard. The resource is identified in the same resource ... people will not get additional operations. With WSRF you can define additional portTypes and target the resource. Ian: in both cases you would the operation name to the original portType that you are using. Savas: in WS-Transfer you would not associate additional operations with that portType. It does not give you anything else other than XML. In http you do a GET from a URI ... it is still the case that it is resource focused. If you build on WS-Transfer you operate on resource and not a representation of resources ... have only read it once so I could have it wrong ... Don Box does not expect people to define additional portTypes when you build applications. Scott Oster: do they expect to do service composition? services built on other services? Seems more fragile ... Savas: because you don't define anything you do not put any restrictions on what you can do and that's where the loose coupling comes from ... currently you are expecting a lot from services.... have not seen any examples of how they think that it is going to be used ... this spec is 3 days old. WS-Enumeration builds something like a remote cursor ... defines the message exchanges to be used to iterate through data. The idea is that you have a large piece of data at the service and that you don't want to pull it all back ... it's a pull model. The service has to produce some state about you and there has to be some life time management so there is a lease concept ... Scott: is there a peer enumeration type of operation? Savas: there is only a pull... Brian Collins: in an example they have they have an analogy with web row set or that is what it implies. Simon: which may have a direct impact on rowset stuff. Norman Paton: we took a different approach ... the difficulty this would produce is that we would have to wait for it to be standardised ... ... Dave Berry: what's the status? Savas: 4 days old ... waving in the air to demark territory... Simon: have to try and finish these specs off but the length of time to get submitted and ratified is not going to impact on it directly first time round but we should keep an eye on this ... Norman: the specs have certain extensibility hooks ... could these new specs be used without making major changes to these specs ... ... Regarding DAIS and naming - this has been discussed in the previous session as well as various other sessions. We are relying on OGSA to select a naming scheme. We need to be able to feedback our requirements, e.g. human friendly abstract names ... there is still some debate about what an EPR is ... is it an address or a name? ... if an EPR is thought of as an abstract name then that gives us a problem as we have no control on what it contains as it is opaque. ... we have to understand that issue before we make assumptions that do not turn out to be true. In the approaches we either: - Use abstract names explicitly where we name the resource or - We do it implicitly through a registry and then don't deal with the abstract name. Comparing approaches - all the approaches work and seem similar until you map the abstract name ... it seems that in this world there will never be one solution and there will always be space for all these variants. Currently we do not have a strong feeling as to which of these approaches is best. We have now educated ourselves and can only make a statement in the context of DAIS. Which approach should we take? Norman: ... and you cannot build two interoperable implementations if you take more than one approach. Do we have to make a choice? Especially difficult with incomplete knowledge. We could: - Put discriminators in the body and make them optional. - May be able to play tricks with the WSDL. - The WSRF TC is looking at different embodiments of the WS-Resource Access Pattern, a document is being prepared that discusses this which I have not seen yet. Examines the singleton resource pattern, ... - Maybe we want to leverage the differences ... use a WSRF representation for a database on which you can run SQL expressions ... in the case where we use the factory pattern to read the data from a data resource and present the results as a new service we can use WSRF to represent the results as a resource but you can subsequently obtain separate result sets ... a query could give me the Nth result set ... a combination of both patterns is being used here... result sets are not represented as different WSRFs ... used both approaches to manage the resulting result sets . Ultimately the consumer of the service has to know what to do. The discriminators have to be there in some capacity. The options for DAIS are: - support no mappings, probably not an option ... unless we want to wait, - Support one mapping, currently WSRF but could change. - Support many mappings, repeat the WSDL but in different ways. Would have to maintain different mappings. Savas: support one mapping ... WSRF is compatible with OGSA at the moment but it is not the case that it is supported by the remainder of the WS world. It can be optional ... if an application does not use WS-RF why is that not OGSA compatible? In another WG they were told specifically that they could not be in OGSA unless they used WSRF explicitly ... I did not know that they had mandated it. It's an interesting question. Dave Berry: OGSA has adopted WSRF - all the management stuff is built on this. Want resources to be managed by WSRF. Not sure what that means for the individual specs ... it might also depend on who said that ... Savas: Hiro ... Dave Pearson: This is something that we need to clarify ... Dave Berry: there is certainly an expectation ... Dave P: It appear that there are no advantages/disadvantages to any of these examples. Simon: We do not have any quantifiable way of evaluating the differences as yet ... there is no obvious right solution but we still need to get a spec out. Dave P: we have been going for a long time and we cannot expect to go on for ever ... be useful to get feedback on this. Comments? Dave B: the previous OGSA session discussed secure names ... some of the options that they are looking at allow names to act as a verifiable identity ... that is not necessarily a nice name ... there is legion... they all talked about Handle which is used in the library community, dspace, which is another name ... currently trying to change the licencing terms to make it easier to use ... still very much an open question ... trying to see where WS names are going ... Simon: it depends on what approach we take ... depends on dependencies on other specs ... we are not in a position where these things are sorted. Dave B: another issue there is an assumption that the EPR can refer to a URI ... Savas: so the resource information should be encoded in the URI? Dave B no, does not have to be a protocol specific thing. The name does not have to be unique for all time ... anyone can take a name while EPRs have to be unique for all time ... Savas: is the naming scheme supposed to be global? Dave B: I think that is the intention.. Savas: ... nobody will ever agree to a global naming scheme. Norman: we have a WSRF mapping ... GGF has a view to use WSRF ... the presence of the singleton resource pattern would be useful but what I'd like to explore is the motivation for more than one mapping. Two options that relevant is where you have a pre-existing naming scheme: could create a mapping to WSRF but you may not want to that. If you are building a service based interface into an organisation that has a lot of RDBMS, e.g. Oracle, that already has a single access point. You may wish to pass one of the Oracle names rather than go through a registry that would do the WSRF to Oracle-naming scheme. This is why it might be useful to have an optional additional parameter in the body of the message while you might also have the WSRF resource properties in the header ... this would require a change to the DAIS operations ... would also require this from WSRF for our metadata ... would be interested to have comments on this approach? ... Ian: one of the things that has been done in WSRF that originated from one of the DAIS requirements is that it is alright to pass ids in the body of the message ... however when you want to perform an operation on a resource then the id also has to be passed [in the header]. As this is constructed at run-time you can do whatever you like in the EPRs ... the client understands that there is a reference to WSRF which is the EPR and understands the operation signature but the client can also include the resource id in the body. When you are sending the getResourceProperties message if you have the resource in the header then that will also work ... you know what the resource is, you know the name of the resource is ... Norman: this is the point ... (goes to the board) sqlExecute( ExistingName, Query) ------> Service Uses the name to look up at the database. What happens to the messages that we do not have control over. Have a: getResourceProperty(logicalSchema) Want to get this to act on the ExistingName of the database. Ian: the solution to the problem is that there needs to be an EPR for the thing that you are sending it to ... Norman: but that is to the service and not the resource ... Ian: what you need to be able to do to avoid passing the getResourceProperties you need to get the EPR from the name of the resource. Norman: have lots of resource with these names and have a registry with the pre-existing name ... could create a mapping between the existing names and EPR but suppose you do not want to do this as an additional mapping ... if you are a DAIS person this is not a problem as you own the WSDL but you cannot do this with the WS-ResourceProperties .... one solution might be that a service only represents one resource and then you can use the singleton resource pattern but if you want to have symmetry you want an additional optional parameter in the getResourceProperties that indicates the name of the resource ... ... Dave B.: ... the service could return the EPR... ... Ian: there are 2 ways to address the problem ... you observe that there is an asymmetry ... but there is that already in the way that you have written the operations. You have done this in the way that you did the original operation ... you could have a resource property document where each of the resource properties in the WSRF represent each of the databases - have only one WS-Resource that represents the state of all the resource.... Susan: ... very impractical ... Ian: the second solution observes that given a database for which you want to use a single WS-Resource you would have to create a WS-Resource for that given name. One of the other embodiments is to use the WS-MessageDelivery (WS-MD) from W3C - only using this as an example - this has a URI address but it does not have a notion of resource properties ... you need to be able to specify a reference about the thing that you are talking about in WS-MD, you wrap the name and the URI ... there is no hang-up about the opacity of the reference ... you could have WS-ResourcePattern which could contain a URI of the resource and the name of that resource ... so in order to specify an interoperable using an embodiment of the WS-REsourcePattern you need to specify the embodiment of how that looks on the wire and what you are referencing ... you can put what you are addressing anywhere ... could define a WS-ResourceAccess pattern that you could encode in the message ... [http://www.w3.org/Submission/2004/SUBM-ws-messagedelivery-20040426/] Susan: could not do that with multiple end-point resources ... ... Savas: ... this is what we have always been saying if you break the association between the EPR and the thing behind the service and allow for the resource id to be in the body of the message you can do all the advanced things or only one ... Ian: the important thing is that, as is the case when using WS-Addressing, ... the service understands how you consume the messages ... if you passed an embodiment of the resource in the body then it would be up to the service to use that as required. I would rather you put that in the header though ... ... Savas: you could define the message interactions for the id of the resource to be in the body ... Ian: but this is not something that we have decided ... Dave P.: your second option is still on a one-to-one ... ... Scott: could you not make a 2-phase parameter in DAIS and do the magic? Norman: that is an idea ... Savas: that is the semantics of that database interface is that if you want to get the properties send me a message of this form and I'll send you a message back. Dave B.: what is the interface of the service? Norman: not sure what your questions. .... Peter Ziu: in JDBC I would have a handle ... had an instance of the class connection. You have a singleton resource pattern the client contains no state? Norman: the sessions are represented differently ... DAIS is silent on this as there may be a transaction context in the header ... Peter: from the result set you get the schema ... the object result handle you should still have the handle ... Norman: the problem here is not to be the logical schema ... this is just an example. Ian: would like to think of the EPR as a JDBC connection ... server side state ... Susan: but it also carries the transaction state .... Peter: would have a pooled connection - in one step you are executing the query and sending the message back ... Norman: it would be a one shot .. Greg: curious to me - either WSRF can talk to multiple resource or it cannot in which case we should stay away from it Norman: WSRF does support more than resource one and the push for doing this is multiple names ... Greg: getResourceProperties should operate on any service so it's not up to us to change that operation otherwise you would have to know that you are talking to a DAIS service so either WSRF gives us a strategy or not ... Norman: that is a clear way of having a one-to-one mapping between a service and a data resource ... Dave B.: why does the following model does not work? Cannot you have a separate service that does the mapping between name and EPR? Norman: you can. Dave B: it's a local mapping .. Norman: instead of saying that you don't implement that mapping and have an operation that returns an EPR could be a viable option. Savas: if the service knows the connection between the name and the resource why do you have to do the multiple message exchanges? Peter: the difference between instance and class? Is the EPR the instance? (yes) Savas: it is this coupling to what is behind the service - WSRF gives you a way to talk to only one thing but then that limits your ability to talk to multiple EPRs ... if you created 1000 EPRs then you would have to do that using 1000 messages and then you would have to talk to each one to destroy them. If you had one name then you could send one name to the service to destroy all those EPRs. If you have a mechanism why introduce another mechanism? Peter: you reduce the number of interfaces .... Savas: the collection solution is not a solution to a problem that did not exist before Ian: but you don't have to create an EPR for each resource ... Simon: At some point we have to do something but it is clear .. Ian: what would really help is the WS-Resource embodiments document that the WSRF TC is producing ... hope to have this available in about 2 weeks ... provides alternatives to using WS-Addressing ... that do not rely on opaque properties ... ... Savas: if it isn't in the header ... you contextualise the scope of the message by adding some additional information which is not coupled with the service ... even Oracle would be happy with that ... Dave P: so it seems that we may have a solution ... should wait 2 weeks for this document to be externalised and DAIS should provide some feedback. Simon: we could maybe redraw the diagrams with this new input. --- Possible DAIS Options are: -------------------------- 1. Resource properties copy their own names. 2. Package operation using WS-MessageDelivery. 3. DAIS specific analogues for WS-ResourceProperties. 4. Map to WSRF EPR when required.