Mailing-List: contact tuscany-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tuscany-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: domain of kentaminator@gmail.com
 designates 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=H0fzFwF2knltgKgsOJlBX0wgvLnzcde9qCdSnkrXLOOJicUOVk1imZMKhPLvRLuzq0eIZFwQr10I77tea0LPzLnxoA0rV+uBuqd4qNCtLiz6taUiSlycNSiBS5xtbfdpUEOCawShtl09SX/OBYRP2F/tl48mqpKdEWwu3bfSuNo=
Message-ID: <e52f74f80608011412r4c0b9afs6d3195a2e5d26edf@mail.gmail.com>
Date: Tue, 1 Aug 2006 14:12:12 -0700
From: "Ken Tam" <kentaminator@gmail.com>
To: tuscany-dev@ws.apache.org
Subject: Re: Webservice via Axis2 in Tomcat.
In-Reply-To: <14E319DD-6D4A-48C1-97DF-5769EC376F95@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44CF7EFF.2020306@gmail.com>
	 <442999A1-F84E-4C09-8307-86DD81979DD4@apache.org>
	 <44CF83BB.1090302@gmail.com>
	 <71e1b5740608010957t71f40d8bp8811301be02ff74f@mail.gmail.com>
	 <05161B88-FB09-44C5-957F-40D41E2BAB1E@apache.org>
	 <71e1b5740608011016sfb98664kdd53c11fb67f71d0@mail.gmail.com>
	 <14E319DD-6D4A-48C1-97DF-5769EC376F95@apache.org>

It seems like having the build infrastructure make it really easy to
configure what components go into a distro would help us iterate our
way to the "right" number and makeup of distros.  While the POM and
project structure manipulation required right now isn't particularly
difficult, it could probably be a lot easier -- I'm thinking of some
mechanism where the POM dependency and assembly descriptor XML
fragments associated with each extension can be kept with the
extension, and the distro description just has to reference extensions
by name.  Does that make any sense?

On 8/1/06, Jeremy Boynes <jboynes@apache.org> wrote:
> There is also the bridge scenario where people are using JSON to talk
> to Ajax clients for the UI but want to access back-end services that
> are using SOAP/HTTP or SOAP/JMS (or XML over JMS ...).
>
> I think this is why we need a spectrum of distros determined by user
> scenarios. By the time we throw everything in that anyone might want
> to use then the kitchen sink variety will be huge, giving a false
> sense of complexity that will put people off and will be a nightmare
> to release as it will require syncing up all the plugins. The other
> extreme is a minimalist one with nothing in it but which allows/
> requires people to figure out and add in function that they need. I
> don't think either of these is ideal.
>
> What I've been proposing is a set of distros based on common runtime
> platforms that people will use. The ones so far are a standalone
> (J2SE) platform and a web-app (J2EE) platform; there's been some
> discussion of a Tomcat platform (i.e. Tomcat + SCA enhancements) like
> M1, and another would be a Celtix platform. These are somewhat
> exclusionary - for example, we will not need to include the Tomcat
> integration code on non-Tomcat platforms, it's just not relevant.
>
> I think users will use these differently, for example, using the
> standalone one as a client, Tomcat for web-app development or Celtix
> for integration. The different usage patterns will show us which
> extensions are relevant for that pattern and we can include those in
> the distro (reducing the number of things users need to add or remove).
>
> --
> Jeremy
>
> On Aug 1, 2006, at 10:16 AM, ant elder wrote:
>
> > I mostly agree, but one of the big benefits for Web services is the
> > JavaScript E4X support. With that and when TUSCANY-419 and the magic
> > databinding stuff is done this is going to make JavaScript
> > components really
> > really useful to use with WS i think. All the old WS debates
> > about databindings and XML to Java mappings disappear as XML
> > becomes really
> > easy.
> >
> >   ...ant
> >
> > On 8/1/06, Jeremy Boynes <jboynes@apache.org> wrote:
> >>
> >> I think there's a difference. Web services play a prominent role in
> >> the SCA specs and are likely to be used by most people which makes a
> >> good case for including them in  distributions by default.
> >>
> >> The JavaScript stuff, although useful, is not something covered by
> >> the spec at all and is likely to be used by a different audience. For
> >> those, I would suggest that we should create a new distribution, one
> >> aimed at people doing REST, JSON, JavaScript stuff; that may or may
> >> not include web services depending on what users want.
> >>
> >> That would give us three distributions:
> >> * standalone environment
> >> * web-app environment with web services
> >> * web-app environment with JS-type stuff
> >>
> >> --
> >> Jeremy
> >>
> >> On Aug 1, 2006, at 9:57 AM, ant elder wrote:
> >>
> >> > How about the JavaScript container be included by default as well
> >> > then?
> >> > Would make it easier to run samples but this brings up all the
> >> > kitchen sink
> >> > distro type questions being discussed on the modularity thread.
> >> >
> >> >   ...ant
> >> >
> >> > On 8/1/06, cr22rc <cr22rc2@gmail.com> wrote:
> >> >>
> >> >> I'm ok with that. I just thought we may want ones without axis.
> >> >> But I'll
> >> >> put it in the others, if I hear nothing different.
> >> >> Jeremy Boynes wrote:
> >> >> > Can we just add the binding to the existing distros?
> >> >> >
> >> >> > --
> >> >> > Jeremy
> >> >> >
> >> >> > On Aug 1, 2006, at 9:19 AM, Rick wrote:
> >> >> >
> >> >> >> I'm currently in the process of trying to get running a service
> >> >> using
> >> >> >> the Axis2 web service binding in Tomcat environment.  The
> >> approach
> >> >> >> I'm taking is to create a new distro based off of Ken Tam's web
> >> >> one
> >> >> >> and add the current Axis 2.0 binding. I've revived the
> >> >> Hellowordlws
> >> >> >> from M1 sample and fixed up the SCDL.     Seem reasonable ?
> >> >> This may
> >> >> >> not be the end all but I'm hoping it will get some web services
> >> >> >> support reasonably soon.
> >> >> >>
> >> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> >>
> >> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org