This spec details the structure and behavior of the "scripts" folder, or other folders marked as "virtual directories" for serving Mashups.

Requirements

1. Have a place to cache auto-created artifacts including metadata, stubs, clients, temp files.
2. Have a place for the user to store customized artifacts including metadata, stubs, clients, etc.
3. Provide a directory structure that corresponds directly to the endpoint of the deployed service.
4. Allow users to group related services into folders, recursively, if they so desire.
5. Provide a way to identify resources related to a service to facilitate migration and sharing of the service.
6. Enable the user a straightforward mechanism for versioning of a service.

Issues

When allowing a user to customize the metadata, the following issues could arise:

1. User provides a custom WSDL 2.0, which may be
   1. out of sync with the service
   2. out of sync with the WSDL 1.1 auto-generated by the service
   3. out of sync with a custom WSDL 1.1 provided by the user.
2. Conversely for custom WSDL 1.1.
3. more...

Alpha plan 

The following constraints attempt to reduce some of the outstanding issues above to a manageable scope to deliver in the alpha timeframe. 

• Auxiliary resources are placed in a folder called <js file name>.resources, which (if non-existant) is created automatically upon deployment of the service.
• At present, the system will forgo creating or caching any resources in the .resources directory.  The directory will presenting be used just for user-created resources.  ?wsdl, ?wsdl2, ?stub will continue to generate the appropriate resource on demand.
• If there is a WSDL 2.0 document in the resources directory then:
  • ?wsdl2 should return that file instead of the automatically generated one.
  • ?wsdl should return an error message stating that a custom WSDL 2.0 document is in use and thus WSDL 1.1 isn't currently available.
  • ?stub should use the user-generated WSDL.
• Assume that the root wsdl (when more than one exists in the .resources directory) is named <js file name>.wsdl.
• Deploy services in nested folders within an active virtual directory (presently just "scripts"), omitting any scripts found in x.resources directories, which are by definition auxilliary resources.
• File a WSAS feature request for service aliases in support of versioning.
• File Host Object should default it's directory to something within the .resources directory - perhaps .resources/temp?

 How do we know the <js file name>.wsdl is WSDL 2.0?  Do we need a filename convention for distinguishing WSDL 1.1 from WSDL 2.0?  Do we need an annotation in the .js to allow the user to point to the various WSDLs by name?

 whttp:location may cause conflicts in endpoints.  What happens if an http location conflicts with a URL already in use by another service?