From Java CoG Kit

With the advent of the Web Service Resource Framework (WSRF) came the necessity of using Endpoint References (EPR) to address a web service resource. Given the complexity of EPRs, it is unreasonable to expect users to be able to manipulate them manually. A scalable service discovery mechanism is needed that can resolve attributes about services (such as port type and host name) to an EPR. Given that the MDS Index service already contains much of the required infrastructure, a prototype discovery system would be useful as a proof of concept despite concerns about performance of the index service under service discovery conditions. A client-side environment with aliased caching of EPRs would add to the usability as well as reduce traffic to the discovery services. An API to access this environment would allow WSRF client applications to process EPR aliases in addition to EPRs directly.

Details

Service Endpoit Discovery Tool
-------------------------------
- Returns a list of EPRs matching the target service search parameters
- Configuration
	- index service EPRs indexed by aliases
	- Allow for multiple EPRs per alias
	- two configuration types
		1) deployment-wide index service EPR config
		2) personal index service EPR config
			- overrides and/or appends to
			deployment-wide index service EPR config
	- create APIs to allow custom clients to access the
	configuration easily
- Two modes of operation
	1) use configurations to find index service
		- aliases used to specify which VO index service EPR
		to use
			- "default" alias assumed if not specified
			- if multiple EPRs listed per alias, try each
			in order before failing
	2) specify an index service EPR explicitly
		- overrides configuration
		- targets a specific index service
- should handle VO index services transparently
	1: check index service "level" RP
	2: if level > 1 search for another index service, goto 1
	3: query level-1 index service for target service EPR
- other options
	- target service transport protocol (i.e. http, https, etc...)
	- target service host
	- target service port
	- target service EPR output file
		- otherwise, matching EPRs are written to stdout
- simplify query parameters since XPath is generic and not very user 
friendly
	- limit to port type names and resource property names and 
	values
		- --port-type
		- --rp-constraint
- Documentation

Index Services
--------------
- Add a "level" RP that indicates hierarchical level
- Each entry should have three parts
	1) WSDL
		- uniquely identifies type of service through port
		type QName
		- provides a list of RP names and types
	2) EPR
		- uniquely identifies the WS-Resource instance
		- already in DefaultIndexService
	3) Resource Properties (selectable)
		- helps narrow search (i.e. localResourceManager=Fork)
		- already in DefaultIndexService
- Scalability and performance issues need to be addressed
	- XPath queries over large documents are slow
	- Aggregating RPs causes memory scalability problems
	- others?
- Deployment Scenarios
	- Default "personal"
		- default index service
			- entries for each WS-R that wishes to opt in
			- should have an RP value that indicates that
			it is a level-one index
				- i.e contains target service EPRs,
				not more index services EPRs
	- VO
		- default index services for each container (see 
		Default "personal" above)
		- fast VO index services
			- entries for each container's default
			index service
- Better documentation!