DAIS Session 4 - GGF 11 - 09/06/04 ================================== Chair: Norman Paton Note taker: Mario Antonioletti Agenda for this meeting: 1. Representing DAIS Functionalities using Emerging WS-Standards: Savas Parastatidis (60 minutes) 2. Panel to Discuss Informational Document (30 minutes) Savas Parastatidis, Sastry Malladi, Susan Malaika ---- Norman introduces the session. Had a mappings presentation at a DAIS session at the last GGF. This has been written up as a document that has been presented at this GGF. 1. Representing DAIS Functionalities using Emerging WS-Standards: Savas Parastatidis Presentation at: http://forge.gridforum.org/projects/dais-wg/document/GGF11-DAIS4-Mappings/en/2 Document this is based on is at: http://forge.gridforum.org/projects/dais-wg/document/draft-ggf-dais-mappings-ggf11/en/1 It has been a pleasure to work with the collaborators. (Sastry agrees) Will follow the structure of the document and will not necessarily express my own opinions. Have taken the DAIS concepts and tried to map them to different infrastructures. Have tried to identify the interactions. Will cover the stuff presented by Simon at GGF10 quickly to have more time to discuss the other scenarios. Want to see how data resources are identified ... (other goals are made in the slides) There are five scenarios. Only covered the first scenario at GGF10. Will go through this scenario quite fast. Have not had time to create figures for third-party delivery but it is straightforward to outline this scenario. Infrastructures that are going to be addressed are: - WS-I set of specs only - WS-I + WS-Context - WS-I + WSRF The classification of terms has changed since the last presentation for clarify. Scenario 1. Query goes to a service, a dataset is produced to represent the data, this is named using a urn - the urn is returned to the user. Tom Maguire: how did you know that the table is available? There has to be a connection between the user and the table and you do not express this relationship ... the granularity of the data resource. The presumption is that there is an end point for every database. No, there is an end point that could represent many databases. The selection could take place in the query. Sastry Malladi: how the consumer discovered is out of scope for this scenario. What you get back normally is the result but in many circumstances this might be too large so in this case you return a name for the data set produced. Stateful interactions using WS-I are managed by expressing the name of the data resource in the body of the message. If you have multiple services you can still use the same name (how the replication is done is out of scope for this scenario). Using WS-Context ... somehow some context is generated - how this happens is out of scope for this scenario - when you start an interaction with a service the context is included in the header of the message. Some infrastructure at the service end extracts the context and associates this with a local data resource - same as previously - the response does not include the pointer to the data resource in the body of the message. You could then pass another message to operate on that same data resource - the data resource is identified in the header. Similarly the same process operates where you have multiple resource. Charlie Little: the name can be associated with multiple resources? Yes - the context is not necessarily an explicit identifier for a data resource. Sastry: the context can be mapped to an explicit resource by some server specific logic. You can combine the first two scenarios associate a data set by name and/or by the context passed in the resource. Context works best when you have multiple users. ... In WSRF you get an End Point Reference (EPR) as the response to a query. The reference properties are specific to the service that produced the EPR. The reference properties are passed between subsequent message exchanges. The data set is now included in the header and the end point of the message is not the service but the EPR. Susan Malaika: you can't send the EPR to another service? You are not allowed to take the EPR and use it to interface to the same service. Guy Rixon: you can use the factory pattern for the first service to create a reference for you to the second service Susan: why can't you pass the EPR to the second service ...? You could do it but you would require an intermediate service to contact the first service.... you can tell the second service that that is the data resource and the second service can replicate the data and create a new EPR for that service. ... Tom: the single address as a physical end point is a misreading of WS-Addressing the address in the end point does not have to be a physical address... The address does not have to be a protocol specific address.... Tom: and this could be bound to many different addresses. But that assumes that it is the same logical service... ... The multiple service interaction could be expressed using WSRF. Scenario 1: could be expressed in wsrf. ... Norman Paton: the client could be informed that the data is being replicated and this could be done using WSRF. Susan: The replication could have been done by the second service by sending the EPR of the first service to the second service. This scenario was supposed to capture issues relating to identity ... Tom: I would not call that identity I would call it a name ... ... because you can have multiple "name"s for the same resource. Scenario 2: Sessions Cannot call the state being held in relation to a data resource as a session. The session is with the service not the data resource. With WS-I you create a session by using the factory pattern. The session could be taken to mean that all messages for that session will be logged. Every time you have an interaction with that service you have to use the session identifier. For the WS-I only case this is now included in the body of the message. Have made the assumption the entire result is returned in this example. At some point you may want to end the session. When you create a session you can include a timeout so that the session can automatically be destroyed otherwise you can end the session by using an explicit endSession message. In the context approach you could have a context service that maintains the context or you have a workflow process that creates the context. Because the service is aware of the context it can log the context. If you assume that a context service does not exist the you can send a createSession message to a service. Allen Luniewski: did not see where the session is? The context is used to create the session Allen: where does the context begin and where does it end... It could be done in the same way as with transactions ... the service receives a message that it is contextualised and if the service does not already have any information about that context it creates a new context. What the service dose it up to the service Sastry: this is not shown in the picture ... it could be done in many ways. Allen: that is confusing ... it should be shown.. Sastry: maybe that's why you (to Savas) should show your previous slide first. ... Once the context is created. Allen: the session and the context is semantically synonymous. Tom: the context in this case is capable of creating the context and handling the service ... it exposes a message pattern for creating the context .... the end point is representing a message pattern to create a service ... yes Sastry: in the previous service it was assumed that a different service was creating a session in this picture a message is being used to allow the service to create the context ... this could be done with a context service. ... In all these pictures a context is being used such as the one shown in the slide (see slide 29) Sastry: the address of the context service and the identifier ...can list all participating services ... structure here corresponds to the WS-Context specification. Tom: do you have an example that uses WS-Coordination? No, WS-Coordination has additional semantics that are not required here. Sastry: the composability is missing here ..... WSRF is very simple. It is not used for modelling sessions. If you want to model sessions you should use WS-I or WS-Context. ... Spent a lot of time trying to model sessions using WSRF ... Tom: you use contextualisation of messages. WSRF is used for representing resources. A context service could use WSRF to manage the context. Sastry: the complexity is because the end point represents a WSRF EPR ... there is no way of representing the context in a single message but you could have a service that represents the context as a resource. In the conceptual model the main recipient of a message is the resource you cannot put ... Tom: there are local actors on the message but you can only have one receiver. The message is addressed to one EPR. Multiple actors can act on that context. Scenario 3 - Discovery Using WS-I assume have a registry ... query the registry that returns metadata that returns information about services and policy. Do a "get" on a registry for a particular name of a data resource and get metadata about that data resource. Allen: this does not look like discovery ... it looks like querying for metadata for a known resource You could change the name in the example with an XPath query... Allen: so the name would be returned as well as the metadata ... exactly nothing specific in WS-Context. In WSRF it is exactly the same and you get an EPR returned. Scenario 4: access to metadata In WS-I can ask for the schema of a table by name ... assume in this instance that the metadata is the table schema. ... No difference when using WS-Context. With WSRF you use the resource properties ... you identify the resource in the header and do a getResourcePropertiesRequest which names the required property and you get back the metadata. Norman: when using the WS-Context could you not send in a message and the stuff that you get depends on the context that you are in. but that does not change the stuff that you get back. It changes the scope... you could use context to identify who you are which in turn determines the metadata that you get back. That type of interaction falls into the sessions scenario. Norman: getting slightly tripped up because you are passing an explicit identifier which is not passed in the context ... Scenario 5: 3rd party delivery. In WS-I you ask a query to be run and the results are passed to a third party. You specify the delivery end point explicitly. Norman: you have described push 3rd party delivery but you could use a pull mechanism or deferred delivery instead that is an issue of identity .. how you name the results ... you specify the name of the data resource, the operation and the delivery address... With WSRF you would only express the EPR to the delivery point. ... Observations/Issues (these are all in the paper) Things to consider when choosing an approach - stability of the supporting infrastructure - interoperability and adoption - composability for instance with WSRF you cannot use BPEL - tooling - conceptual model and the differences to the approach. We do not have any conclusions as we were not given that task. ---- 2. Panel to Discuss Informational Document (30 minutes) Savas Parastatidis, Sastry Malladi, Susan Malaika/Tom Maguire Norman: as a group we can draw general approach but as a group we also need to draw some specific conclusions as to what the DAIS specs are going to use. Now move over to the panel session and open up to questions from the floor. Savas: can I show a different scenario where I can take my neutral hat off? Norman: no. Sastry: (to the audience) was the idea clear about how the different scenarios work why would use one or the other? Tom: and not a combination ... Steve Newhouse: you did not lose any functionality when adopting any of the infrastructures for these scenarios. Sastry: but there are issues as to how you extend these scenarios ... Steve: if I was a user I could do exactly the same things using any of the infrastructures ... Sastry: in most cases .... however you could not use WSRF to model sessions although you could use a combination of approaches to do this Norman: so if the difference are not functional what are the advantages ... Sastry: if you want to model a session that could easily be done using WS-Context ... if you are using WSRF then you can model context as a resource but what is the associated cost of doing it that way? Norman: why would you want to use context? Sastry: you want to begin a conversation with a service then you, as a consumer, only want to pass a context back and forward ... you could do that yourself but it would be better if that was done for you... Norman: Susan...? Susan: to me the Grid is about providing standards for general infrastructure that is not a good example ... context helps to manage ... but I did not see any particular benefits in the examples .... WSRF is used for modelling the state in a service which can be passed to another service that can get the state from that first service ... the details can then be passed easily ... for instance one travel agent can get your details by pulling the EPR from another service Tony Hey: WSRF is a proposal in OASIS ... Oracle are in OASIS ... can the shortcomings of WSRF be sorted so that it is of benefit to both parties? Sastry: it is being done ... there are Oracle people in OASIS ... Savas: but Oracle are opposed to the model.... Tony: that is not very constructive ... Sastry: WSRF models a resource behind that service and the EPR has the name and identity of that resource ... binds it together into one entity that is opaque to the client. If you want to talk to the same resource through a different service you effectively have a remote pointer to that resource Tony: I agree with that general thrust ... as a user I would like all of your clients to agree ... if you pursue WS-Context without the help and support of Microsoft and/or IBM then it's not going to get anywhere and vice versa with WSRF Savas: they are not mutually exclusive .... .... Steve: there is no functional difference ... Susan: there is a difference in third party delivery (disagreement noises from Sastry and Savas) Susan: you are passing pointers about that represent the state on the server side ... that is what WSRF is about and you are able to pass that around.. You can create a result set that others can identify in a standard way ... we would have to do something specific for DAIS to do 3rd party delivery otherwise Sastry: you can use any of the 3 approaches to do what Susan just described ... you could just pass the EPR .... Susan: standardise the naming convention though ... Sastry: standardising on the name convention and the addressing is fine but combining the two is a problem Savas: what Sastry just said does leave to some functional differences ... because of the binding of these two things ... in WS-I only can do operations on multiple data resources ... with WSRF you cannot do that without introducing another WSRF resource that groups all of these resources together ... this is a discussion currently going on in the WSRF list ... Norman: Susan said that you have patterns ... some generality helps but the disadvantages is that that pattern cannot always be used Savas: have not seen situations where you gain as a whole on that pattern. Tom: most of your objections are directed about the use of WS-Addressing ... because Microsoft are not involved is not an argument ... Savas: the primary author of WS-Addressing said that just because the spec allows this does not prevent you from hanging yourself ... Tom: we too have asked questions to the authors of that spec ... you seem to object to WSRF because of WS-Addressing concepts ... Sastry: there is no contention with WS-Resource properties ... it's the way of that EPRs are being used Tom: but the normative text in WS-Addressing explicitly talks about dispatching to an entity behind the service. Savas: perhaps Oracle and WSRF people could talk to each other ... Tom: ... can have that discussion in a public forum when WS-Addressing ... Savas: if you used WS-MD (?) you would not use the same conceptual model Tom: the problem then is the binding of the interface to a particular state .. Savas: you expose something that is inside the service and make it explicitly accessible so that it can break ... Tony: that is why Microsoft moved away ... it's CORBA like ... ... Savas: the WSRF TC now want to couple the EPR with WSDL ... ... Susan: can put things that sit behind the service ... you have this in URLs and the web scales ... Savas: the human interactions scale but not the machine-machine interactions ... as a human you know how to deal with a 404 and a resource not being there ... Steve: these scenarios are all drawn from a document ... it would be nice to see scenarios where there is a functional difference Sastry: can take the multiple resource scenario where there is a difference ... Tony: that would be a good idea.... ... Adrian Cockcroft: what about the number of round trips? Savas: there is a model in WS-Agreement where agreements are represented as resources .. you don't send the contract but use an EPR instead ... you need new messages to get properties or the whole agreement ... Alain Andrieux: once an agreement is accepted you don't need this ... Adrian: would be good if the document also included round trips .... Alain: my response is not just the EPR but a copy of the agreement.... ... Sastry: using an EPR to represent a remote document is a stretch ... ... Norman: we are moving to an end of this session ... in the DAIS context we will have to follow-up. We do not know exactly how we will follow-up ... we also wanted to find out what it is exactly and how we can feed back to the process of the emerging specs. We will start discussing as a group how we move forward ... in the specs have tried to decouple the mapping specific stuff with the actual mapping specifics. Savas: can I re-emphasise the slide that makes the case that it is not only the technical equivalence like other factor like tool support and adoption .... these should also be considered. Dave: it would be useful if anyone can think of scenarios that would bring out the functional difference it would be good if these could be communicated to the group. ---