You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Gouker <go...@bellsouth.net> on 2000/09/08 21:33:22 UTC

Introduction and request

Hello!

I'm Michael Gouker, a system programmer (c++ mostly, but more and more java
all the time) from S. Florida and I've been lurking on the list a few days
now. I've seen some very interesting discussions here and would like to
contribute, but I thought a good read of the archives might be  helpful. Can
anyone point me to the right place? I looked on the old ibm site and
couldn't find anything.

Best regards,

Michael


-----Original Message-----
From: Vahe Amirbekyan [mailto:avahe@techone.com]
Sent: Friday, September 08, 2000 2:26 PM
To: soap-dev@xml.apache.org
Subject: Re: Accessing instances in SOAP - ideas?


Hi,

I really fail to see any reason of making any special headers (and in
general any special enhancement in the SOAP) for EJBs. IMHO, the only
place where the EJB-ity comes into picture here is the way how SOAP
router manages the "server" objects. Namely, how it finds and/or
instantiates the server EJB objects.

In our application we created a framework (mentioned on this mailing
list by my colleague Ara and me) called Locator which is a more
sophisticated class loader used in the RPCRouterServlet. If the target
object ID of an incoming call points to an EJB (i.e. is an "instance
identifier"), Locator is able to "locate" the targeted object by getting
its Home and invoking create() or find() on it. The server EJBs can be
either entity or session beans (we have different Locator plugins for
each kind of EJB). Now, the target object ID has to contain all
necessary information so that the Locator can do its job. In the format
of Object ID for EJB we've chosen (oriented on URN standard) we put the
Home name and (optionally, for entity beans only) the key. We also added
regular-expression-based matching (as opposed to exact string matching)
to our Service Manager so that single Deployment Descriptor could
"describe" a whole group of target EJBs. And that's all: once the EJB is
located, it is ready to serve to SOAP clients. The rest is _exactly_ the
same as with any non-EJB server objects.

And - just to make it clear - if the EJBs are used on the server side to
provide SOAP services, it's internal issue for the server, the client
sending the call should not even know about it.

Am I missing something here? Does this answer to your question?

Vahe

Paul Fremantle wrote:
>
> Richard
>
> Thanks for the feedback. I guess I've approached this from two points of
> view:
>
> 1) How to use EJBs to implement new SOAP services. This I'd do with
> stateless session beans, which don't require any special headers, and
could
> be reimplemented with any SOAP backend. This would add the benefits of
EJBs
> as a container for running services (e.g. transactions, thread management)
>
> 2) Accessing existing stateful or persistent EJBs using SOAP. This is
where
> the headers come in, and these would be required for "instances". In this
> case you are tying yourself to a backend that implements an object model.
> You would be more likely to use this for integrating existing EJB
> applications with SOAP than to write new SOAP services. However, from the
> discussions, it seems that a number of people are looking at accessing
> "instance"-based models, so maybe there is a common approach where the
fact
> it is an EJB is not exposed, only the fact that the service exposes some
> instance-based model.
>
> What do you think?
>
> Paul
> ----- Original Message -----
> From: <Ri...@exe.com>
> To: <so...@xml.apache.org>
> Sent: Wednesday, September 06, 2000 9:21 PM
> Subject: Re: Accessing instances in SOAP - ideas?
>
> >
> >
> >
> > Maybe I'm missing something here.  If you add special headers to allow
the
> > backend EJB interaction to happen more easily, aren't you tying yourself
> to an
> > EJB implementation?  IMO there's nothing wrong with this, btw.  However,
> once
> > you've assumed EJB, you can use a much tighter/more efficient
> communications
> > method than SOAP to talk to the server.
> >
> > There are two reasons that I can think of to use SOAP in that case.
> First, to
> > be fully buzzword complient -- perfectly understandable :-)  Second, for
> future
> > backend modification.  However, that would require either rewriting of
the
> > clients to send different instance information (easier than a full
> protocol
> > change but still a pain) or something like XSL to convert the
EJB-headers
> into
> > whatever you are now using.  Either way, you give up a lot of the
> > implementation-agnostic benefits of SOAP.
> >
> > At this point, I'm assuming that I've missed the point behind the
special
> > headers approach...?
> >
> > -Richard
> >
> >
> > Original Message:
> >
> >
> >
> > "Paul Fremantle" <pz...@hursley.ibm.com> on 09/06/2000 03:12:26 PM
> >
> > Please respond to soap-dev@xml.apache.org
> >
> > To:   soap-dev@xml.apache.org, Jackson.George@necx.com
> > cc:    (bcc: Richard Stanford/EXE)
> >
> > Subject:  Accessing instances in SOAP - ideas?
> >
> >
> >
> > Jackson, SOAP gurus!
> >
> > I've been thinking about this (how to specify instances) for EJB
> instances.
> > I've come up with two approaches. One is to call the EJB home to get the
a
> > URI for the instance. This has the benefit of not requiring special
> headers.
> > The other is to put an instance identifier in a header. I'm interested
in
> > comments on both approaches, and any other approaches?
> >
> > I've prototyped both, and the Java Apache client code in each case is
ok.
> I
> > haven't really thought through lightweight clients and other clients.
> >
> > Regards,
> >
> > Paul
> >
> >
> >
> >
> >
> >
> >

--
       (\______________________________________________________/)
     __|_|        Vahe AMIRBEKYAN, Senior Consultant          |_|__
    (___o)            tel: (510) 729 6750 ext.375             (o___)
     (__o)              mailto:vahe@techone.com               (o__)
     (__o)              http://www.techone.com                (o__)
      (_o)____________________________________________________(o_)