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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>
>> >
>> >
>> >
>>
---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>>
>>
>>
---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
