axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: Architecture consideration
Date Mon, 16 Apr 2001 15:44:58 GMT
I agree with your requirements, Yuhichi.

I also strongly agree with avoiding the need for a full J2EE solution.  In
fact, I would prefer the Axis engine to be able to run without a servlet
container, assuming you have other transports available.  If we design this
thing in a modular enough fashion, we should be able to support the use case
of embedding a (pretty tiny) Axis engine into an application which accepts
SOAP requests over a raw TCP socket, or running it standalone in a differnet
JVM as Yuhichi suggests below.

--G

> -----Original Message-----
> From: Yuhichi Nakamura [mailto:NAKAMURY@jp.ibm.com]
> Sent: Friday, April 13, 2001 9:47 AM
> To: axis-dev@xml.apache.org
> Subject: RE: Architecture consideration
> 
> 
> 
> I have two requirements.
> First, AxisEngine instance(s) should be through multiple transports,
> i.e. an engine might be accessed via HTTP and SMTP, so that it
> can be easily maintained.  This does not lead us to EJB directly,
> rather we need to get AxisEngine worked in an different JVM, and it
> is accessed by tranport listener via some means tcp/ip, rmi, etc.
> Second, from security perspective, I want to rely on some
> solid security architecture, especiallly authorization.
> I think that J2EE satisfies the requirements, and is more importantly
> fairly promised.  With J2EE, it is very natural to provide the engine
> as EJB object.
> Furthermore, this approach does not impact on the current
> architecture.
> The current stuff (non-EJB) is still valid.
> Regards,
> 
> Yuhichi Nakamura
> IBM Tokyo Research Laboratory
> Tel: +81-462-73-4668
> 
> 
> From: "Doug Davis" <dug@us.ibm.com> on 2001/04/13 20:34
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:   axis-dev@xml.apache.org
> cc:
> Subject:  RE: Architecture consideration
> 
> 
> 
> Perhaps someone could go into a little more details here
> for me.  When you guys talk about making sure that Axis can
> play in an Enterprise solution (EJBs...) what does that
> mean?  Take Apache SOAP v2, using the EJB pluggable providers
> it can use EJBs, but I'm assuming you guys mean more to it
> than that, right?  Does it mean that the entry point into
> the SOAP server needs to be an EJB?  What are the list of
> requirements that you guys need fulfilled?
> thanks,
> -Dug
> 
> 
> "Yuhichi Nakamura" <NAKAMURY@jp.ibm.com> on 04/12/2001 09:42:02 PM
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:   axis-dev@xml.apache.org
> cc:
> Subject:  RE: Architecture consideration
> 
> 
> 
> 
> Make sense.
> So Axis should allows users to set up light-weight configrations such
> as servlet/jsp-based as well as enterprise configrations including
> EJB, JMS, etc.  Off course, basic componets should be shared as much
> as possible from Axis devloper point of view (as Dug indicated).
> Regards,
> 
> Yuhichi Nakamura
> IBM Tokyo Research Laboratory
> Tel: +81-46-215-4668
> Fax: +81-46-215-7413
> 
> 
> From: Michael Brennan <Michael_Brennan@Allegis.com> on 
> 2001/04/13 10:13
> 
> Please respond to axis-dev@xml.apache.org
> 
> To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> cc:
> Subject:  RE: Architecture consideration
> 
> 
> 
> By "non-J2EE", I really mean servlets and JSPs without EJBs. 
> (Sorry for the
> ambiguity. I should have been more specific.)
> 
> I think a simple web services model for servlets can attract many
> developers
> who are not using EJBs. I would also add that even for those 
> developers who
> are using more of the J2EE platform than just servlets and 
> JSPs, there may
> be other non-EJB services they want to expose as a web service. For
> instance, a servlet interacting with an EIS system using a 
> J2EE Connector
> interface, or perhaps a proprietary integration API.
> 
> Web services have the potential to open many doors that EJBs 
> cannot open.
> In
> addition, a simple web services model could attract many 
> developers who are
> intimidated by the constantly growing complexity of the J2EE model.
> Certainly, though, a sound web services architecture should 
> also be able to
> support those developers who need those richer J2EE services, as well.
> 
> > -----Original Message-----
> > From: Yuhichi Nakamura [mailto:NAKAMURY@jp.ibm.com]
> > Sent: Thursday, April 12, 2001 6:05 PM
> > To: axis-dev@xml.apache.org
> > Subject: RE: Architecture consideration
> >
> >
> >
> > Good point.
> > Can I restate "Axis is based on J2EE, but we should provide non-EJB
> > version also"?  Would you tell me what non-J2EE environments
> > means exactly?  Maybe since I am looking at enterprise applications,
> > I only see J2EE servers such JRun, WebLogic, WebSpehre, etc.
> > Which products are non-J2EE servers?
> > Best regards,
> >
> > Yuhichi Nakamura
> > IBM Tokyo Research Laboratory
> > Tel: +81-46-215-4668
> > Fax: +81-46-215-7413
> >
> >
> > From: Michael Brennan <Michael_Brennan@Allegis.com> on
> > 2001/04/13 09:50
> >
> > Please respond to axis-dev@xml.apache.org
> >
> > To:   "'axis-dev@xml.apache.org'" <axis-dev@xml.apache.org>
> > cc:
> > Subject:  RE: Architecture consideration
> >
> >
> >
> > > From: Yuhichi Nakamura [mailto:NAKAMURY@jp.ibm.com]
> > > Sent: Thursday, April 12, 2001 5:48 PM
> > > To: axis-dev@xml.apache.org
> > > Subject: Re: Architecture consideration
> > > [...]
> > > Apparently, Servlet+EJB is much slower than just Servlet.
> > > I do not know how much slow, and how acceptable.
> > > However, the direciton of application server is J2EE.  Why
> > > not based on it?
> >
> > I hope the team will consider supporting Axis in non-J2EE
> > environments. It
> > would be a mistake to think that everyone using server-side
> > Java are using
> > J2EE servers. Some folks are balking at the cost and
> > complexity of such
> > servers and just sticking with servlets.
> >
> > Axis should play well in J2EE environments, but I think
> > requiring J2EE will
> > shut out a large audience of prospective users.
> >
> > (Just my 2 cents.)
> >
> >
> >
> 
> 
> 
> 
> 
> 
> 
> 

Mime
View raw message