[mashup-dev] Mashup Server Deployment Architecture

Mon May 7 10:54:22 PDT 2007

Added one other item to the Wiki for your consideration:
 - File Host Object should default it's directory to something within the
.resources directory - perhaps .resources/temp?

Currently the default directory is the mashup server directory.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-bounces at wso2.org]
> On Behalf Of Jonathan Marsh
> Sent: Thursday, May 03, 2007 7:23 PM
> To: mashup-dev at wso2.org
> Subject: RE: [mashup-dev] Mashup Server Deployment Architecture
> 
> Transferred what I think are the conclusions to a speclet at
> http://www.wso2.org/wiki/display/mashup/scripts+folder+structure+and+de
> ploym
> ent
> 
> 
> Jonathan Marsh - http://www.wso2.com -
> http://auburnmarshes.spaces.live.com
> 
> 
> > -----Original Message-----
> > From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-
> bounces at wso2.org]
> > On Behalf Of Jonathan Marsh
> > Sent: Thursday, May 03, 2007 6:07 PM
> > To: mashup-dev at wso2.org
> > Subject: RE: [mashup-dev] Mashup Server Deployment Architecture
> >
> > Yes, easy sharing is an interesting pov.  Some thoughts:
> >
> > If we have a UI based sharing system, the packaging mechanism isn't
> > that
> > crucial; the code will make sure the necessary resources are where
> they
> > need
> > to be.
> >
> > Vista Gadgets use an organization that is similar to an aar (although
> > not
> > compressed). Each gadget is in a folder called foo.gadget.  Inside
> this
> > folder is a manifest called foo.xml.  It points to other resources
> > within
> > the same folder.  To deploy a gadget you just drop the foo.gadget
> > folder
> > into the magic directory and it appears in the UI.
> >
> > However, gadgets are different in two ways from services.  First,
> they
> > are a
> > flat list, and there is no hierarchy.  That's not so good for
> services
> > because services are manifest as endpoint URIs and we want to give
> > users
> > control over the form of their URIs.  So we need a flexible
> hierarchy.
> > Second, there aren't any gadgets that are comprised of a single file,
> > so a
> > folder is always useful in keeping related resources together - not
> so
> > with
> > many services.
> >
> > Since we do want people to be able to share deploy scripts as simple
> > files
> > (through the desktop, FTP, or some other UI) there is some appeal in
> a
> > single folder per service model, but in general I'm not convinced
> it's
> > worth
> > complicating the simplest case.  I can still zip foo.js and
> > foo.resources up
> > and send them along.  Unzip them anywhere (including within a
> > directory) and
> > they'll just work.
> >
> > In sum, I don't think the constraints below will overly complicate
> > sharing
> > of services.
> >
> > Re: distinguishing wsdl versions, that only solves a small part of
> the
> > problem I think.  Also I'm not sure I really want to hardcode links
> to
> > the
> > WSDL into the service, but it's worth thinking about longer.
> >
> > Jonathan Marsh - http://www.wso2.com -
> > http://auburnmarshes.spaces.live.com
> >
> >
> > > -----Original Message-----
> > > From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-
> > bounces at wso2.org]
> > > On Behalf Of Thilina Gunarathne
> > > Sent: Wednesday, May 09, 2007 7:59 AM
> > > To: mashup-dev at wso2.org
> > > Subject: RE: [mashup-dev] Mashup Server Deployment Architecture
> > >
> > > Hi all,
> > > Sharing of Mashup story is one thing which I forgot to add to my
> > first
> > > mail... For me it seems that the sharing of mashups has lot to do
> > with
> > > the
> > > deployment architecture..
> > >
> > > I've just started thinking down that line. Just wanted all of you
> to
> > do
> > > the
> > > same ;-)..
> > >
> > > Thanks,
> > > Thilina
> > >
> > > -----Original Message-----
> > > From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-
> > bounces at wso2.org]
> > > On
> > > Behalf Of Thilina Gunarathne
> > > Sent: Wednesday, May 09, 2007 12:57 PM
> > > To: mashup-dev at wso2.org
> > > Subject: RE: [mashup-dev] Mashup Server Deployment Architecture
> > >
> > >
> > > >I think it would be valuable in WSAS to provide a symlink, aka
> alias
> > > (mac),
> > > >aka shortcut (win) for service endpoints.  Probably even more
> > > important at
> > > >present for WSAS then for the Mashup Server.
> > > IMHO I don't think the type of users whom we are targeting the
> Mashup
> > > server
> > > would need a sophisticated feature like this.. This may be a very
> > good
> > > ad-on
> > > for our enterprise story (enterprise mashup server)
> > >
> > > +1 for the list of constraints..
> > > >- There may be more than one WSDL in the directory - although the
> > > simplest
> > > >convention for determining the "root" would be to look for {js
> file
> > > >name}.wsdl, that doesn't work very well as we extend support to
> WSDL
> > > 1.1 as
> > > >well.  Do we need a new file name   extension convention to
> > > distinguish
> > > >WSDL 1.1 and WSDL 2.0 documents?
> > > How about two property annotations in the service.js as follows,
> > >  this.wsdlv1_1=mywsdl.wsdl;
> > >  this.wsdlv2_0=mywsdl2.wsdl;
> >
> >
> >
> > > thanks,
> > > Thilina
> > >
> > >
> > > > -----Original Message-----
> > > > From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-
> > > bounces at wso2.org]
> > > > On Behalf Of Sanjiva Weerawarana
> > > > Sent: Sunday, April 29, 2007 11:47 PM
> > > > To: mashup-dev at wso2.org
> > > > Subject: Re: [mashup-dev] Mashup Server Deployment Architecture
> > > >
> > > > Thilina Gunarathne wrote:
> > > > >>> 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..
> > > >
> > > > I'd prefer if we keep using whatever WSAS gives for this level of
> > > > function. Right now that means no persisting of what ?wsdl gives.
> > If
> > > we
> > > > want to improve that by supporting a persistent cache type model
> > then
> > > > let's open an issue against WSAS for that.
> > > >
> > > > Sanjiva.
> > > > --
> > > > Sanjiva Weerawarana, Ph.D.
> > > > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > > > email: sanjiva at wso2.com; cell: +94 77 787 6880; fax: +1 509 691
> > 2000
> > > >
> > > > "Oxygenating the Web Service Platform."
> > > >
> > > > _______________________________________________
> > > > Mashup-dev mailing list
> > > > Mashup-dev at wso2.org
> > > > http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
> > >
> > >
> > > _______________________________________________
> > > Mashup-dev mailing list
> > > Mashup-dev at wso2.org
> > > http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
> > >
> > >
> > > --
> > > Internal Virus Database is out-of-date.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.446 / Virus Database: 269.6.1/778 - Release Date:
> > > 4/27/2007
> > > 1:39 PM
> > >
> > >
> > > _______________________________________________
> > > Mashup-dev mailing list
> > > Mashup-dev at wso2.org
> > > http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
> > >
> > >
> > > --
> > > Internal Virus Database is out-of-date.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.446 / Virus Database: 269.6.2/781 - Release Date:
> > > 4/30/2007
> > > 9:14 AM
> > >
> > >
> > >
> > > _______________________________________________
> > > Mashup-dev mailing list
> > > Mashup-dev at wso2.org
> > > http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
> >
> >
> > _______________________________________________
> > Mashup-dev mailing list
> > Mashup-dev at wso2.org
> > http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev
> 
> 
> _______________________________________________
> Mashup-dev mailing list
> Mashup-dev at wso2.org
> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev