[mashup-dev] Mashup Server Deployment Architecture

[Thilina Gunarathne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
See my comments inline...
>> There are three kinds of auxiliary resources:
>> 1) those generated by the Mashup Server for its own bookkeeping and not
>> intended to be examined or modified by the user.
>> 2) those generated by the user for use with a particular service (a
>> service-specific config file for instance.)
>> 3) those generated initially by the Mashup Server, but amenable to
>> examination or modification by the user.
>> 
>> The handling of these kinds can be different.  Hidden or a magic temp
>> directory are good for (1), but awful for (2).  The conventions required for
>> (1) and (3) can be an inconvenience for (2), where the user wants to define
>> his own directory structure.
Thanks a lot for the good analysis :)... +1.

> Other option is to put the .js file in a directory named by the service
> name and use the same to store the resources too.
> 
>> This is pretty clean, though the files shouldn't be hidden.
No...files won't be hidden... But Linux will consider the .xx folders as
hidden folders

>> In effect the directories are immaterial to this approach, which is "put the
>> auxiliary files in the same directory as the service."  To group the
>> auxiliary files together, they will likely have the same base name.
>> service.js will generate service.wsdl, service.tryit.wsdl, service.stub.js,
>> etc.  If the user wants one service per directory, that's their option.
We can give the user the responsibility of making sure dir's are
clean..But IMHO this approach limits the user by two means..
1. User will have to choose between his preferred URL vs the cleanliness
of the directory.. As an example I want 10 services to appear in
http://xxxx/services/foo/bar/xxx/.. But then my directory will be
cluttered..
2. Then enforcement of service.{resource}.xxx naming seems to be bit of
an overhead..

>> As I said earlier, the folder of auxiliary resources should not be hidden as
>> we expect it to contain resources the user might want to examine or change.
>> Any resources we don't ever want the user to touch can still be hidden
>> within the folder.  The folder name should be such that it is grouped
>> alphabetically with the service.  E.g. "service.js" and "service.resources".
+1.. {js file name}.resources directory sounds fine to me...

>> Note that this raises a number of other issues:
>> 1) If I deploy a service, and wsdl gets created automatically, what happens
>> if I directly modify that WSDL?  Does it get served up when I ask for ?wsdl?
>> Is the user then responsible for keeping wsdl 1.1 and wsdl 2.0 in sync?
>> What happens if I redeploy the service?  Are my wsdl changes overwritten?
>> Merged?  Preserved even if they no longer match the service?
I agree that it would have been really nice if the mashup server
persists the WSDL in the file system and then to merge the changes done
by the user when we are updating the WSDL,stubs when the service is
updated.. But for the simplicity I would like if we stick to either the
programatically generated one or the user provided once..No merging or
updating of those resources..

Let the run time dependent things like WSDL's, generated stubs to be
served programmatically rather than storing them in the file system..
This will allow us to reflect the changes done to the service
effectively in these resources.

On the other hand if the user wants control over them, then he can
provide his own wsdl's (may be by saving and modifying what Mashup
server provides), own stubs..But he needs to take care of updating them
once the service is changed.

>> 2) If a temp file is used for generated stubs (e.g. service.stub.js) how is
>> it distinguished from another service that is to be deployed?
We can by default add the annotation this.disable=true;... But I don't
think this will be an issue when we have chosen the correct directory
structure..
>> 3) Is there any benefit from matching the structure of an .aar file?  From
>> accepting .aar files as a way to deploy a service with auxiliary resources
>> in a single file?
I'm 0- on this.. .aar structure is tightly coupled to the services.xml..
The only thing it's structure will add extra to our dir based deployment
 models discussed above will be the META-INF folder...

Thanks,
Thilina

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFGNX7NTt0cKycFPQgRAo1MAJsFFIY4gkKFxOm8rAhnPTCi//AfIgCaA9iX
KYAmOLWToyt4gwwGvEWUfyI=
=FOYb
-----END PGP SIGNATURE-----