[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.koi] Re: Case for SOAP
|
Michael,
Thanks for your observations relating to Jini. We aren't tied to SOAP in
the long term but, because of the "web services" approach we have taken, we
think it is important that we move to using the current mainstream web
services technologies. That's why we want to get SOAP support in place
relatively quickly.
Our group hasn't had any experice with Jini and we hadn't really considered
it as a technology base for Koi, but I don't think there is any technical
basis for not considering it. Adapting Koi to use Jini is an area where we
would certainly welcome contributors to the project.
I haven't researched this yet, but one concern of mine is potential
incompatabilities between the Eclipse and Jini licenses. I don't think
there are any real problems for this stage of technology development but
ultimately I would like to see a collaboration infrastructure and
collaborative features become part of the mainline Eclipse platform so we
should at least try to avoid future licensing problem.
The main thing to keep in mind is that Koi is a technology development
project for an Eclipse collaborative intrastructure. The current Koi
prototype is starting point for this but we aren't at all wedded to this
particular design if something better emerges. If other people have
alternatives that they think would provide a stronger basis for such an
infrastructure we would like invite them to work on it in the context of the
Koi project.
Allen Wirfs-Brock
"Michael Schneider" <michaelschneider@fuse.net> wrote in message
avpja9$lb3$1@rogue.oti.com">news:avpja9$lb3$1@rogue.oti.com...
> Allen,
>
> Is the KOI team tied to SOAP for it's implementation? I started down
> this path on a project we are working on, but we are starting to prototype
> a Jini version.
>
> SOAP was communication only, while the Jini provided many useful services
> out of the box. We hope these additional services will lower our
> development time
> (Persistence, leasing, distributed transactions, ...).
>
> We have a simple set of Web Service requirements. These Web Services
allow
> .NET clients to connect to our system. We have prototyped a Web Service
> Jini Proxy that passes Web Service Requests to a Jini Service. This will
> allow us to present a set of Web Services that can be called by .NET
> clients.
>
> In about 3 weeks I can let you know what we have learned if that would be
> useful
> to you. This is our first app with Jini, so I can't stand up and say "go
> forth with Jini".
> The only statement that I can make now is that Jini looks like a nice
match
> for our
> domain (similar to yours), and I am going to fund a team to develop a
> prototype using Jini.
>
> Does anyone on your team have production code that uses Jini? I am
curious
> of your
> teams thoughts, experiences with Jini.
>
> Thanks, and good luck with KOI,
> Mike Schneider
>
>
> "Allen Wirfs-Brock" <Allenb_Wirfs-Brock@instantiations.com> wrote in
message
> news:atsvii$jp3$1@rogue.oti.com...
> > Our current thinking is that we will use the Apache Axis SOAP
> > implementation. When we were implementing the RPC layers of the Koi
> > prototype last spring/summer Axis was not yet far enough along to be
> usable
> > and it didn't look like the predecessor Apache SOAP implementation was
> going
> > to fit our needs. So, as an interim solution we just went with XML-RPC.
> >
> > We're looking for people who want to get involved with the SOAP work.
If
> > you are interest let me know.
> >
> > Allen Wirfs-Brock
> > Koi project Lead
> >
> >
> > "Ed Burnette" <ed.burnette@no.spam.sas.com> wrote in message
> > news:atq2j9$u1a$1@rogue.oti.com...
> > > Koi looks interesting, and I've read the FAQ about XML-RPC vs. Soap
and
> > the
> > > Server-Side Plugin section. But... the FAQ says using XML-RPC "allowed
> > > Apache time to develop a production quality SOAP implementation".
Well,
> I
> > > think there are a couple good SOAP implementations available now. I
use
> > JAXM
> > > in a production environment and it works fine. I would argue that
while
> > > using XML-RPC is fine for a prototype, you should move immediately to
> > using
> > > SOAP Web services exclusively for maximum interoperability (in the
first
> > > public version if possible) and drop the XML-RPC support.
> > >
> > > You write you want to avoid focusing on the "intricacies of SOAP" but
at
> > the
> > > simple level you're currently using I don't see how SOAP is
> significantly
> > > harder or more complicated than XML-RPC. Just my opinion, but I think
> > moving
> > > now will better position you for the future (with security and routing
> and
> > > other research coming to fruition in SOAP, not to mention broad
industry
> > > support) and the sooner you make the conversion then the less
> > compatability
> > > problems you'll have.
> > >
> > >
> > >
> >
> >
>
>