[dais-wg] Example based on GGF13 summary - Version 2
Simon Laws
simon_laws at uk.ibm.com
Wed Apr 13 05:36:33 CDT 2005
Example based on GGF13 summary - Version 2
------------------------------------------
Following the DAIS telcon of 12th April I have updated the example to
address some of the issues noted in the first version. The text of the
original note is attached at the bottom for comparison.
The multiplicity symbols I am using here are:
No Symbol = one
* = zero or more
+ = one or more
? = zero or one
Issues Addressed
................
Savas has made a proposal where resource names are resolved to WSRF EPRs
via a message exchange with a web service. I also think this is what Jay
was getting at when he talked about a two call strategy at GGF13.
Here are the main modifications to the previous example required to take
account of the proposal
1/ Introduce a resolve message such as EPR* Resolve ( DataResourceName+ )
2/ Accept that Type 2 and Type 3 data resources can be handled in the same
way whether as WSRF ws resources or as named resources within the DAIS
conduit
3/ In order to achieve 2/ either a) design all messages with optional data
resource names or b) design two sets of messages - I take the approach a)
here as I already made this the case for data resources within the DAIS
conduit
4/ In order to achieve 2/ messages specified for WSRF must be reproduced
for the no WSRF case - The existing example already does this for
GetResourceProperties so I have extended the set.
5/ Change the return messages associated with the 'factory' messages from
EPR to DataResourceName so. Give a name a consumer would be expected to
'resolve' this to a WSF EPR if required.
Service Templates
.................
Assuming the same scenario as before here are the updated service
examples. In this case I have Service B and Service B' to show WSRF and
non WSRF renderings of rowset1.
Service A - DAIS Conduit exposed as a ws resource (or as a non WSRF web
service - in this case there can be only one conduit per service end
point)
<DAISProperties>
<AbstractName>DAISConduit1</AbstractName>
<DAISVersion>1.0</DAISVersion>
<Capabilities>capability info over and above
WSDL</Capabilities>
<DataResource>
<DataResourceName>Database1</DataResourceName>
// CIM properties go here
</DataResource>
</DAISProperties>
// Messages targeted at the DAIS conduit
XML GetResourcePropertyDocument ()
// Get the entire resource properties document
XML GetResourceProperty ( PropertyName )
// Get a named property of the conduit
// If a WSRF implementation is used the WSDL indicates
// the static structure of the properties document
// If a non WSRF implementation is used then there is no
specified
// way of determining the structure of the properties
document.
// we would have to invent one.
DestroyResponse Destroy ( )
// Destroy DBMS conduit only
EPR* Resolve ( DataResourceName+ )
// resolves a resource name to a WSRF EPR if it can
// Messages targeted at a data resource within the conduit
XML GetResourceProperty( DataResourceName?, PropetyName )
// not sure this is required as the message targeted
// at the conduit could be used to navigate down to
// properties of the data resource. However there may be a
// a requirement for messages that retrieve specific
properties
// of a data resource.
Data SQLExecute ( DataResourceName?, SQLExpression )
// as with DAIS currently, the result is returned
synchronously
DataResourceName SQLExecuteFactory ( DataResourceName?,
SQLExpression, RequiredInterface )
// assumes that the result is always managed by DAIS
GenericResponse GenericOperation ( DataResourceName?,
GenericRequest )
// a mechanism for passing generic document based requests
to
// the conduit
Service B - Rowset1 exposed as a ws resource (The implementer chose only a
WSRF approach)
<RowsetProperties>
<AbstractName>Rowset1</AbstractName>
<Schema>...</Schema>
<NumberOfRows>
etc.
</RowsetProperties>
// Messages targeted at the rowset
XML GetResourcePropertyDocument ()
// Get the entire resource properties document
XML getResourceProperty( PropertyName )
// Get a property of the rowset
DestroyResponse Destroy ( )
// Destroy the rowset data resource
GetTuplesResponse getTuples ( DataResourceName?, GetTuplesRequest )
Service B' - Rowset1 exposed as a data resource within a DAIS conduit (The
implementer chose a non WSRF approach)
<DAISProperties>
<AbstractName>DAISConduit1</AbstractName>
<DAISVersion>1.0</DAISVersion>
<Capabilities>capability info over and above
WSDL</Capabilities>
<DataResource>
<DataResourceName>Rowset1</DataResourceName>
// CIM properties go here
</DataResource>
</DAISProperties>
// Messages targeted at the DAIS conduit
XML GetResourcePropertyDocument ()
// Get the entire resource properties document
XML GetResourceProperty ( PropertyName )
// Get a named property of the conduit
DestroyResponse Destroy ( )
// Destroy DBMS conduit only
EPR* Resolve ( DataResourceName+ )
// resolves a resource name to a WSRF EPR if it can
// Messages targeted at the rowset
XML GetResourcePropertyDocument ( DataResourceName?)
// Get the entire resource properties document
XML GetResourceProperty( DataResourceName?, PropertyName )
// Get a property of the rowset
DestroyResponse Destroy ( DataResourceName? )
// Destroy the rowset data resource
GetTuplesResponse getTuples ( DataResourceName?, GetTuplesRequest
)
Port Types
..........
The service templates are intended to give an idea of how running services
will look but give no idea about how the messages will be grouped into
Port Types in a DAIS specification. If you remove the WSRF specified
messages from above and arrange what remains into groups you get something
like
WSRF Defined (we don't have to specify these)
XML GetResourcePropertyDocument ()
XML GetResourceProperty ( PropertyName )
DestroyResponse Destroy ( )
...
Messages required to add WSRF function to non WSRF services (we do have to
worry about these, but where?)
XML GetResourcePropertyDocument ( DataResourceName?)
XML GetResourceProperty( DataResourceName?, PropertyName )
DestroyResponse Destroy ( DataResourceName? )
...
Messages required to move from Non WSRF to WSRF services
EPR* Resolve ( DataResourceName+ )
Generic messages (WS-DAI)
GenericResponse GenericOperation ( DataResourceName?,
GenericRequest )
...
SQL Messages (WS-DAIR)
Data SQLExecute ( DataResourceName?, SQLExpression )
DataResourceName SQLExecuteFactory ( DataResourceName?,
SQLExpression, RequiredInterface )
...
Rowset Messages (WS-DAIR)
GetTuplesResponse getTuples ( DataResourceName?, GetTuplesRequest
)
...
For Further Discussion
......................
8 - Savas made some style comments about replacing the factory messages by
extending the messages that return results directly with options/switches.
I haven't included this here as keeping them separate lets me deal with
the factory aspects explicitly.
9 - Savas also made some suggestions about how to handle requests targeted
at multiple resources. This comes down to the detailed structure of the
input and output messages. I haven't included this here as this adds
another level to the debate.
10. Given an EPR that someone passed you how do you know whether to pass
the data resource name or not. To put it another way how do you know
whether the WSRF or Non WSRF models are being followed? If you have a name
you know what you have to do. If you have and EPR you are not sure.
===================================================================================================================================
Example based on GGF13 summary - Version 1
------------------------------------------
The GGF13 DAIS2 meeting discussed two categories of data resource. Those,
such as DBMS and Databases within them, that exist irrespective of the web
services infrastructure that we are interested in and those that can be
managed by the web services infrastructure, such as result sets.
Artifacts/Resources of concern to DAIS (See Sues's summary note)
................................................................
Type 1 - A DAIS defined conduit to data resources
Type 2 - Data resources not managed by DAIS and hence not suitable for
representation using WSRF
Type 3 - Data resources managed by DAIS and hence suitable for
representation using WSRF
The scenario
............
DAIS (Type 1 resource) that acts as a conduit to data resources of
interest
DBMS1 (Type 2 resource) already exists and contains
Database1 (Type 2 resource) already exists and contains
Table1 (Type 2 resource)
Rowset1 (Type 3 resource) will be created following a SQL query against
Database1
The web services
................
Web Service A - DAIS Service which presents a conduit for accessing the
existing DBMS and its databases e.g. DBMS1 and Database1 (we currently
consider the DBMS functions, e.g. creating and dropping databases, out of
scope of DAIS so will concentrate on database access here)
Web Service B - DAIS Rowset Service which exposes a dynamically created
rowset data resource
Service Templates
.................
These demonstrate how a web service would appear at runtime. This is not
intended to demonstrate how the DAIS specification would group messages
into port types. DAIS currently doesn't mandate how its specified port
types should be combined into services but its hard to envisage the model
here without making some suggestions. So what I have done for Service A
and Serivce B is list some indicative proerpties and a selection of
messages that each service might support. These service interfaces are not
intended to be complete.
Service A - DAIS Conduit exposed as a ws resource (or as a non WSRF web
service - in this case there can be only one conduit per service end
point)
<DAISProperties>
<AbstractName>DAISConduit1</AbstractName>
<DAISVersion>1.0</DAISVersion>
<Capabilities>capability info over and above
WSDL</Capabilities>
<DataResource>
<DataResourceName>Database1</DataResourceName>
// CIM properties go here
</DataResource>
</DAISProperties>
// Messages targeted at the DAIS conduit
XML GetResourcePropertyDocument ()
// Get the entire resource properties document
XML GetResourceProperty ( PropertyName )
// Get a named property of the conduit
// If a WSRF implementation is used the WSDL indicates
// the static structure of the properties document
// If a non WSRF implementation is used then there is no
specified
// way of determining the structure of the properties
document.
// we would have to invent one.
DestroyResponse Destroy ( )
// Destroy DBMS conduit only
// Messages targeted at a data resource within the conduit
XML GetResourceProperty( DataResourceName?, PropetyName )
// not sure this is required as the message targeted
// at the conduit could be used to navigate down to
// properties of the data resource. However there may be a
// a requirement for messages that retrieve specific
properties
// of a data resource.
Data SQLExecute ( DataResourceName?, SQLExpression )
// as with DAIS currently, the result is returned
synchronously
EPR SQLExecuteFactory ( DataResourceName?, SQLExpression,
RequiredInterface )
// assumes that the result is always managed by DAIS
GenericResponse GenericOperation ( DataResourceName?,
GenericRequest )
// a mechanism for passing generic document based requests
to
// the conduit
Service B - Rowset1 exposed as a database resource
<RowsetProperties>
<AbstractName>Rowset1</AbstractName>
<Schema>...</Schema>
<NumberOfRows>
etc.
</RowsetProperties>
// Messages targeted at the rowset
XML GetResourcePropertyDocument ()
// Get the entire resource properties document
XML getResourceProperty( PropertyName )
// Get a property of the rowset
DestroyResponse Destroy ( )
// Destroy the rowset data resource
GetTuplesResponse getTuples ( GetTuplesRequest )
Using the services
...................
Here Ref[DAISConduit1] means a reference to DAISConduit1.
A reference could be represented in several ways, for example, an erp
containing discrimination
information required to identify a ws resource, an epr with just the
endpoint
of a web service (in the case where there is only one conduit at that
endopoint) or just the URL of
web service endpoint (again in this case there can only be one conduit at
that endpoint)
1/ Initiation
The administrator of the web service server deploys Service A
configuring it with the appropriate conduits which in turn reference
existing data resources
2/ Getting properties of the DBMS and Database
PropertiesDoc = Ref[DAISConduit1]->GetResourceProperties ("DAISVersion")
3/ Getting data directly
Data = Ref[DAISConduit1]->SQLExecute ( "Database1", <SQLExpression>SELECT
* FROM Table1</SQLExpression> )
4/ Getting data indirectly
EPR[Rowset1] = Ref[DAISConduit1]->SQLExecuteFactory( "Database1",
<SQLExpression>SELECT * FROM Table1</SQLExpression>,
dais:PortTypeForServiceB )
Data = EPR[Rowset1]->GetTuples( 2 )
For further discussion
----------------------
1/ It is clear that Type 3 resources could be handled by the conduit
in the same way as type 2 resources
We would have to implement lifetime management messages that
pass through the conduit
2/ How to express interfaces/capabilities of the conduit. What more
information
is required over and above WSDL?
We haven't considered the conduit to date so we haven't defined
capabilities at this level necessarily. Do the properties we have
defined
such a Readable, Writeable, ConcurrentAccess etc. work at this
level
3/ Do we provide facilities for the consumer to choose where a result
set is a type 2 or type 3 resources
We have discussed dependent/independent resources before. It
would seem sensible at this stage to take the simple approach and
assume that all dynamically generated data resources are
independent
4/ With the inclusion of data resource properties in the DAIS conduit
properties document we have a potentially large number of nested levels.
5/ The WSRF resource properties can be used to retrieve properties
from the DAIS conduit concerning the conduit itself or concerning the
data resources it contains. There will be other properties of the
data resources that are not contained in the properties document. Data
resource specific messages will be used for retrieving these properties.
I included XML GetResourceProperty( DataResourceName?, PropetyName
)
but its not clear that this general message is appropriate
6/ Given an EPR to the DAIS service a consumer of the service is
unable to tell the difference between a web service which represent
the DAIS conduit as a ws resource and a web service which does not use
wsrf but only represents a single DAIS conduit
7/ Should we specify messages for managing the conduit?
Simon Laws
IBM Hursley - Emerging Technology Services
Mail Point 137, Hursley Park, Winchester, Hampshire, SO21 2JN
Tel: Internal 248708 External +44 (0)1962 818708
Email: simon_laws at uk.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dais-wg/attachments/20050413/dcb182e8/attachment.html
More information about the dais-wg
mailing list