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 Paul Fink <pf...@wamnet.com> on 2000/09/13 17:59:32 UTC
Provider Type of "EJB"
There are a few ways one could wed SOAP to EJB.
Right now we have a "Provider Type" that maps to Java classes
and to scripts. One approach would be to extend this to include
EJBs and then have a RPCRouterEJB "do the right thing"
RPCRouterEJB would probably be an abstract class so the specifics
of the EJB call could be easily implemented.
Then I have to figure how to map the DD's scope to the bean's lifecycle.
Re: need for generalized Provider Type
Posted by Paul Fink <pf...@wamnet.com>.
----- Original Message -----
From: "Diane l. Davison" <Di...@oracle.com>
> Yes, definitely.
>
Good. Then I have a purpose in life. ;>}
Re: need for generalized Provider Type
Posted by Paul Fink <pf...@wamnet.com>.
----- Original Message -----
From: "Diane l. Davison" <Di...@oracle.com>
> Yes, definitely.
>
Good. Then I have a purpose in life. ;>}
Re: need for generalized Provider Type
Posted by "Diane l. Davison" <Di...@oracle.com>.
Yes, definitely.
Paul Fink wrote:
> Regardless of how EJBs are handle it would still seem
> that we should have a more generalized implantation of
> providers so that you all can plug in what-ever implementation you want.
>
> Yes? No?
>
> ----- Original Message -----
> From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Thursday, September 14, 2000 5:44 AM
> Subject: Re: Provider Type of "EJB"
>
> > The current codebase supports two types of providers: java and script
> > (some BSF supported scripting language). This definitely needs to be
> > generalized - its fairly easy to support an interface. The deployment
> > descriptor's type attribute would be used as a key to find the
> > appropriate implementation and we would have to make the deployment
> > descriptor extensible to enable whatever is needed for that type
> > of deployment.
> >
> > Any volunteers to do it?
> >
> > Sanjiva.
> >
Re: need for generalized Provider Type
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Me three!
Sanjiva.
----- Original Message -----
From: "George I Matkovits" <ma...@uswest.net>
To: <so...@xml.apache.org>
Sent: Saturday, September 16, 2000 3:06 PM
Subject: Re: need for generalized Provider Type
> IMHO the additional provider implentation would be cleaner.
> I would vote yes,
> Regards - George
>
> Paul Fremantle wrote:
>
> > I vote Yes too.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Paul Fink" <pf...@wamnet.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, September 15, 2000 10:42 PM
> > Subject: need for generalized Provider Type
> >
> > > Regardless of how EJBs are handle it would still seem
> > > that we should have a more generalized implantation of
> > > providers so that you all can plug in what-ever implementation you want.
> > >
> > > Yes? No?
> > >
> > > ----- Original Message -----
> > > From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Thursday, September 14, 2000 5:44 AM
> > > Subject: Re: Provider Type of "EJB"
> > >
> > >
> > > > The current codebase supports two types of providers: java and script
> > > > (some BSF supported scripting language). This definitely needs to be
> > > > generalized - its fairly easy to support an interface. The deployment
> > > > descriptor's type attribute would be used as a key to find the
> > > > appropriate implementation and we would have to make the deployment
> > > > descriptor extensible to enable whatever is needed for that type
> > > > of deployment.
> > > >
> > > > Any volunteers to do it?
> > > >
> > > > Sanjiva.
> > > >
> > >
> > >
>
Re: need for generalized Provider Type
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Me three!
Sanjiva.
----- Original Message -----
From: "George I Matkovits" <ma...@uswest.net>
To: <so...@xml.apache.org>
Sent: Saturday, September 16, 2000 3:06 PM
Subject: Re: need for generalized Provider Type
> IMHO the additional provider implentation would be cleaner.
> I would vote yes,
> Regards - George
>
> Paul Fremantle wrote:
>
> > I vote Yes too.
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Paul Fink" <pf...@wamnet.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, September 15, 2000 10:42 PM
> > Subject: need for generalized Provider Type
> >
> > > Regardless of how EJBs are handle it would still seem
> > > that we should have a more generalized implantation of
> > > providers so that you all can plug in what-ever implementation you want.
> > >
> > > Yes? No?
> > >
> > > ----- Original Message -----
> > > From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Thursday, September 14, 2000 5:44 AM
> > > Subject: Re: Provider Type of "EJB"
> > >
> > >
> > > > The current codebase supports two types of providers: java and script
> > > > (some BSF supported scripting language). This definitely needs to be
> > > > generalized - its fairly easy to support an interface. The deployment
> > > > descriptor's type attribute would be used as a key to find the
> > > > appropriate implementation and we would have to make the deployment
> > > > descriptor extensible to enable whatever is needed for that type
> > > > of deployment.
> > > >
> > > > Any volunteers to do it?
> > > >
> > > > Sanjiva.
> > > >
> > >
> > >
>
Re: need for generalized Provider Type
Posted by George I Matkovits <ma...@uswest.net>.
IMHO the additional provider implentation would be cleaner.
I would vote yes,
Regards - George
Paul Fremantle wrote:
> I vote Yes too.
>
> Paul
>
> ----- Original Message -----
> From: "Paul Fink" <pf...@wamnet.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 10:42 PM
> Subject: need for generalized Provider Type
>
> > Regardless of how EJBs are handle it would still seem
> > that we should have a more generalized implantation of
> > providers so that you all can plug in what-ever implementation you want.
> >
> > Yes? No?
> >
> > ----- Original Message -----
> > From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> > To: <so...@xml.apache.org>
> > Sent: Thursday, September 14, 2000 5:44 AM
> > Subject: Re: Provider Type of "EJB"
> >
> >
> > > The current codebase supports two types of providers: java and script
> > > (some BSF supported scripting language). This definitely needs to be
> > > generalized - its fairly easy to support an interface. The deployment
> > > descriptor's type attribute would be used as a key to find the
> > > appropriate implementation and we would have to make the deployment
> > > descriptor extensible to enable whatever is needed for that type
> > > of deployment.
> > >
> > > Any volunteers to do it?
> > >
> > > Sanjiva.
> > >
> >
> >
Re: need for generalized Provider Type
Posted by George I Matkovits <ma...@uswest.net>.
IMHO the additional provider implentation would be cleaner.
I would vote yes,
Regards - George
Paul Fremantle wrote:
> I vote Yes too.
>
> Paul
>
> ----- Original Message -----
> From: "Paul Fink" <pf...@wamnet.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 10:42 PM
> Subject: need for generalized Provider Type
>
> > Regardless of how EJBs are handle it would still seem
> > that we should have a more generalized implantation of
> > providers so that you all can plug in what-ever implementation you want.
> >
> > Yes? No?
> >
> > ----- Original Message -----
> > From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> > To: <so...@xml.apache.org>
> > Sent: Thursday, September 14, 2000 5:44 AM
> > Subject: Re: Provider Type of "EJB"
> >
> >
> > > The current codebase supports two types of providers: java and script
> > > (some BSF supported scripting language). This definitely needs to be
> > > generalized - its fairly easy to support an interface. The deployment
> > > descriptor's type attribute would be used as a key to find the
> > > appropriate implementation and we would have to make the deployment
> > > descriptor extensible to enable whatever is needed for that type
> > > of deployment.
> > >
> > > Any volunteers to do it?
> > >
> > > Sanjiva.
> > >
> >
> >
Re: need for generalized Provider Type
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
I vote Yes too.
Paul
----- Original Message -----
From: "Paul Fink" <pf...@wamnet.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 10:42 PM
Subject: need for generalized Provider Type
> Regardless of how EJBs are handle it would still seem
> that we should have a more generalized implantation of
> providers so that you all can plug in what-ever implementation you want.
>
> Yes? No?
>
> ----- Original Message -----
> From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Thursday, September 14, 2000 5:44 AM
> Subject: Re: Provider Type of "EJB"
>
>
> > The current codebase supports two types of providers: java and script
> > (some BSF supported scripting language). This definitely needs to be
> > generalized - its fairly easy to support an interface. The deployment
> > descriptor's type attribute would be used as a key to find the
> > appropriate implementation and we would have to make the deployment
> > descriptor extensible to enable whatever is needed for that type
> > of deployment.
> >
> > Any volunteers to do it?
> >
> > Sanjiva.
> >
>
>
Re: need for generalized Provider Type
Posted by "Diane l. Davison" <Di...@oracle.com>.
Yes, definitely.
Paul Fink wrote:
> Regardless of how EJBs are handle it would still seem
> that we should have a more generalized implantation of
> providers so that you all can plug in what-ever implementation you want.
>
> Yes? No?
>
> ----- Original Message -----
> From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Thursday, September 14, 2000 5:44 AM
> Subject: Re: Provider Type of "EJB"
>
> > The current codebase supports two types of providers: java and script
> > (some BSF supported scripting language). This definitely needs to be
> > generalized - its fairly easy to support an interface. The deployment
> > descriptor's type attribute would be used as a key to find the
> > appropriate implementation and we would have to make the deployment
> > descriptor extensible to enable whatever is needed for that type
> > of deployment.
> >
> > Any volunteers to do it?
> >
> > Sanjiva.
> >
Re: need for generalized Provider Type
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
I vote Yes too.
Paul
----- Original Message -----
From: "Paul Fink" <pf...@wamnet.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 10:42 PM
Subject: need for generalized Provider Type
> Regardless of how EJBs are handle it would still seem
> that we should have a more generalized implantation of
> providers so that you all can plug in what-ever implementation you want.
>
> Yes? No?
>
> ----- Original Message -----
> From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Thursday, September 14, 2000 5:44 AM
> Subject: Re: Provider Type of "EJB"
>
>
> > The current codebase supports two types of providers: java and script
> > (some BSF supported scripting language). This definitely needs to be
> > generalized - its fairly easy to support an interface. The deployment
> > descriptor's type attribute would be used as a key to find the
> > appropriate implementation and we would have to make the deployment
> > descriptor extensible to enable whatever is needed for that type
> > of deployment.
> >
> > Any volunteers to do it?
> >
> > Sanjiva.
> >
>
>
need for generalized Provider Type
Posted by Paul Fink <pf...@wamnet.com>.
Regardless of how EJBs are handle it would still seem
that we should have a more generalized implantation of
providers so that you all can plug in what-ever implementation you want.
Yes? No?
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Thursday, September 14, 2000 5:44 AM
Subject: Re: Provider Type of "EJB"
> The current codebase supports two types of providers: java and script
> (some BSF supported scripting language). This definitely needs to be
> generalized - its fairly easy to support an interface. The deployment
> descriptor's type attribute would be used as a key to find the
> appropriate implementation and we would have to make the deployment
> descriptor extensible to enable whatever is needed for that type
> of deployment.
>
> Any volunteers to do it?
>
> Sanjiva.
>
Re: Provider Type of "EJB"
Posted by Paul Fink <pf...@wamnet.com>.
This is the best approach and I'll need to do it
for my current project.
I'm not sure of the process. I'll start on the changes today.
I'll be on vacation all next week so I'll circle back with my design
and diff's sometime the following week.
OK?
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Thursday, September 14, 2000 5:44 AM
Subject: Re: Provider Type of "EJB"
> The current codebase supports two types of providers: java and script
> (some BSF supported scripting language). This definitely needs to be
> generalized - its fairly easy to support an interface. The deployment
> descriptor's type attribute would be used as a key to find the
> appropriate implementation and we would have to make the deployment
> descriptor extensible to enable whatever is needed for that type
> of deployment.
>
> Any volunteers to do it?
>
> Sanjiva.
>
need for generalized Provider Type
Posted by Paul Fink <pf...@wamnet.com>.
Regardless of how EJBs are handle it would still seem
that we should have a more generalized implantation of
providers so that you all can plug in what-ever implementation you want.
Yes? No?
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Thursday, September 14, 2000 5:44 AM
Subject: Re: Provider Type of "EJB"
> The current codebase supports two types of providers: java and script
> (some BSF supported scripting language). This definitely needs to be
> generalized - its fairly easy to support an interface. The deployment
> descriptor's type attribute would be used as a key to find the
> appropriate implementation and we would have to make the deployment
> descriptor extensible to enable whatever is needed for that type
> of deployment.
>
> Any volunteers to do it?
>
> Sanjiva.
>
Re: Provider Type of "EJB"
Posted by Paul Fink <pf...@wamnet.com>.
This is the best approach and I'll need to do it
for my current project.
I'm not sure of the process. I'll start on the changes today.
I'll be on vacation all next week so I'll circle back with my design
and diff's sometime the following week.
OK?
----- Original Message -----
From: "Sanjiva Weerawarana" <sa...@watson.ibm.com>
To: <so...@xml.apache.org>
Sent: Thursday, September 14, 2000 5:44 AM
Subject: Re: Provider Type of "EJB"
> The current codebase supports two types of providers: java and script
> (some BSF supported scripting language). This definitely needs to be
> generalized - its fairly easy to support an interface. The deployment
> descriptor's type attribute would be used as a key to find the
> appropriate implementation and we would have to make the deployment
> descriptor extensible to enable whatever is needed for that type
> of deployment.
>
> Any volunteers to do it?
>
> Sanjiva.
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Vahe
> - SOAP clients should NOT have any information how the server is
> implemented. Consequently, adding special headers/whatever to the SOAP
> message describing EJB-ness of the target object is a bad idea.
I agree
> Also,
> requiring the client to first link to home interface and invoke
> create/find operation on it is also meaningless (although, if needed,
> the client _can_ be provided home interface as well).
I agree that the common cases shouldn't require this. However, the act of
creating a new entity instance *is* a real action, and should be done
explicitly.
> (BTW - how can
> home interface to be exposed "on the same URI as the bean"? The Home
> interface is a factory-like interface not specific to one bean, but to
> the "family" of beans)
The "base" URI expressing the service id is actually giving access to a
family of beans. A more specific URI for a particular instance identifier
"urn:EJBServiceName#instance-identifier" should probably not expose the home
methods. I did suggest this should be optional.
> - The only thing SOAP clients rely on is the target object's URI and
> server's URL.
The URI, URL *and* the definition of the service. The method definitions,
parameters and return values are required to write a successful client. The
EJBs key in the case of an entity is a similar thing in that the client
needs to be able to specify a key to access an instance.
> - The URI of the target object should contain enough information so that
> the server-side framework can uniquely identify the target object.
I agree.
> It
> doesn't mean that the URI should contain internal server data.
I think that this should be dependent on the implementation. If you want to
make stateful session beans available, you need to use some server specific
construct to identify the instances.
> Server
> can use various level of sophistication to map the URI to any internal
> value which is helpful to locate the target object. So it should not
> necessarily contain the type name and the key, e.g. server side can use
> some rule-based approach to select the target object from pools of EJBs.
I agree.
>
> As a whole, our approach is similar to yours, with some exceptions. You
> didn't specify what you changed in the SOAP2.0 to incorporate your
> approach though. In ours - we just added non-SOAP specific Locator and
> URN generator as well as EJB (de)serializers, and also tweaked the
> RPCRouter servlet to use the Locator instead of class loader.
I tweaked the service manager to understand the extended URN syntax. I wrote
my current implementation before SOAP2.0, so I have my own router servlet,
and I have a EJBRouter object which is probably similar to your Locator. I
also subclassed the deployment descriptor to contain EJB-specific info.
Regards,
Paul
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Vahe
> - SOAP clients should NOT have any information how the server is
> implemented. Consequently, adding special headers/whatever to the SOAP
> message describing EJB-ness of the target object is a bad idea.
I agree
> Also,
> requiring the client to first link to home interface and invoke
> create/find operation on it is also meaningless (although, if needed,
> the client _can_ be provided home interface as well).
I agree that the common cases shouldn't require this. However, the act of
creating a new entity instance *is* a real action, and should be done
explicitly.
> (BTW - how can
> home interface to be exposed "on the same URI as the bean"? The Home
> interface is a factory-like interface not specific to one bean, but to
> the "family" of beans)
The "base" URI expressing the service id is actually giving access to a
family of beans. A more specific URI for a particular instance identifier
"urn:EJBServiceName#instance-identifier" should probably not expose the home
methods. I did suggest this should be optional.
> - The only thing SOAP clients rely on is the target object's URI and
> server's URL.
The URI, URL *and* the definition of the service. The method definitions,
parameters and return values are required to write a successful client. The
EJBs key in the case of an entity is a similar thing in that the client
needs to be able to specify a key to access an instance.
> - The URI of the target object should contain enough information so that
> the server-side framework can uniquely identify the target object.
I agree.
> It
> doesn't mean that the URI should contain internal server data.
I think that this should be dependent on the implementation. If you want to
make stateful session beans available, you need to use some server specific
construct to identify the instances.
> Server
> can use various level of sophistication to map the URI to any internal
> value which is helpful to locate the target object. So it should not
> necessarily contain the type name and the key, e.g. server side can use
> some rule-based approach to select the target object from pools of EJBs.
I agree.
>
> As a whole, our approach is similar to yours, with some exceptions. You
> didn't specify what you changed in the SOAP2.0 to incorporate your
> approach though. In ours - we just added non-SOAP specific Locator and
> URN generator as well as EJB (de)serializers, and also tweaked the
> RPCRouter servlet to use the Locator instead of class loader.
I tweaked the service manager to understand the extended URN syntax. I wrote
my current implementation before SOAP2.0, so I have my own router servlet,
and I have a EJBRouter object which is probably similar to your Locator. I
also subclassed the deployment descriptor to contain EJB-specific info.
Regards,
Paul
Re: EJB access over SOAP
Posted by Vahe Amirbekyan <av...@techone.com>.
Paul,
> There has been a number of discussions about EJBs and SOAP recently on this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper which I would
> love to get some comments on. It isn't perfect, but I'd rather get comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
As I described in several postings (e.g. in the thread titled <Provider
Type of "EJB">) we have implemented a SOAP-based system where server
objects are EJBs (session and entity as well as home). Please, refer to
these postings to get more details. If you have additional questions or
comments - feel free to write me (via newsletter or directly). Basically
your approach have many common elements with ours. There are some
differences though, especially when it comes to Home interface
considerations.
> I also have an implementation of this, which is sub-classed/extended on the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
I will just highlight some points we think are important to the issue:
- SOAP clients should NOT have any information how the server is
implemented. Consequently, adding special headers/whatever to the SOAP
message describing EJB-ness of the target object is a bad idea. Also,
requiring the client to first link to home interface and invoke
create/find operation on it is also meaningless (although, if needed,
the client _can_ be provided home interface as well). (BTW - how can
home interface to be exposed "on the same URI as the bean"? The Home
interface is a factory-like interface not specific to one bean, but to
the "family" of beans)
- The only thing SOAP clients rely on is the target object's URI and
server's URL.
- The URI of the target object should contain enough information so that
the server-side framework can uniquely identify the target object. It
doesn't mean that the URI should contain internal server data. Server
can use various level of sophistication to map the URI to any internal
value which is helpful to locate the target object. So it should not
necessarily contain the type name and the key, e.g. server side can use
some rule-based approach to select the target object from pools of EJBs.
As a whole, our approach is similar to yours, with some exceptions. You
didn't specify what you changed in the SOAP2.0 to incorporate your
approach though. In ours - we just added non-SOAP specific Locator and
URN generator as well as EJB (de)serializers, and also tweaked the
RPCRouter servlet to use the Locator instead of class loader.
Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Paul
You are right: there is a mistake in the document. It shouldn't have
"urn:ejb:jndiName" anywhere.
Paul
----- Original Message -----
From: "Paul Fink" <pf...@wamnet.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 6:59 PM
Subject: Re: EJB access over SOAP
> I think I misread some of your document.
> Part of my comments came from the first example where you have
> xmlns:ns1="urn:ejb:Hello"
>
> Then later, in section 5, you say that you do _not_want an
> EJB-base URN schema e.g. urn:ejb:jndiName
>
> I assume the example is incorrect and I understood your intent.
>
> Paul
> ----- Original Message -----
> From: "Paul Fremantle" <pz...@hursley.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 12:18 PM
> Subject: Re: EJB access over SOAP
>
>
> > Paul
> >
> > Thanks for the feedback.
> >
> > I strongly agree with you! I am very keen that people can do exactly
what
> > you suggest - put together a script-based service and then re-engineer
> > later using EJBs. I think the way one should do that is to build a
> stateless
> > session bean that implements the same interface as the service (and the
> next
> > step is to build the tools that can help you do that). I will update the
> > document to be clearer on that. The document is probably wrongly
> structured,
> > because 80% of the text is devoted to 20% of the use cases :-) The
"easy"
> > stuff (stateless session beans) is covered in one short paragraph, but
> will
> > probably be the most used.
> >
> > However, I also envisage people wanting to use SOAP in other ways, and I
> was
> > keen to expose the full power of EJBs over SOAP *if possible*. Having
> > thought about and rejected lots of ways that required changes to the
SOAP
> > protocol, I hope that the approaches for entities and stateful objects
fit
> > the SOAP protocol quite well, even if they extend the spirit. I see the
> > model of using a key in the service id (urn:AccountService#ACC10234) as
> > treating *my* bank account as a service of its own. One motivation is
> things
> > like accessing EJBs over messaging transports.
> >
> > Best,
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Paul Fink" <pf...@wamnet.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, September 15, 2000 5:02 PM
> > Subject: Re: EJB access over SOAP
> >
> >
> > > Thank you very much for your willingness to share your ideas.
> > >
> > > I have a question that is maybe more related to your goals.
> > > You devised a system to expose the EJBs to a client via SOAP.
> > > In doing so the client gains a lot of control over the EJBs but it
> > > also needs to know more about the implementation then I care to
> > > have it know.
> > >
> > > My goal is to have a mechanism that will allow the SOAP server to use
> > > EJBs as "target objects" with out changing the semantics of the SOAP
> call.
> > > I don't want the client to know, or care, how the SOAP server side
> object
> > > is implemented. This is a very important issue. A person writing Perl,
> VB
> > or
> > > maybe even PL/1 shouldn't be required to know anything about EJBs to
> > > make use of a service and in turn I don't want to know anything about
> COM
> > > to make SOAP calls to a Windows box.
> > >
> > > The abstraction also allows the implementation to change with out
> > effecting
> > > the client.
> > > So I can rush out a service using some old C++ interface to the
database
> > > or Perl hack and later come back and re-engineer the service using EJB
> > with
> > > out the clients, (aka customers), ever knowing.
> > >
> > > Now, this restriction on the interface limits what the client can do
and
> > > places additional
> > > restrictions on the server. But this isn't necessarily bad!!
> > >
> > > I would argue, probably not successfully, that one shouldn't worry too
> > much
> > > about
> > > passing primary keys because the "proper" way to make such a call is
> with
> > > getters and setters.
> > >
> > > OK I'll shut up for now and listen to what others say.
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Paul Fremantle" <pz...@hursley.ibm.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Friday, September 15, 2000 10:12 AM
> > > Subject: EJB access over SOAP
> > >
> > >
> > > > Folks,
> > > >
> > > > There has been a number of discussions about EJBs and SOAP recently
on
> > > this
> > > > list. At least two people/organisations have done some work in this
> > area,
> > > > and I have also spent a long time thinking about this: since SOAP
0.9
> > came
> > > > out nearly a year ago. I have put together a discussion paper which
I
> > > would
> > > > love to get some comments on. It isn't perfect, but I'd rather get
> > > comments
> > > > now and improve it with feedback from this list.
> > > >
> > > > In particular I'd like feedback on how this fits with: the
> > implementations
> > > > that others have done, and other object-based systems.
> > > >
> > > > I also have an implementation of this, which is sub-classed/extended
> on
> > > the
> > > > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
> > ready
> > > > soon. The paper touches on some of the things it implements.
> > > >
> > > > Best regards,
> > > >
> > > > Paul Fremantle
> > > >
> > > >
> > > >
> > >
> >
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Paul
You are right: there is a mistake in the document. It shouldn't have
"urn:ejb:jndiName" anywhere.
Paul
----- Original Message -----
From: "Paul Fink" <pf...@wamnet.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 6:59 PM
Subject: Re: EJB access over SOAP
> I think I misread some of your document.
> Part of my comments came from the first example where you have
> xmlns:ns1="urn:ejb:Hello"
>
> Then later, in section 5, you say that you do _not_want an
> EJB-base URN schema e.g. urn:ejb:jndiName
>
> I assume the example is incorrect and I understood your intent.
>
> Paul
> ----- Original Message -----
> From: "Paul Fremantle" <pz...@hursley.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 12:18 PM
> Subject: Re: EJB access over SOAP
>
>
> > Paul
> >
> > Thanks for the feedback.
> >
> > I strongly agree with you! I am very keen that people can do exactly
what
> > you suggest - put together a script-based service and then re-engineer
> > later using EJBs. I think the way one should do that is to build a
> stateless
> > session bean that implements the same interface as the service (and the
> next
> > step is to build the tools that can help you do that). I will update the
> > document to be clearer on that. The document is probably wrongly
> structured,
> > because 80% of the text is devoted to 20% of the use cases :-) The
"easy"
> > stuff (stateless session beans) is covered in one short paragraph, but
> will
> > probably be the most used.
> >
> > However, I also envisage people wanting to use SOAP in other ways, and I
> was
> > keen to expose the full power of EJBs over SOAP *if possible*. Having
> > thought about and rejected lots of ways that required changes to the
SOAP
> > protocol, I hope that the approaches for entities and stateful objects
fit
> > the SOAP protocol quite well, even if they extend the spirit. I see the
> > model of using a key in the service id (urn:AccountService#ACC10234) as
> > treating *my* bank account as a service of its own. One motivation is
> things
> > like accessing EJBs over messaging transports.
> >
> > Best,
> >
> > Paul
> >
> > ----- Original Message -----
> > From: "Paul Fink" <pf...@wamnet.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, September 15, 2000 5:02 PM
> > Subject: Re: EJB access over SOAP
> >
> >
> > > Thank you very much for your willingness to share your ideas.
> > >
> > > I have a question that is maybe more related to your goals.
> > > You devised a system to expose the EJBs to a client via SOAP.
> > > In doing so the client gains a lot of control over the EJBs but it
> > > also needs to know more about the implementation then I care to
> > > have it know.
> > >
> > > My goal is to have a mechanism that will allow the SOAP server to use
> > > EJBs as "target objects" with out changing the semantics of the SOAP
> call.
> > > I don't want the client to know, or care, how the SOAP server side
> object
> > > is implemented. This is a very important issue. A person writing Perl,
> VB
> > or
> > > maybe even PL/1 shouldn't be required to know anything about EJBs to
> > > make use of a service and in turn I don't want to know anything about
> COM
> > > to make SOAP calls to a Windows box.
> > >
> > > The abstraction also allows the implementation to change with out
> > effecting
> > > the client.
> > > So I can rush out a service using some old C++ interface to the
database
> > > or Perl hack and later come back and re-engineer the service using EJB
> > with
> > > out the clients, (aka customers), ever knowing.
> > >
> > > Now, this restriction on the interface limits what the client can do
and
> > > places additional
> > > restrictions on the server. But this isn't necessarily bad!!
> > >
> > > I would argue, probably not successfully, that one shouldn't worry too
> > much
> > > about
> > > passing primary keys because the "proper" way to make such a call is
> with
> > > getters and setters.
> > >
> > > OK I'll shut up for now and listen to what others say.
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Paul Fremantle" <pz...@hursley.ibm.com>
> > > To: <so...@xml.apache.org>
> > > Sent: Friday, September 15, 2000 10:12 AM
> > > Subject: EJB access over SOAP
> > >
> > >
> > > > Folks,
> > > >
> > > > There has been a number of discussions about EJBs and SOAP recently
on
> > > this
> > > > list. At least two people/organisations have done some work in this
> > area,
> > > > and I have also spent a long time thinking about this: since SOAP
0.9
> > came
> > > > out nearly a year ago. I have put together a discussion paper which
I
> > > would
> > > > love to get some comments on. It isn't perfect, but I'd rather get
> > > comments
> > > > now and improve it with feedback from this list.
> > > >
> > > > In particular I'd like feedback on how this fits with: the
> > implementations
> > > > that others have done, and other object-based systems.
> > > >
> > > > I also have an implementation of this, which is sub-classed/extended
> on
> > > the
> > > > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
> > ready
> > > > soon. The paper touches on some of the things it implements.
> > > >
> > > > Best regards,
> > > >
> > > > Paul Fremantle
> > > >
> > > >
> > > >
> > >
> >
>
Re: EJB access over SOAP
Posted by Paul Fink <pf...@wamnet.com>.
I think I misread some of your document.
Part of my comments came from the first example where you have
xmlns:ns1="urn:ejb:Hello"
Then later, in section 5, you say that you do _not_want an
EJB-base URN schema e.g. urn:ejb:jndiName
I assume the example is incorrect and I understood your intent.
Paul
----- Original Message -----
From: "Paul Fremantle" <pz...@hursley.ibm.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 12:18 PM
Subject: Re: EJB access over SOAP
> Paul
>
> Thanks for the feedback.
>
> I strongly agree with you! I am very keen that people can do exactly what
> you suggest - put together a script-based service and then re-engineer
> later using EJBs. I think the way one should do that is to build a
stateless
> session bean that implements the same interface as the service (and the
next
> step is to build the tools that can help you do that). I will update the
> document to be clearer on that. The document is probably wrongly
structured,
> because 80% of the text is devoted to 20% of the use cases :-) The "easy"
> stuff (stateless session beans) is covered in one short paragraph, but
will
> probably be the most used.
>
> However, I also envisage people wanting to use SOAP in other ways, and I
was
> keen to expose the full power of EJBs over SOAP *if possible*. Having
> thought about and rejected lots of ways that required changes to the SOAP
> protocol, I hope that the approaches for entities and stateful objects fit
> the SOAP protocol quite well, even if they extend the spirit. I see the
> model of using a key in the service id (urn:AccountService#ACC10234) as
> treating *my* bank account as a service of its own. One motivation is
things
> like accessing EJBs over messaging transports.
>
> Best,
>
> Paul
>
> ----- Original Message -----
> From: "Paul Fink" <pf...@wamnet.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 5:02 PM
> Subject: Re: EJB access over SOAP
>
>
> > Thank you very much for your willingness to share your ideas.
> >
> > I have a question that is maybe more related to your goals.
> > You devised a system to expose the EJBs to a client via SOAP.
> > In doing so the client gains a lot of control over the EJBs but it
> > also needs to know more about the implementation then I care to
> > have it know.
> >
> > My goal is to have a mechanism that will allow the SOAP server to use
> > EJBs as "target objects" with out changing the semantics of the SOAP
call.
> > I don't want the client to know, or care, how the SOAP server side
object
> > is implemented. This is a very important issue. A person writing Perl,
VB
> or
> > maybe even PL/1 shouldn't be required to know anything about EJBs to
> > make use of a service and in turn I don't want to know anything about
COM
> > to make SOAP calls to a Windows box.
> >
> > The abstraction also allows the implementation to change with out
> effecting
> > the client.
> > So I can rush out a service using some old C++ interface to the database
> > or Perl hack and later come back and re-engineer the service using EJB
> with
> > out the clients, (aka customers), ever knowing.
> >
> > Now, this restriction on the interface limits what the client can do and
> > places additional
> > restrictions on the server. But this isn't necessarily bad!!
> >
> > I would argue, probably not successfully, that one shouldn't worry too
> much
> > about
> > passing primary keys because the "proper" way to make such a call is
with
> > getters and setters.
> >
> > OK I'll shut up for now and listen to what others say.
> >
> >
> >
> > ----- Original Message -----
> > From: "Paul Fremantle" <pz...@hursley.ibm.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, September 15, 2000 10:12 AM
> > Subject: EJB access over SOAP
> >
> >
> > > Folks,
> > >
> > > There has been a number of discussions about EJBs and SOAP recently on
> > this
> > > list. At least two people/organisations have done some work in this
> area,
> > > and I have also spent a long time thinking about this: since SOAP 0.9
> came
> > > out nearly a year ago. I have put together a discussion paper which I
> > would
> > > love to get some comments on. It isn't perfect, but I'd rather get
> > comments
> > > now and improve it with feedback from this list.
> > >
> > > In particular I'd like feedback on how this fits with: the
> implementations
> > > that others have done, and other object-based systems.
> > >
> > > I also have an implementation of this, which is sub-classed/extended
on
> > the
> > > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
> ready
> > > soon. The paper touches on some of the things it implements.
> > >
> > > Best regards,
> > >
> > > Paul Fremantle
> > >
> > >
> > >
> >
>
Re: EJB access over SOAP
Posted by Paul Fink <pf...@wamnet.com>.
I think I misread some of your document.
Part of my comments came from the first example where you have
xmlns:ns1="urn:ejb:Hello"
Then later, in section 5, you say that you do _not_want an
EJB-base URN schema e.g. urn:ejb:jndiName
I assume the example is incorrect and I understood your intent.
Paul
----- Original Message -----
From: "Paul Fremantle" <pz...@hursley.ibm.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 12:18 PM
Subject: Re: EJB access over SOAP
> Paul
>
> Thanks for the feedback.
>
> I strongly agree with you! I am very keen that people can do exactly what
> you suggest - put together a script-based service and then re-engineer
> later using EJBs. I think the way one should do that is to build a
stateless
> session bean that implements the same interface as the service (and the
next
> step is to build the tools that can help you do that). I will update the
> document to be clearer on that. The document is probably wrongly
structured,
> because 80% of the text is devoted to 20% of the use cases :-) The "easy"
> stuff (stateless session beans) is covered in one short paragraph, but
will
> probably be the most used.
>
> However, I also envisage people wanting to use SOAP in other ways, and I
was
> keen to expose the full power of EJBs over SOAP *if possible*. Having
> thought about and rejected lots of ways that required changes to the SOAP
> protocol, I hope that the approaches for entities and stateful objects fit
> the SOAP protocol quite well, even if they extend the spirit. I see the
> model of using a key in the service id (urn:AccountService#ACC10234) as
> treating *my* bank account as a service of its own. One motivation is
things
> like accessing EJBs over messaging transports.
>
> Best,
>
> Paul
>
> ----- Original Message -----
> From: "Paul Fink" <pf...@wamnet.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 5:02 PM
> Subject: Re: EJB access over SOAP
>
>
> > Thank you very much for your willingness to share your ideas.
> >
> > I have a question that is maybe more related to your goals.
> > You devised a system to expose the EJBs to a client via SOAP.
> > In doing so the client gains a lot of control over the EJBs but it
> > also needs to know more about the implementation then I care to
> > have it know.
> >
> > My goal is to have a mechanism that will allow the SOAP server to use
> > EJBs as "target objects" with out changing the semantics of the SOAP
call.
> > I don't want the client to know, or care, how the SOAP server side
object
> > is implemented. This is a very important issue. A person writing Perl,
VB
> or
> > maybe even PL/1 shouldn't be required to know anything about EJBs to
> > make use of a service and in turn I don't want to know anything about
COM
> > to make SOAP calls to a Windows box.
> >
> > The abstraction also allows the implementation to change with out
> effecting
> > the client.
> > So I can rush out a service using some old C++ interface to the database
> > or Perl hack and later come back and re-engineer the service using EJB
> with
> > out the clients, (aka customers), ever knowing.
> >
> > Now, this restriction on the interface limits what the client can do and
> > places additional
> > restrictions on the server. But this isn't necessarily bad!!
> >
> > I would argue, probably not successfully, that one shouldn't worry too
> much
> > about
> > passing primary keys because the "proper" way to make such a call is
with
> > getters and setters.
> >
> > OK I'll shut up for now and listen to what others say.
> >
> >
> >
> > ----- Original Message -----
> > From: "Paul Fremantle" <pz...@hursley.ibm.com>
> > To: <so...@xml.apache.org>
> > Sent: Friday, September 15, 2000 10:12 AM
> > Subject: EJB access over SOAP
> >
> >
> > > Folks,
> > >
> > > There has been a number of discussions about EJBs and SOAP recently on
> > this
> > > list. At least two people/organisations have done some work in this
> area,
> > > and I have also spent a long time thinking about this: since SOAP 0.9
> came
> > > out nearly a year ago. I have put together a discussion paper which I
> > would
> > > love to get some comments on. It isn't perfect, but I'd rather get
> > comments
> > > now and improve it with feedback from this list.
> > >
> > > In particular I'd like feedback on how this fits with: the
> implementations
> > > that others have done, and other object-based systems.
> > >
> > > I also have an implementation of this, which is sub-classed/extended
on
> > the
> > > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
> ready
> > > soon. The paper touches on some of the things it implements.
> > >
> > > Best regards,
> > >
> > > Paul Fremantle
> > >
> > >
> > >
> >
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Paul
Thanks for the feedback.
I strongly agree with you! I am very keen that people can do exactly what
you suggest - put together a script-based service and then re-engineer
later using EJBs. I think the way one should do that is to build a stateless
session bean that implements the same interface as the service (and the next
step is to build the tools that can help you do that). I will update the
document to be clearer on that. The document is probably wrongly structured,
because 80% of the text is devoted to 20% of the use cases :-) The "easy"
stuff (stateless session beans) is covered in one short paragraph, but will
probably be the most used.
However, I also envisage people wanting to use SOAP in other ways, and I was
keen to expose the full power of EJBs over SOAP *if possible*. Having
thought about and rejected lots of ways that required changes to the SOAP
protocol, I hope that the approaches for entities and stateful objects fit
the SOAP protocol quite well, even if they extend the spirit. I see the
model of using a key in the service id (urn:AccountService#ACC10234) as
treating *my* bank account as a service of its own. One motivation is things
like accessing EJBs over messaging transports.
Best,
Paul
----- Original Message -----
From: "Paul Fink" <pf...@wamnet.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 5:02 PM
Subject: Re: EJB access over SOAP
> Thank you very much for your willingness to share your ideas.
>
> I have a question that is maybe more related to your goals.
> You devised a system to expose the EJBs to a client via SOAP.
> In doing so the client gains a lot of control over the EJBs but it
> also needs to know more about the implementation then I care to
> have it know.
>
> My goal is to have a mechanism that will allow the SOAP server to use
> EJBs as "target objects" with out changing the semantics of the SOAP call.
> I don't want the client to know, or care, how the SOAP server side object
> is implemented. This is a very important issue. A person writing Perl, VB
or
> maybe even PL/1 shouldn't be required to know anything about EJBs to
> make use of a service and in turn I don't want to know anything about COM
> to make SOAP calls to a Windows box.
>
> The abstraction also allows the implementation to change with out
effecting
> the client.
> So I can rush out a service using some old C++ interface to the database
> or Perl hack and later come back and re-engineer the service using EJB
with
> out the clients, (aka customers), ever knowing.
>
> Now, this restriction on the interface limits what the client can do and
> places additional
> restrictions on the server. But this isn't necessarily bad!!
>
> I would argue, probably not successfully, that one shouldn't worry too
much
> about
> passing primary keys because the "proper" way to make such a call is with
> getters and setters.
>
> OK I'll shut up for now and listen to what others say.
>
>
>
> ----- Original Message -----
> From: "Paul Fremantle" <pz...@hursley.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 10:12 AM
> Subject: EJB access over SOAP
>
>
> > Folks,
> >
> > There has been a number of discussions about EJBs and SOAP recently on
> this
> > list. At least two people/organisations have done some work in this
area,
> > and I have also spent a long time thinking about this: since SOAP 0.9
came
> > out nearly a year ago. I have put together a discussion paper which I
> would
> > love to get some comments on. It isn't perfect, but I'd rather get
> comments
> > now and improve it with feedback from this list.
> >
> > In particular I'd like feedback on how this fits with: the
implementations
> > that others have done, and other object-based systems.
> >
> > I also have an implementation of this, which is sub-classed/extended on
> the
> > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
ready
> > soon. The paper touches on some of the things it implements.
> >
> > Best regards,
> >
> > Paul Fremantle
> >
> >
> >
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Paul
Thanks for the feedback.
I strongly agree with you! I am very keen that people can do exactly what
you suggest - put together a script-based service and then re-engineer
later using EJBs. I think the way one should do that is to build a stateless
session bean that implements the same interface as the service (and the next
step is to build the tools that can help you do that). I will update the
document to be clearer on that. The document is probably wrongly structured,
because 80% of the text is devoted to 20% of the use cases :-) The "easy"
stuff (stateless session beans) is covered in one short paragraph, but will
probably be the most used.
However, I also envisage people wanting to use SOAP in other ways, and I was
keen to expose the full power of EJBs over SOAP *if possible*. Having
thought about and rejected lots of ways that required changes to the SOAP
protocol, I hope that the approaches for entities and stateful objects fit
the SOAP protocol quite well, even if they extend the spirit. I see the
model of using a key in the service id (urn:AccountService#ACC10234) as
treating *my* bank account as a service of its own. One motivation is things
like accessing EJBs over messaging transports.
Best,
Paul
----- Original Message -----
From: "Paul Fink" <pf...@wamnet.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 5:02 PM
Subject: Re: EJB access over SOAP
> Thank you very much for your willingness to share your ideas.
>
> I have a question that is maybe more related to your goals.
> You devised a system to expose the EJBs to a client via SOAP.
> In doing so the client gains a lot of control over the EJBs but it
> also needs to know more about the implementation then I care to
> have it know.
>
> My goal is to have a mechanism that will allow the SOAP server to use
> EJBs as "target objects" with out changing the semantics of the SOAP call.
> I don't want the client to know, or care, how the SOAP server side object
> is implemented. This is a very important issue. A person writing Perl, VB
or
> maybe even PL/1 shouldn't be required to know anything about EJBs to
> make use of a service and in turn I don't want to know anything about COM
> to make SOAP calls to a Windows box.
>
> The abstraction also allows the implementation to change with out
effecting
> the client.
> So I can rush out a service using some old C++ interface to the database
> or Perl hack and later come back and re-engineer the service using EJB
with
> out the clients, (aka customers), ever knowing.
>
> Now, this restriction on the interface limits what the client can do and
> places additional
> restrictions on the server. But this isn't necessarily bad!!
>
> I would argue, probably not successfully, that one shouldn't worry too
much
> about
> passing primary keys because the "proper" way to make such a call is with
> getters and setters.
>
> OK I'll shut up for now and listen to what others say.
>
>
>
> ----- Original Message -----
> From: "Paul Fremantle" <pz...@hursley.ibm.com>
> To: <so...@xml.apache.org>
> Sent: Friday, September 15, 2000 10:12 AM
> Subject: EJB access over SOAP
>
>
> > Folks,
> >
> > There has been a number of discussions about EJBs and SOAP recently on
> this
> > list. At least two people/organisations have done some work in this
area,
> > and I have also spent a long time thinking about this: since SOAP 0.9
came
> > out nearly a year ago. I have put together a discussion paper which I
> would
> > love to get some comments on. It isn't perfect, but I'd rather get
> comments
> > now and improve it with feedback from this list.
> >
> > In particular I'd like feedback on how this fits with: the
implementations
> > that others have done, and other object-based systems.
> >
> > I also have an implementation of this, which is sub-classed/extended on
> the
> > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
ready
> > soon. The paper touches on some of the things it implements.
> >
> > Best regards,
> >
> > Paul Fremantle
> >
> >
> >
>
Re: EJB access over SOAP
Posted by Paul Fink <pf...@wamnet.com>.
Thank you very much for your willingness to share your ideas.
I have a question that is maybe more related to your goals.
You devised a system to expose the EJBs to a client via SOAP.
In doing so the client gains a lot of control over the EJBs but it
also needs to know more about the implementation then I care to
have it know.
My goal is to have a mechanism that will allow the SOAP server to use
EJBs as "target objects" with out changing the semantics of the SOAP call.
I don't want the client to know, or care, how the SOAP server side object
is implemented. This is a very important issue. A person writing Perl, VB or
maybe even PL/1 shouldn't be required to know anything about EJBs to
make use of a service and in turn I don't want to know anything about COM
to make SOAP calls to a Windows box.
The abstraction also allows the implementation to change with out effecting
the client.
So I can rush out a service using some old C++ interface to the database
or Perl hack and later come back and re-engineer the service using EJB with
out the clients, (aka customers), ever knowing.
Now, this restriction on the interface limits what the client can do and
places additional
restrictions on the server. But this isn't necessarily bad!!
I would argue, probably not successfully, that one shouldn't worry too much
about
passing primary keys because the "proper" way to make such a call is with
getters and setters.
OK I'll shut up for now and listen to what others say.
----- Original Message -----
From: "Paul Fremantle" <pz...@hursley.ibm.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 10:12 AM
Subject: EJB access over SOAP
> Folks,
>
> There has been a number of discussions about EJBs and SOAP recently on
this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper which I
would
> love to get some comments on. It isn't perfect, but I'd rather get
comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
>
> I also have an implementation of this, which is sub-classed/extended on
the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
>
> Best regards,
>
> Paul Fremantle
>
>
>
Re: EJB access over SOAP
Posted by Vahe Amirbekyan <av...@techone.com>.
Paul,
> There has been a number of discussions about EJBs and SOAP recently on this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper which I would
> love to get some comments on. It isn't perfect, but I'd rather get comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
As I described in several postings (e.g. in the thread titled <Provider
Type of "EJB">) we have implemented a SOAP-based system where server
objects are EJBs (session and entity as well as home). Please, refer to
these postings to get more details. If you have additional questions or
comments - feel free to write me (via newsletter or directly). Basically
your approach have many common elements with ours. There are some
differences though, especially when it comes to Home interface
considerations.
> I also have an implementation of this, which is sub-classed/extended on the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
I will just highlight some points we think are important to the issue:
- SOAP clients should NOT have any information how the server is
implemented. Consequently, adding special headers/whatever to the SOAP
message describing EJB-ness of the target object is a bad idea. Also,
requiring the client to first link to home interface and invoke
create/find operation on it is also meaningless (although, if needed,
the client _can_ be provided home interface as well). (BTW - how can
home interface to be exposed "on the same URI as the bean"? The Home
interface is a factory-like interface not specific to one bean, but to
the "family" of beans)
- The only thing SOAP clients rely on is the target object's URI and
server's URL.
- The URI of the target object should contain enough information so that
the server-side framework can uniquely identify the target object. It
doesn't mean that the URI should contain internal server data. Server
can use various level of sophistication to map the URI to any internal
value which is helpful to locate the target object. So it should not
necessarily contain the type name and the key, e.g. server side can use
some rule-based approach to select the target object from pools of EJBs.
As a whole, our approach is similar to yours, with some exceptions. You
didn't specify what you changed in the SOAP2.0 to incorporate your
approach though. In ours - we just added non-SOAP specific Locator and
URN generator as well as EJB (de)serializers, and also tweaked the
RPCRouter servlet to use the Locator instead of class loader.
Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: EJB access over SOAP
Posted by Paul Fink <pf...@wamnet.com>.
Thank you very much for your willingness to share your ideas.
I have a question that is maybe more related to your goals.
You devised a system to expose the EJBs to a client via SOAP.
In doing so the client gains a lot of control over the EJBs but it
also needs to know more about the implementation then I care to
have it know.
My goal is to have a mechanism that will allow the SOAP server to use
EJBs as "target objects" with out changing the semantics of the SOAP call.
I don't want the client to know, or care, how the SOAP server side object
is implemented. This is a very important issue. A person writing Perl, VB or
maybe even PL/1 shouldn't be required to know anything about EJBs to
make use of a service and in turn I don't want to know anything about COM
to make SOAP calls to a Windows box.
The abstraction also allows the implementation to change with out effecting
the client.
So I can rush out a service using some old C++ interface to the database
or Perl hack and later come back and re-engineer the service using EJB with
out the clients, (aka customers), ever knowing.
Now, this restriction on the interface limits what the client can do and
places additional
restrictions on the server. But this isn't necessarily bad!!
I would argue, probably not successfully, that one shouldn't worry too much
about
passing primary keys because the "proper" way to make such a call is with
getters and setters.
OK I'll shut up for now and listen to what others say.
----- Original Message -----
From: "Paul Fremantle" <pz...@hursley.ibm.com>
To: <so...@xml.apache.org>
Sent: Friday, September 15, 2000 10:12 AM
Subject: EJB access over SOAP
> Folks,
>
> There has been a number of discussions about EJBs and SOAP recently on
this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper which I
would
> love to get some comments on. It isn't perfect, but I'd rather get
comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
>
> I also have an implementation of this, which is sub-classed/extended on
the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
>
> Best regards,
>
> Paul Fremantle
>
>
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
George
I plan to publish the extensions shortly... they just need a bit of
tweaking!
Paul
----- Original Message -----
From: "George I Matkovits" <ma...@uswest.net>
To: <so...@xml.apache.org>
Sent: Saturday, September 16, 2000 3:19 AM
Subject: Re: EJB access over SOAP
> I just read your paper. I very much like what you are proposing. It is
clean
> and 'almost' fits in with the current Apache Soap Architecture. We will
have to
> work on transactions later but this would be an excellent beginning. Could
you
> please publish your extensions against the current Soap2_0 base, we could
then
> experiment with it.
> I am normally not very supportive of extensions beyond better support for
Web
> Services BUT IMHO future Web services will be EJB based (the better
ones!!!!!!)
>
> Regards - George
>
> Paul Fremantle wrote:
>
> > Folks,
> >
> > There has been a number of discussions about EJBs and SOAP recently on
this
> > list. At least two people/organisations have done some work in this
area,
> > and I have also spent a long time thinking about this: since SOAP 0.9
came
> > out nearly a year ago. I have put together a discussion paper which I
would
> > love to get some comments on. It isn't perfect, but I'd rather get
comments
> > now and improve it with feedback from this list.
> >
> > In particular I'd like feedback on how this fits with: the
implementations
> > that others have done, and other object-based systems.
> >
> > I also have an implementation of this, which is sub-classed/extended on
the
> > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
ready
> > soon. The paper touches on some of the things it implements.
> >
> > Best regards,
> >
> > Paul Fremantle
> >
> > ------------------------------------------------------------
> > Name: soap ejb proposal.pdf
> > soap ejb proposal.pdf Type: Acrobat (application/pdf)
> > Encoding: base64
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
George
I plan to publish the extensions shortly... they just need a bit of
tweaking!
Paul
----- Original Message -----
From: "George I Matkovits" <ma...@uswest.net>
To: <so...@xml.apache.org>
Sent: Saturday, September 16, 2000 3:19 AM
Subject: Re: EJB access over SOAP
> I just read your paper. I very much like what you are proposing. It is
clean
> and 'almost' fits in with the current Apache Soap Architecture. We will
have to
> work on transactions later but this would be an excellent beginning. Could
you
> please publish your extensions against the current Soap2_0 base, we could
then
> experiment with it.
> I am normally not very supportive of extensions beyond better support for
Web
> Services BUT IMHO future Web services will be EJB based (the better
ones!!!!!!)
>
> Regards - George
>
> Paul Fremantle wrote:
>
> > Folks,
> >
> > There has been a number of discussions about EJBs and SOAP recently on
this
> > list. At least two people/organisations have done some work in this
area,
> > and I have also spent a long time thinking about this: since SOAP 0.9
came
> > out nearly a year ago. I have put together a discussion paper which I
would
> > love to get some comments on. It isn't perfect, but I'd rather get
comments
> > now and improve it with feedback from this list.
> >
> > In particular I'd like feedback on how this fits with: the
implementations
> > that others have done, and other object-based systems.
> >
> > I also have an implementation of this, which is sub-classed/extended on
the
> > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
ready
> > soon. The paper touches on some of the things it implements.
> >
> > Best regards,
> >
> > Paul Fremantle
> >
> > ------------------------------------------------------------
> > Name: soap ejb proposal.pdf
> > soap ejb proposal.pdf Type: Acrobat (application/pdf)
> > Encoding: base64
>
Re: EJB access over SOAP
Posted by George I Matkovits <ma...@uswest.net>.
I just read your paper. I very much like what you are proposing. It is clean
and 'almost' fits in with the current Apache Soap Architecture. We will have to
work on transactions later but this would be an excellent beginning. Could you
please publish your extensions against the current Soap2_0 base, we could then
experiment with it.
I am normally not very supportive of extensions beyond better support for Web
Services BUT IMHO future Web services will be EJB based (the better ones!!!!!!)
Regards - George
Paul Fremantle wrote:
> Folks,
>
> There has been a number of discussions about EJBs and SOAP recently on this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper which I would
> love to get some comments on. It isn't perfect, but I'd rather get comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
>
> I also have an implementation of this, which is sub-classed/extended on the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
>
> Best regards,
>
> Paul Fremantle
>
> ------------------------------------------------------------
> Name: soap ejb proposal.pdf
> soap ejb proposal.pdf Type: Acrobat (application/pdf)
> Encoding: base64
Re: EJB access over SOAP
Posted by George I Matkovits <ma...@uswest.net>.
I just read your paper. I very much like what you are proposing. It is clean
and 'almost' fits in with the current Apache Soap Architecture. We will have to
work on transactions later but this would be an excellent beginning. Could you
please publish your extensions against the current Soap2_0 base, we could then
experiment with it.
I am normally not very supportive of extensions beyond better support for Web
Services BUT IMHO future Web services will be EJB based (the better ones!!!!!!)
Regards - George
Paul Fremantle wrote:
> Folks,
>
> There has been a number of discussions about EJBs and SOAP recently on this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper which I would
> love to get some comments on. It isn't perfect, but I'd rather get comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
>
> I also have an implementation of this, which is sub-classed/extended on the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
>
> Best regards,
>
> Paul Fremantle
>
> ------------------------------------------------------------
> Name: soap ejb proposal.pdf
> soap ejb proposal.pdf Type: Acrobat (application/pdf)
> Encoding: base64
Re: EJB access over SOAP
Posted by Vahe Amirbekyan <av...@techone.com>.
Bernhard,
> > OK, but once you decide to reorganize/scale your JNDI schema on the
> > server side all references held by clients become invalid. IMHO, putting
> > the server-specific JNDI name (as well as any other piece of information
> > reflecting the server's configuration/state) into the reference sent to
> > the client is prone of problems.
> Yes, but reorganisation does not only involve a change of JNDI names,
> probably interfaces change, too. Which also affects clients.
Sure. Basically everything can change. The bottom line is to provide
such a framework on the server side which is able to "react" to
server-side changes so that they do not invalidate the references held
by the clients. URNs are supposed to be _persistent_ resource
identifiers.
>
> > Instead, I'd suggest providing a level
> > of indirection (nothing new, indeed) between the reference sent to the
> > client and the reference used on the server side to identify the
> > service. This what we did in our Locator (see my previous message).
> >
> I can see your point(flexibility).
> But looking into your code I notice, that the JNDI name of the Bean seems to
> be a part of your URN (the TypeName) . Or did I get this wrong?
It is a temporary solution, in fact we did it as a shortcut to
concentrate on other more important issues. But the important thing is:
the Locator can be added a component which will be able to handle URNs
(pointing to EJBs) which have different format. Say, for example, we
decide to include - instead of the direct typename - some "alias" of it.
Then all we have to do is to add a component which takes the "aliases"
from the private part of the URN and maps it to the "real" typename. Or
redirects the call somewhere else, where the "alias" can be resolved.
Again - IMHO - in order to not to end up like URLs (with one - even good
but inflexible - addressing schema) we should rather provide a framework
which can be adapted to changing conditions on server side.
> However, there should be a standardised way to form URNs for references.
> If i got it right, you suggest:
> "urn:"+ <protocol> + ":" + <typename> + "@" + <key>
> with protocol := "ejb" | "soap" | "ejbhome" | "soaphome"
> to be totally transparent shouldn't it be something like
> "urn:target:"+<boundName> ?
Yes, the standards should be used. But - this is why we decided to use
URNs. URN is "urn:" + NamespaceIdentifier (which contains only numbers,
letters and '-') + ":" + Namespace Specific String (which can contain
anything but %,/,? and #). The last one is that what we can compare to
the private part of the IOR in CORBA. It is server-specific, i.e. it is
generated and interpreted by the same server. Hence we can put virtually
anything we want there. In particular, we decided to put protocol info
there along with the typename and key, as it was convenient to implement
locators for EJBs using this information. But we could have chosen any
other format, if it fits to our specific application. IMHO instead of
providing many different standards for different types of target objects
(e.g. EJB), we should rather stick to the general URN format AND some
flexible/pluginable tools on the server side which can decide how to
resolve the URNs.
> > ...why not provide a designated type, called 'urn' or 'objref' or
> > whatever which will indicate that the returned is an object reference:
> >
> > <createResponse>
> > <return xsi:type="xsd:urn">urn:NS:seviceID</return>
> > </createResponse>
> >
> > and nothing is EJB-specific here.
> >
> Agreed. However it was a question to Paul, who does not explain this in his
> document.
> Which location do you (Vahe) use for representing object references?
> NSURI of method call entry in SOAP Body?
> or
> SOAPAction Entry in the http Header?
when we use object reference to invoke remote method - we use references
as any "regular" target object ID, i.e. it is put in the namespace. On
the server side Locator takes care of resolving it to the real object
(EJB). If the reference is used as argument or return value, we use the
'xsd:uri-reference' as the type tag, than the deserializer takes care of
locating the target object (in case of return value serializer invokes
URN Generator and sends the generated reference back to the client).
Regards, Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: EJB access over SOAP
Posted by Vahe Amirbekyan <av...@techone.com>.
Bernhard,
> > OK, but once you decide to reorganize/scale your JNDI schema on the
> > server side all references held by clients become invalid. IMHO, putting
> > the server-specific JNDI name (as well as any other piece of information
> > reflecting the server's configuration/state) into the reference sent to
> > the client is prone of problems.
> Yes, but reorganisation does not only involve a change of JNDI names,
> probably interfaces change, too. Which also affects clients.
Sure. Basically everything can change. The bottom line is to provide
such a framework on the server side which is able to "react" to
server-side changes so that they do not invalidate the references held
by the clients. URNs are supposed to be _persistent_ resource
identifiers.
>
> > Instead, I'd suggest providing a level
> > of indirection (nothing new, indeed) between the reference sent to the
> > client and the reference used on the server side to identify the
> > service. This what we did in our Locator (see my previous message).
> >
> I can see your point(flexibility).
> But looking into your code I notice, that the JNDI name of the Bean seems to
> be a part of your URN (the TypeName) . Or did I get this wrong?
It is a temporary solution, in fact we did it as a shortcut to
concentrate on other more important issues. But the important thing is:
the Locator can be added a component which will be able to handle URNs
(pointing to EJBs) which have different format. Say, for example, we
decide to include - instead of the direct typename - some "alias" of it.
Then all we have to do is to add a component which takes the "aliases"
from the private part of the URN and maps it to the "real" typename. Or
redirects the call somewhere else, where the "alias" can be resolved.
Again - IMHO - in order to not to end up like URLs (with one - even good
but inflexible - addressing schema) we should rather provide a framework
which can be adapted to changing conditions on server side.
> However, there should be a standardised way to form URNs for references.
> If i got it right, you suggest:
> "urn:"+ <protocol> + ":" + <typename> + "@" + <key>
> with protocol := "ejb" | "soap" | "ejbhome" | "soaphome"
> to be totally transparent shouldn't it be something like
> "urn:target:"+<boundName> ?
Yes, the standards should be used. But - this is why we decided to use
URNs. URN is "urn:" + NamespaceIdentifier (which contains only numbers,
letters and '-') + ":" + Namespace Specific String (which can contain
anything but %,/,? and #). The last one is that what we can compare to
the private part of the IOR in CORBA. It is server-specific, i.e. it is
generated and interpreted by the same server. Hence we can put virtually
anything we want there. In particular, we decided to put protocol info
there along with the typename and key, as it was convenient to implement
locators for EJBs using this information. But we could have chosen any
other format, if it fits to our specific application. IMHO instead of
providing many different standards for different types of target objects
(e.g. EJB), we should rather stick to the general URN format AND some
flexible/pluginable tools on the server side which can decide how to
resolve the URNs.
> > ...why not provide a designated type, called 'urn' or 'objref' or
> > whatever which will indicate that the returned is an object reference:
> >
> > <createResponse>
> > <return xsi:type="xsd:urn">urn:NS:seviceID</return>
> > </createResponse>
> >
> > and nothing is EJB-specific here.
> >
> Agreed. However it was a question to Paul, who does not explain this in his
> document.
> Which location do you (Vahe) use for representing object references?
> NSURI of method call entry in SOAP Body?
> or
> SOAPAction Entry in the http Header?
when we use object reference to invoke remote method - we use references
as any "regular" target object ID, i.e. it is put in the namespace. On
the server side Locator takes care of resolving it to the real object
(EJB). If the reference is used as argument or return value, we use the
'xsd:uri-reference' as the type tag, than the deserializer takes care of
locating the target object (in case of return value serializer invokes
URN Generator and sends the generated reference back to the client).
Regards, Vahe
--
(\______________________________________________________/)
__|_| 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_)
RE: EJB access over SOAP
Posted by Bernhard Dorninger <be...@scch.at>.
Hi
> OK, but once you decide to reorganize/scale your JNDI schema on the
> server side all references held by clients become invalid. IMHO, putting
> the server-specific JNDI name (as well as any other piece of information
> reflecting the server's configuration/state) into the reference sent to
> the client is prone of problems.
Yes, but reorganisation does not only involve a change of JNDI names,
probably interfaces change, too. Which also affects clients.
> Instead, I'd suggest providing a level
> of indirection (nothing new, indeed) between the reference sent to the
> client and the reference used on the server side to identify the
> service. This what we did in our Locator (see my previous message).
>
I can see your point(flexibility).
But looking into your code I notice, that the JNDI name of the Bean seems to
be a part of your URN (the TypeName) . Or did I get this wrong?
However, there should be a standardised way to form URNs for references.
If i got it right, you suggest:
"urn:"+ <protocol> + ":" + <typename> + "@" + <key>
with protocol := "ejb" | "soap" | "ejbhome" | "soaphome"
to be totally transparent shouldn't it be something like
"urn:target:"+<boundName> ?
> ...why not provide a designated type, called 'urn' or 'objref' or
> whatever which will indicate that the returned is an object reference:
>
> <createResponse>
> <return xsi:type="xsd:urn">urn:NS:seviceID</return>
> </createResponse>
>
> and nothing is EJB-specific here.
>
Agreed. However it was a question to Paul, who does not explain this in his
document.
Which location do you (Vahe) use for representing object references?
NSURI of method call entry in SOAP Body?
or
SOAPAction Entry in the http Header?
regards
Bernhard
RE: EJB access over SOAP
Posted by Ara Kassabian <ar...@techone.com>.
Minor comment: SOAP already provides a data type for object references:
xsd:uri-reference.
----------------------------------------------
Ara Kassabian
TechOne, Inc.
100 N. Brand Blvd., Suite 605
Glendale, CA 91203
http://www.techone.com
ara@techone.com
(510) 729-6750 Ext. 396 (Oakland)
(818) 476-0055 (Los Angeles)
-----Original Message-----
From: Vahe Amirbekyan [mailto:avahe@techone.com]
Sent: Tuesday, September 19, 2000 1:57 AM
To: soap-dev@xml.apache.org
Subject: Re: EJB access over SOAP
Hello,
> > I also started using the JNDI name in the URI. However, I think
> > this limits
> > the ability to swap a non-ejb service for an ejb service. For
> > example, if I
> > develop a perl-based SOAP service available at "urn:MyAuctionService", I
> > cannot replace the implementation of the service transparently
> > using an EJB.
> Not necessarily. The only thing that limits replacement through nonEJB
> implementations is that the URN contains the fragment "ejb". The use of
JNDI
> names does not limit this. For a client it is transparent what hides
behind
> a name.
> e.g. "urn:myservices:MyService1"
> could be either an "ordinary" service, or a bean. Depends on how names are
> resolved.
OK, but once you decide to reorganize/scale your JNDI schema on the
server side all references held by clients become invalid. IMHO, putting
the server-specific JNDI name (as well as any other piece of information
reflecting the server's configuration/state) into the reference sent to
the client is prone of problems. Instead, I'd suggest providing a level
of indirection (nothing new, indeed) between the reference sent to the
client and the reference used on the server side to identify the
service. This what we did in our Locator (see my previous message).
>
> I am still not sure what is better/worse. However, I will adapt any
> standardisation efforts.
> Question: how you retrieve a your handles from the server? Call
create(...)
> and "createResponse" contains the URI-String?
> <createResponse>
> <return xsi:type="xsd:String">base64-encoded-Handle</return>
> </createResponse>
...why not provide a designated type, called 'urn' or 'objref' or
whatever which will indicate that the returned is an object reference:
<createResponse>
<return xsi:type="xsd:urn">urn:NS:seviceID</return>
</createResponse>
and nothing is EJB-specific here.
> > I would like to see a flexible framework, because I see this as
> > being implementation specific. For example, the ability to use a
> > short UUID rather than a serialized handle.
> YES, I'd love that , too. With having a "name" representation of
References
> I would have no more problem with using them in URIs.
> I'll try to use the JNDI service of the EJB container to map Handles to
> names.
Please, see the Locator I submitted. I'd be glad to hear your opinion
about it.
> > What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
> > expert on URNs.
> Your suggestion would be a valid URI, if it did not use the reserved
"urn:"
> scheme.
> URNs consist of the fixed "urn:" scheme identifier, a NID and a NSS
> seperated by ":".
> In addition, the "#" character should not be used in URNs. (refer to
RFC2141
> for details)
That's true, but you can use other signs like '@', '$', '!', etc.
instead.
Vahe
--
(\______________________________________________________/)
__|_| 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_)
RE: EJB access over SOAP
Posted by Bernhard Dorninger <be...@scch.at>.
Hi
> OK, but once you decide to reorganize/scale your JNDI schema on the
> server side all references held by clients become invalid. IMHO, putting
> the server-specific JNDI name (as well as any other piece of information
> reflecting the server's configuration/state) into the reference sent to
> the client is prone of problems.
Yes, but reorganisation does not only involve a change of JNDI names,
probably interfaces change, too. Which also affects clients.
> Instead, I'd suggest providing a level
> of indirection (nothing new, indeed) between the reference sent to the
> client and the reference used on the server side to identify the
> service. This what we did in our Locator (see my previous message).
>
I can see your point(flexibility).
But looking into your code I notice, that the JNDI name of the Bean seems to
be a part of your URN (the TypeName) . Or did I get this wrong?
However, there should be a standardised way to form URNs for references.
If i got it right, you suggest:
"urn:"+ <protocol> + ":" + <typename> + "@" + <key>
with protocol := "ejb" | "soap" | "ejbhome" | "soaphome"
to be totally transparent shouldn't it be something like
"urn:target:"+<boundName> ?
> ...why not provide a designated type, called 'urn' or 'objref' or
> whatever which will indicate that the returned is an object reference:
>
> <createResponse>
> <return xsi:type="xsd:urn">urn:NS:seviceID</return>
> </createResponse>
>
> and nothing is EJB-specific here.
>
Agreed. However it was a question to Paul, who does not explain this in his
document.
Which location do you (Vahe) use for representing object references?
NSURI of method call entry in SOAP Body?
or
SOAPAction Entry in the http Header?
regards
Bernhard
RE: EJB access over SOAP
Posted by Ara Kassabian <ar...@techone.com>.
Minor comment: SOAP already provides a data type for object references:
xsd:uri-reference.
----------------------------------------------
Ara Kassabian
TechOne, Inc.
100 N. Brand Blvd., Suite 605
Glendale, CA 91203
http://www.techone.com
ara@techone.com
(510) 729-6750 Ext. 396 (Oakland)
(818) 476-0055 (Los Angeles)
-----Original Message-----
From: Vahe Amirbekyan [mailto:avahe@techone.com]
Sent: Tuesday, September 19, 2000 1:57 AM
To: soap-dev@xml.apache.org
Subject: Re: EJB access over SOAP
Hello,
> > I also started using the JNDI name in the URI. However, I think
> > this limits
> > the ability to swap a non-ejb service for an ejb service. For
> > example, if I
> > develop a perl-based SOAP service available at "urn:MyAuctionService", I
> > cannot replace the implementation of the service transparently
> > using an EJB.
> Not necessarily. The only thing that limits replacement through nonEJB
> implementations is that the URN contains the fragment "ejb". The use of
JNDI
> names does not limit this. For a client it is transparent what hides
behind
> a name.
> e.g. "urn:myservices:MyService1"
> could be either an "ordinary" service, or a bean. Depends on how names are
> resolved.
OK, but once you decide to reorganize/scale your JNDI schema on the
server side all references held by clients become invalid. IMHO, putting
the server-specific JNDI name (as well as any other piece of information
reflecting the server's configuration/state) into the reference sent to
the client is prone of problems. Instead, I'd suggest providing a level
of indirection (nothing new, indeed) between the reference sent to the
client and the reference used on the server side to identify the
service. This what we did in our Locator (see my previous message).
>
> I am still not sure what is better/worse. However, I will adapt any
> standardisation efforts.
> Question: how you retrieve a your handles from the server? Call
create(...)
> and "createResponse" contains the URI-String?
> <createResponse>
> <return xsi:type="xsd:String">base64-encoded-Handle</return>
> </createResponse>
...why not provide a designated type, called 'urn' or 'objref' or
whatever which will indicate that the returned is an object reference:
<createResponse>
<return xsi:type="xsd:urn">urn:NS:seviceID</return>
</createResponse>
and nothing is EJB-specific here.
> > I would like to see a flexible framework, because I see this as
> > being implementation specific. For example, the ability to use a
> > short UUID rather than a serialized handle.
> YES, I'd love that , too. With having a "name" representation of
References
> I would have no more problem with using them in URIs.
> I'll try to use the JNDI service of the EJB container to map Handles to
> names.
Please, see the Locator I submitted. I'd be glad to hear your opinion
about it.
> > What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
> > expert on URNs.
> Your suggestion would be a valid URI, if it did not use the reserved
"urn:"
> scheme.
> URNs consist of the fixed "urn:" scheme identifier, a NID and a NSS
> seperated by ":".
> In addition, the "#" character should not be used in URNs. (refer to
RFC2141
> for details)
That's true, but you can use other signs like '@', '$', '!', etc.
instead.
Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: EJB access over SOAP
Posted by Vahe Amirbekyan <av...@techone.com>.
Hello,
> > I also started using the JNDI name in the URI. However, I think
> > this limits
> > the ability to swap a non-ejb service for an ejb service. For
> > example, if I
> > develop a perl-based SOAP service available at "urn:MyAuctionService", I
> > cannot replace the implementation of the service transparently
> > using an EJB.
> Not necessarily. The only thing that limits replacement through nonEJB
> implementations is that the URN contains the fragment "ejb". The use of JNDI
> names does not limit this. For a client it is transparent what hides behind
> a name.
> e.g. "urn:myservices:MyService1"
> could be either an "ordinary" service, or a bean. Depends on how names are
> resolved.
OK, but once you decide to reorganize/scale your JNDI schema on the
server side all references held by clients become invalid. IMHO, putting
the server-specific JNDI name (as well as any other piece of information
reflecting the server's configuration/state) into the reference sent to
the client is prone of problems. Instead, I'd suggest providing a level
of indirection (nothing new, indeed) between the reference sent to the
client and the reference used on the server side to identify the
service. This what we did in our Locator (see my previous message).
>
> I am still not sure what is better/worse. However, I will adapt any
> standardisation efforts.
> Question: how you retrieve a your handles from the server? Call create(...)
> and "createResponse" contains the URI-String?
> <createResponse>
> <return xsi:type="xsd:String">base64-encoded-Handle</return>
> </createResponse>
...why not provide a designated type, called 'urn' or 'objref' or
whatever which will indicate that the returned is an object reference:
<createResponse>
<return xsi:type="xsd:urn">urn:NS:seviceID</return>
</createResponse>
and nothing is EJB-specific here.
> > I would like to see a flexible framework, because I see this as
> > being implementation specific. For example, the ability to use a
> > short UUID rather than a serialized handle.
> YES, I'd love that , too. With having a "name" representation of References
> I would have no more problem with using them in URIs.
> I'll try to use the JNDI service of the EJB container to map Handles to
> names.
Please, see the Locator I submitted. I'd be glad to hear your opinion
about it.
> > What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
> > expert on URNs.
> Your suggestion would be a valid URI, if it did not use the reserved "urn:"
> scheme.
> URNs consist of the fixed "urn:" scheme identifier, a NID and a NSS
> seperated by ":".
> In addition, the "#" character should not be used in URNs. (refer to RFC2141
> for details)
That's true, but you can use other signs like '@', '$', '!', etc.
instead.
Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: EJB access over SOAP
Posted by Vahe Amirbekyan <av...@techone.com>.
Hello,
> > I also started using the JNDI name in the URI. However, I think
> > this limits
> > the ability to swap a non-ejb service for an ejb service. For
> > example, if I
> > develop a perl-based SOAP service available at "urn:MyAuctionService", I
> > cannot replace the implementation of the service transparently
> > using an EJB.
> Not necessarily. The only thing that limits replacement through nonEJB
> implementations is that the URN contains the fragment "ejb". The use of JNDI
> names does not limit this. For a client it is transparent what hides behind
> a name.
> e.g. "urn:myservices:MyService1"
> could be either an "ordinary" service, or a bean. Depends on how names are
> resolved.
OK, but once you decide to reorganize/scale your JNDI schema on the
server side all references held by clients become invalid. IMHO, putting
the server-specific JNDI name (as well as any other piece of information
reflecting the server's configuration/state) into the reference sent to
the client is prone of problems. Instead, I'd suggest providing a level
of indirection (nothing new, indeed) between the reference sent to the
client and the reference used on the server side to identify the
service. This what we did in our Locator (see my previous message).
>
> I am still not sure what is better/worse. However, I will adapt any
> standardisation efforts.
> Question: how you retrieve a your handles from the server? Call create(...)
> and "createResponse" contains the URI-String?
> <createResponse>
> <return xsi:type="xsd:String">base64-encoded-Handle</return>
> </createResponse>
...why not provide a designated type, called 'urn' or 'objref' or
whatever which will indicate that the returned is an object reference:
<createResponse>
<return xsi:type="xsd:urn">urn:NS:seviceID</return>
</createResponse>
and nothing is EJB-specific here.
> > I would like to see a flexible framework, because I see this as
> > being implementation specific. For example, the ability to use a
> > short UUID rather than a serialized handle.
> YES, I'd love that , too. With having a "name" representation of References
> I would have no more problem with using them in URIs.
> I'll try to use the JNDI service of the EJB container to map Handles to
> names.
Please, see the Locator I submitted. I'd be glad to hear your opinion
about it.
> > What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
> > expert on URNs.
> Your suggestion would be a valid URI, if it did not use the reserved "urn:"
> scheme.
> URNs consist of the fixed "urn:" scheme identifier, a NID and a NSS
> seperated by ":".
> In addition, the "#" character should not be used in URNs. (refer to RFC2141
> for details)
That's true, but you can use other signs like '@', '$', '!', etc.
instead.
Vahe
--
(\______________________________________________________/)
__|_| 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_)
RE: EJB access over SOAP
Posted by Bernhard Dorninger <be...@scch.at>.
Hi Paul
> I also started using the JNDI name in the URI. However, I think
> this limits
> the ability to swap a non-ejb service for an ejb service. For
> example, if I
> develop a perl-based SOAP service available at "urn:MyAuctionService", I
> cannot replace the implementation of the service transparently
> using an EJB.
Not necessarily. The only thing that limits replacement through nonEJB
implementations is that the URN contains the fragment "ejb". The use of JNDI
names does not limit this. For a client it is transparent what hides behind
a name.
e.g. "urn:myservices:MyService1"
could be either an "ordinary" service, or a bean. Depends on how names are
resolved.
> I have used the NS-URI of the method to encode the Handle. I don't like it
> much either, but since I only use this for stateful session beans, I think
> it is ok.
Has its pros, but also cons. I think serialised objects and resource
identifiers are two different things. And: Dealing with remote references,
is an extension of SOAP, as the SOAP spec defines that as a non-goal. SOAP
Header entries are a way to extend messages. Generally it should be
discussed, how remote references shall be represented in SOAP.
I was struggling a lot with myself (and still do) if its better to wrap
Handles in a message entry or in the NS. But finally I chose the way of
using header entries for targeting EJBObjects. These entries are named
<Handle> and <HomeHandle>and contain the base64 serialised handle. With a
"neutral" naming I could also use it to reference objects different from
EJBs, then the tags containing other serialised object refs.
I am still not sure what is better/worse. However, I will adapt any
standardisation efforts.
Question: how you retrieve a your handles from the server? Call create(...)
and "createResponse" contains the URI-String?
<createResponse>
<return xsi:type="xsd:String">base64-encoded-Handle</return>
</createResponse>
> I would like to see a flexible framework, because I see this as
> being implementation specific. For example, the ability to use a
> short UUID rather than a serialized handle.
YES, I'd love that , too. With having a "name" representation of References
I would have no more problem with using them in URIs.
I'll try to use the JNDI service of the EJB container to map Handles to
names.
> I don't use the SOAPAction header.
I do. It specifies the Service-URN (which contains the JNDI name)
> What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
> expert on URNs.
Your suggestion would be a valid URI, if it did not use the reserved "urn:"
scheme.
URNs consist of the fixed "urn:" scheme identifier, a NID and a NSS
seperated by ":".
In addition, the "#" character should not be used in URNs. (refer to RFC2141
for details)
regards
Bernhard
RE: EJB access over SOAP
Posted by Bernhard Dorninger <be...@scch.at>.
Hi Paul
> I also started using the JNDI name in the URI. However, I think
> this limits
> the ability to swap a non-ejb service for an ejb service. For
> example, if I
> develop a perl-based SOAP service available at "urn:MyAuctionService", I
> cannot replace the implementation of the service transparently
> using an EJB.
Not necessarily. The only thing that limits replacement through nonEJB
implementations is that the URN contains the fragment "ejb". The use of JNDI
names does not limit this. For a client it is transparent what hides behind
a name.
e.g. "urn:myservices:MyService1"
could be either an "ordinary" service, or a bean. Depends on how names are
resolved.
> I have used the NS-URI of the method to encode the Handle. I don't like it
> much either, but since I only use this for stateful session beans, I think
> it is ok.
Has its pros, but also cons. I think serialised objects and resource
identifiers are two different things. And: Dealing with remote references,
is an extension of SOAP, as the SOAP spec defines that as a non-goal. SOAP
Header entries are a way to extend messages. Generally it should be
discussed, how remote references shall be represented in SOAP.
I was struggling a lot with myself (and still do) if its better to wrap
Handles in a message entry or in the NS. But finally I chose the way of
using header entries for targeting EJBObjects. These entries are named
<Handle> and <HomeHandle>and contain the base64 serialised handle. With a
"neutral" naming I could also use it to reference objects different from
EJBs, then the tags containing other serialised object refs.
I am still not sure what is better/worse. However, I will adapt any
standardisation efforts.
Question: how you retrieve a your handles from the server? Call create(...)
and "createResponse" contains the URI-String?
<createResponse>
<return xsi:type="xsd:String">base64-encoded-Handle</return>
</createResponse>
> I would like to see a flexible framework, because I see this as
> being implementation specific. For example, the ability to use a
> short UUID rather than a serialized handle.
YES, I'd love that , too. With having a "name" representation of References
I would have no more problem with using them in URIs.
I'll try to use the JNDI service of the EJB container to map Handles to
names.
> I don't use the SOAPAction header.
I do. It specifies the Service-URN (which contains the JNDI name)
> What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
> expert on URNs.
Your suggestion would be a valid URI, if it did not use the reserved "urn:"
scheme.
URNs consist of the fixed "urn:" scheme identifier, a NID and a NSS
seperated by ":".
In addition, the "#" character should not be used in URNs. (refer to RFC2141
for details)
regards
Bernhard
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Bernhard
I also started using the JNDI name in the URI. However, I think this limits
the ability to swap a non-ejb service for an ejb service. For example, if I
develop a perl-based SOAP service available at "urn:MyAuctionService", I
cannot replace the implementation of the service transparently using an EJB.
I have used the NS-URI of the method to encode the Handle. I don't like it
much either, but since I only use this for stateful session beans, I think
it is ok. I would like to see a flexible framework, because I see this as
being implementation specific. For example, the ability to use a short UUID
rather than a serialized handle. I don't use the SOAPAction header.
What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
expert on URNs.
Regards,
Paul
----- Original Message -----
From: "Bernhard Dorninger" <be...@scch.at>
To: <so...@xml.apache.org>
Sent: Monday, September 18, 2000 9:30 AM
Subject: RE: EJB access over SOAP
> Hi
> I also have read the proposal and found it to be very interesting.
> Unfortunately my efforts in this direction (use EJBs via SOAP), use things
> you declare a no-no.
> 1. I do not use a service registry , i use jndi names in an URI (e.g.
> "urn:MyServices:MyBeanJNDIName") to identify the service (the bean).
What's
> the problem with using JNDI names? Security?
> The bean interfaces have to be available to the clients anyway (method
> desc.+params), so why not a JNDI name?
>
> 2. I do use special Header Entries in my concept (for carrying Handles
over
> the network). And I can see your point here, why one should not use header
> entries. I too am not very happy with that and considered to encode
handles
> in an URN.
> **Question: Is your suggested encoding of a handle used as NS-URI of the
> method? Or is this URI used in the "SOAPAction" Header entry only? **
> Since string encoded handles are rather long,I had a problem with both
> possibilities, as they make the request look ugly.
> Anyway, what you suggest in your section 4, does not appear to be a valid
> URN ("urn:SessionService#base64-encoded-serHandle"). typo?
>
> 3. I had not considered any special handling to transmit entity bean keys.
> findByPrimaryKey is an ordinary home method, therefore its call cann be
> encoded like any other method call. Client/Server should of course be
> capable of deSerialising Primary key objects .
> In addition I think, that clients (any Clients, not just SOAP) should not
> work directly with Entity beans. I see them as an abstraction of
application
> data, with Session beans providing the necessary business interface.
>
> regards
> Bernhard
>
> > -----Original Message-----
> > From: Paul Fremantle [mailto:pzf@hursley.ibm.com]
> > Sent: 15 September 2000 17:13
> > To: soap-dev@xml.apache.org
> > Subject: EJB access over SOAP
> >
> >
> > Folks,
> >
> > There has been a number of discussions about EJBs and SOAP
> > recently on this
> > list. At least two people/organisations have done some work in this
area,
> > and I have also spent a long time thinking about this: since SOAP 0.9
came
> > out nearly a year ago. I have put together a discussion paper
> > which I would
> > love to get some comments on. It isn't perfect, but I'd rather
> > get comments
> > now and improve it with feedback from this list.
> >
> > In particular I'd like feedback on how this fits with: the
implementations
> > that others have done, and other object-based systems.
> >
> > I also have an implementation of this, which is
> > sub-classed/extended on the
> > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
ready
> > soon. The paper touches on some of the things it implements.
> >
> > Best regards,
> >
> > Paul Fremantle
> >
> >
> >
>
Re: EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Bernhard
I also started using the JNDI name in the URI. However, I think this limits
the ability to swap a non-ejb service for an ejb service. For example, if I
develop a perl-based SOAP service available at "urn:MyAuctionService", I
cannot replace the implementation of the service transparently using an EJB.
I have used the NS-URI of the method to encode the Handle. I don't like it
much either, but since I only use this for stateful session beans, I think
it is ok. I would like to see a flexible framework, because I see this as
being implementation specific. For example, the ability to use a short UUID
rather than a serialized handle. I don't use the SOAPAction header.
What is wrong with "urn:SessionService#base64encodedhandle" ? I'm not an
expert on URNs.
Regards,
Paul
----- Original Message -----
From: "Bernhard Dorninger" <be...@scch.at>
To: <so...@xml.apache.org>
Sent: Monday, September 18, 2000 9:30 AM
Subject: RE: EJB access over SOAP
> Hi
> I also have read the proposal and found it to be very interesting.
> Unfortunately my efforts in this direction (use EJBs via SOAP), use things
> you declare a no-no.
> 1. I do not use a service registry , i use jndi names in an URI (e.g.
> "urn:MyServices:MyBeanJNDIName") to identify the service (the bean).
What's
> the problem with using JNDI names? Security?
> The bean interfaces have to be available to the clients anyway (method
> desc.+params), so why not a JNDI name?
>
> 2. I do use special Header Entries in my concept (for carrying Handles
over
> the network). And I can see your point here, why one should not use header
> entries. I too am not very happy with that and considered to encode
handles
> in an URN.
> **Question: Is your suggested encoding of a handle used as NS-URI of the
> method? Or is this URI used in the "SOAPAction" Header entry only? **
> Since string encoded handles are rather long,I had a problem with both
> possibilities, as they make the request look ugly.
> Anyway, what you suggest in your section 4, does not appear to be a valid
> URN ("urn:SessionService#base64-encoded-serHandle"). typo?
>
> 3. I had not considered any special handling to transmit entity bean keys.
> findByPrimaryKey is an ordinary home method, therefore its call cann be
> encoded like any other method call. Client/Server should of course be
> capable of deSerialising Primary key objects .
> In addition I think, that clients (any Clients, not just SOAP) should not
> work directly with Entity beans. I see them as an abstraction of
application
> data, with Session beans providing the necessary business interface.
>
> regards
> Bernhard
>
> > -----Original Message-----
> > From: Paul Fremantle [mailto:pzf@hursley.ibm.com]
> > Sent: 15 September 2000 17:13
> > To: soap-dev@xml.apache.org
> > Subject: EJB access over SOAP
> >
> >
> > Folks,
> >
> > There has been a number of discussions about EJBs and SOAP
> > recently on this
> > list. At least two people/organisations have done some work in this
area,
> > and I have also spent a long time thinking about this: since SOAP 0.9
came
> > out nearly a year ago. I have put together a discussion paper
> > which I would
> > love to get some comments on. It isn't perfect, but I'd rather
> > get comments
> > now and improve it with feedback from this list.
> >
> > In particular I'd like feedback on how this fits with: the
implementations
> > that others have done, and other object-based systems.
> >
> > I also have an implementation of this, which is
> > sub-classed/extended on the
> > SOAP2.0 base. It isn't quite ready for release, but I hope to get it
ready
> > soon. The paper touches on some of the things it implements.
> >
> > Best regards,
> >
> > Paul Fremantle
> >
> >
> >
>
RE: EJB access over SOAP
Posted by Bernhard Dorninger <be...@scch.at>.
Hi
I also have read the proposal and found it to be very interesting.
Unfortunately my efforts in this direction (use EJBs via SOAP), use things
you declare a no-no.
1. I do not use a service registry , i use jndi names in an URI (e.g.
"urn:MyServices:MyBeanJNDIName") to identify the service (the bean). What's
the problem with using JNDI names? Security?
The bean interfaces have to be available to the clients anyway (method
desc.+params), so why not a JNDI name?
2. I do use special Header Entries in my concept (for carrying Handles over
the network). And I can see your point here, why one should not use header
entries. I too am not very happy with that and considered to encode handles
in an URN.
**Question: Is your suggested encoding of a handle used as NS-URI of the
method? Or is this URI used in the "SOAPAction" Header entry only? **
Since string encoded handles are rather long,I had a problem with both
possibilities, as they make the request look ugly.
Anyway, what you suggest in your section 4, does not appear to be a valid
URN ("urn:SessionService#base64-encoded-serHandle"). typo?
3. I had not considered any special handling to transmit entity bean keys.
findByPrimaryKey is an ordinary home method, therefore its call cann be
encoded like any other method call. Client/Server should of course be
capable of deSerialising Primary key objects .
In addition I think, that clients (any Clients, not just SOAP) should not
work directly with Entity beans. I see them as an abstraction of application
data, with Session beans providing the necessary business interface.
regards
Bernhard
> -----Original Message-----
> From: Paul Fremantle [mailto:pzf@hursley.ibm.com]
> Sent: 15 September 2000 17:13
> To: soap-dev@xml.apache.org
> Subject: EJB access over SOAP
>
>
> Folks,
>
> There has been a number of discussions about EJBs and SOAP
> recently on this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper
> which I would
> love to get some comments on. It isn't perfect, but I'd rather
> get comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
>
> I also have an implementation of this, which is
> sub-classed/extended on the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
>
> Best regards,
>
> Paul Fremantle
>
>
>
RE: EJB access over SOAP
Posted by Bernhard Dorninger <be...@scch.at>.
Hi
I also have read the proposal and found it to be very interesting.
Unfortunately my efforts in this direction (use EJBs via SOAP), use things
you declare a no-no.
1. I do not use a service registry , i use jndi names in an URI (e.g.
"urn:MyServices:MyBeanJNDIName") to identify the service (the bean). What's
the problem with using JNDI names? Security?
The bean interfaces have to be available to the clients anyway (method
desc.+params), so why not a JNDI name?
2. I do use special Header Entries in my concept (for carrying Handles over
the network). And I can see your point here, why one should not use header
entries. I too am not very happy with that and considered to encode handles
in an URN.
**Question: Is your suggested encoding of a handle used as NS-URI of the
method? Or is this URI used in the "SOAPAction" Header entry only? **
Since string encoded handles are rather long,I had a problem with both
possibilities, as they make the request look ugly.
Anyway, what you suggest in your section 4, does not appear to be a valid
URN ("urn:SessionService#base64-encoded-serHandle"). typo?
3. I had not considered any special handling to transmit entity bean keys.
findByPrimaryKey is an ordinary home method, therefore its call cann be
encoded like any other method call. Client/Server should of course be
capable of deSerialising Primary key objects .
In addition I think, that clients (any Clients, not just SOAP) should not
work directly with Entity beans. I see them as an abstraction of application
data, with Session beans providing the necessary business interface.
regards
Bernhard
> -----Original Message-----
> From: Paul Fremantle [mailto:pzf@hursley.ibm.com]
> Sent: 15 September 2000 17:13
> To: soap-dev@xml.apache.org
> Subject: EJB access over SOAP
>
>
> Folks,
>
> There has been a number of discussions about EJBs and SOAP
> recently on this
> list. At least two people/organisations have done some work in this area,
> and I have also spent a long time thinking about this: since SOAP 0.9 came
> out nearly a year ago. I have put together a discussion paper
> which I would
> love to get some comments on. It isn't perfect, but I'd rather
> get comments
> now and improve it with feedback from this list.
>
> In particular I'd like feedback on how this fits with: the implementations
> that others have done, and other object-based systems.
>
> I also have an implementation of this, which is
> sub-classed/extended on the
> SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
> soon. The paper touches on some of the things it implements.
>
> Best regards,
>
> Paul Fremantle
>
>
>
EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Folks,
There has been a number of discussions about EJBs and SOAP recently on this
list. At least two people/organisations have done some work in this area,
and I have also spent a long time thinking about this: since SOAP 0.9 came
out nearly a year ago. I have put together a discussion paper which I would
love to get some comments on. It isn't perfect, but I'd rather get comments
now and improve it with feedback from this list.
In particular I'd like feedback on how this fits with: the implementations
that others have done, and other object-based systems.
I also have an implementation of this, which is sub-classed/extended on the
SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
soon. The paper touches on some of the things it implements.
Best regards,
Paul Fremantle
EJB access over SOAP
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Folks,
There has been a number of discussions about EJBs and SOAP recently on this
list. At least two people/organisations have done some work in this area,
and I have also spent a long time thinking about this: since SOAP 0.9 came
out nearly a year ago. I have put together a discussion paper which I would
love to get some comments on. It isn't perfect, but I'd rather get comments
now and improve it with feedback from this list.
In particular I'd like feedback on how this fits with: the implementations
that others have done, and other object-based systems.
I also have an implementation of this, which is sub-classed/extended on the
SOAP2.0 base. It isn't quite ready for release, but I hope to get it ready
soon. The paper touches on some of the things it implements.
Best regards,
Paul Fremantle
RE: Provider Type of "EJB"
Posted by Bernhard Dorninger <be...@scch.at>.
I'm working on a prototype (for my master thesis), which allows access to
EJB functionality via SOAP messages. I am expecting first stable results at
the beginning of Oct.
The server code I write does not use a ServiceRegistry, it uses JNDI
services of the container to access EJB Homes (SOAPAction is the beans
JNDIname), furthermore it uses serialised EJB Handles in SOAP-Headers to
call methods of EJB Remotes (EJBObjects).
Services shall be accessible through ApacheSOAP generated messages of
course.
I plan to publish all that code, if the company, which induced this project
will let me.
regards
Bernhard
RE: Provider Type of "EJB"
Posted by Bernhard Dorninger <be...@scch.at>.
I'm working on a prototype (for my master thesis), which allows access to
EJB functionality via SOAP messages. I am expecting first stable results at
the beginning of Oct.
The server code I write does not use a ServiceRegistry, it uses JNDI
services of the container to access EJB Homes (SOAPAction is the beans
JNDIname), furthermore it uses serialised EJB Handles in SOAP-Headers to
call methods of EJB Remotes (EJBObjects).
Services shall be accessible through ApacheSOAP generated messages of
course.
I plan to publish all that code, if the company, which induced this project
will let me.
regards
Bernhard
Re: Provider Type of "EJB"
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
The current codebase supports two types of providers: java and script
(some BSF supported scripting language). This definitely needs to be
generalized - its fairly easy to support an interface. The deployment
descriptor's type attribute would be used as a key to find the
appropriate implementation and we would have to make the deployment
descriptor extensible to enable whatever is needed for that type
of deployment.
Any volunteers to do it?
Sanjiva.
----- Original Message -----
From: "Steve Muench" <sm...@us.oracle.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 13, 2000 8:19 PM
Subject: Re: Provider Type of "EJB"
> Vahe,
>
> | string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
> | specific locator having it as an input will be able to find/create the
> | instance of the specific provider. All locators extend one class which
>
> I might be misunderstanding, but doesn't pushing
> smarts into the URN string overload the URN in an
> undesireable way since it ties the public service
> name to its implemenation provider type?
>
> Say you start with a service with URN:
>
> urn:ejb:BuySomeFlowers
>
> then you decide to reimplement without EJB as a plain Java class,
> wouldn't this require the URN to change in your locator
> scheme and force clients requesting the "BuySomeFlowers" web service
> to have to change, too?
>
> I would imagine that some kind of indirect mapping between:
>
> 1. Clean URI/URN that only "smells" of what the service does
> without traces of its implementation/provider-type and
>
> 2. The provider type
>
> would be more desireable.
>
> ______________________________________________________________
> Steve Muench, Lead XML Evangelist & Consulting Product Manager
> BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
> Author "Building Oracle XML Applications", O'Reilly
> http://www.oreilly.com/catalog/orxmlapp/
>
>
>
>
Re: Provider Type of "EJB"
Posted by Vahe Amirbekyan <av...@techone.com>.
Steve,
Steve Muench wrote:
> | string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
> | specific locator having it as an input will be able to find/create the
> | instance of the specific provider. All locators extend one class which
>
> I might be misunderstanding, but doesn't pushing
> smarts into the URN string overload the URN in an
> undesireable way since it ties the public service
> name to its implemenation provider type?
You are absolutely right. The main objective of Locator was exactly
this: separating internal logic/structure of the serves from remote
clients. Perhaps I wasn't very clear here, and also didn't go into
details... What I meant is that the information in the URN is enough for
Locator framework to make the final decision about who is the addressee
of the call. That doesn't mean at all that URN should literally contain
the internal details of the server.
> Say you start with a service with URN:
>
> urn:ejb:BuySomeFlowers
>
> then you decide to reimplement without EJB as a plain Java class,
> wouldn't this require the URN to change in your locator
> scheme and force clients requesting the "BuySomeFlowers" web service
> to have to change, too?
>
> I would imagine that some kind of indirect mapping between:
>
> 1. Clean URI/URN that only "smells" of what the service does
> without traces of its implementation/provider-type and
>
> 2. The provider type
>
> would be more desireable.
That's exactly what we do in the Locator! In the URN we use namespace
part ("external" namespace may be mapped to "internal" one), protocol
part (can be another hint for the server) and the ID part (this can be
something like IOR's opaque object ID part or just a key used in a
rule-based specific locator or anything else). In addition, each part
can be processed by a designated chain of sub-locators. You got a lot of
flexibility in defining how URNs are mapped to server internal objects.
Hope this answers your question, Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: Provider Type of "EJB"
Posted by Vahe Amirbekyan <av...@techone.com>.
Steve,
Steve Muench wrote:
> | string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
> | specific locator having it as an input will be able to find/create the
> | instance of the specific provider. All locators extend one class which
>
> I might be misunderstanding, but doesn't pushing
> smarts into the URN string overload the URN in an
> undesireable way since it ties the public service
> name to its implemenation provider type?
You are absolutely right. The main objective of Locator was exactly
this: separating internal logic/structure of the serves from remote
clients. Perhaps I wasn't very clear here, and also didn't go into
details... What I meant is that the information in the URN is enough for
Locator framework to make the final decision about who is the addressee
of the call. That doesn't mean at all that URN should literally contain
the internal details of the server.
> Say you start with a service with URN:
>
> urn:ejb:BuySomeFlowers
>
> then you decide to reimplement without EJB as a plain Java class,
> wouldn't this require the URN to change in your locator
> scheme and force clients requesting the "BuySomeFlowers" web service
> to have to change, too?
>
> I would imagine that some kind of indirect mapping between:
>
> 1. Clean URI/URN that only "smells" of what the service does
> without traces of its implementation/provider-type and
>
> 2. The provider type
>
> would be more desireable.
That's exactly what we do in the Locator! In the URN we use namespace
part ("external" namespace may be mapped to "internal" one), protocol
part (can be another hint for the server) and the ID part (this can be
something like IOR's opaque object ID part or just a key used in a
rule-based specific locator or anything else). In addition, each part
can be processed by a designated chain of sub-locators. You got a lot of
flexibility in defining how URNs are mapped to server internal objects.
Hope this answers your question, Vahe
--
(\______________________________________________________/)
__|_| 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_)
VB Serializer
Posted by Hai Ning <ni...@vinterprise.com>.
anyone knows about a vb component that does serialization from array
to xml string and vice versa?
or, alternatively, what do you do when you need to return an array from
web service function back to an vb/asp client?
thanks
-harry
VB Serializer
Posted by Hai Ning <ni...@vinterprise.com>.
anyone knows about a vb component that does serialization from array
to xml string and vice versa?
or, alternatively, what do you do when you need to return an array from
web service function back to an vb/asp client?
thanks
-harry
Re: Provider Type of "EJB"
Posted by George I Matkovits <ma...@uswest.net>.
We will be able to do all these things via Web Services Discovery
Descriptors (not too speedily 1st but we could get back URL references also
to EJBs. Please download IBM's Web Services Toolkit from Alphaworks.
Regards - George
Steve Muench wrote:
> Vahe,
>
> | string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
> | specific locator having it as an input will be able to find/create the
> | instance of the specific provider. All locators extend one class which
>
> I might be misunderstanding, but doesn't pushing
> smarts into the URN string overload the URN in an
> undesireable way since it ties the public service
> name to its implemenation provider type?
>
> Say you start with a service with URN:
>
> urn:ejb:BuySomeFlowers
>
> then you decide to reimplement without EJB as a plain Java class,
> wouldn't this require the URN to change in your locator
> scheme and force clients requesting the "BuySomeFlowers" web service
> to have to change, too?
>
> I would imagine that some kind of indirect mapping between:
>
> 1. Clean URI/URN that only "smells" of what the service does
> without traces of its implementation/provider-type and
>
> 2. The provider type
>
> would be more desireable.
>
> ______________________________________________________________
> Steve Muench, Lead XML Evangelist & Consulting Product Manager
> BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
> Author "Building Oracle XML Applications", O'Reilly
> http://www.oreilly.com/catalog/orxmlapp/
Re: Provider Type of "EJB"
Posted by George I Matkovits <ma...@uswest.net>.
We will be able to do all these things via Web Services Discovery
Descriptors (not too speedily 1st but we could get back URL references also
to EJBs. Please download IBM's Web Services Toolkit from Alphaworks.
Regards - George
Steve Muench wrote:
> Vahe,
>
> | string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
> | specific locator having it as an input will be able to find/create the
> | instance of the specific provider. All locators extend one class which
>
> I might be misunderstanding, but doesn't pushing
> smarts into the URN string overload the URN in an
> undesireable way since it ties the public service
> name to its implemenation provider type?
>
> Say you start with a service with URN:
>
> urn:ejb:BuySomeFlowers
>
> then you decide to reimplement without EJB as a plain Java class,
> wouldn't this require the URN to change in your locator
> scheme and force clients requesting the "BuySomeFlowers" web service
> to have to change, too?
>
> I would imagine that some kind of indirect mapping between:
>
> 1. Clean URI/URN that only "smells" of what the service does
> without traces of its implementation/provider-type and
>
> 2. The provider type
>
> would be more desireable.
>
> ______________________________________________________________
> Steve Muench, Lead XML Evangelist & Consulting Product Manager
> BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
> Author "Building Oracle XML Applications", O'Reilly
> http://www.oreilly.com/catalog/orxmlapp/
Re: Provider Type of "EJB"
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
The current codebase supports two types of providers: java and script
(some BSF supported scripting language). This definitely needs to be
generalized - its fairly easy to support an interface. The deployment
descriptor's type attribute would be used as a key to find the
appropriate implementation and we would have to make the deployment
descriptor extensible to enable whatever is needed for that type
of deployment.
Any volunteers to do it?
Sanjiva.
----- Original Message -----
From: "Steve Muench" <sm...@us.oracle.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 13, 2000 8:19 PM
Subject: Re: Provider Type of "EJB"
> Vahe,
>
> | string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
> | specific locator having it as an input will be able to find/create the
> | instance of the specific provider. All locators extend one class which
>
> I might be misunderstanding, but doesn't pushing
> smarts into the URN string overload the URN in an
> undesireable way since it ties the public service
> name to its implemenation provider type?
>
> Say you start with a service with URN:
>
> urn:ejb:BuySomeFlowers
>
> then you decide to reimplement without EJB as a plain Java class,
> wouldn't this require the URN to change in your locator
> scheme and force clients requesting the "BuySomeFlowers" web service
> to have to change, too?
>
> I would imagine that some kind of indirect mapping between:
>
> 1. Clean URI/URN that only "smells" of what the service does
> without traces of its implementation/provider-type and
>
> 2. The provider type
>
> would be more desireable.
>
> ______________________________________________________________
> Steve Muench, Lead XML Evangelist & Consulting Product Manager
> BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
> Author "Building Oracle XML Applications", O'Reilly
> http://www.oreilly.com/catalog/orxmlapp/
>
>
>
>
Re: Provider Type of "EJB"
Posted by Steve Muench <sm...@us.oracle.com>.
Vahe,
| string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
| specific locator having it as an input will be able to find/create the
| instance of the specific provider. All locators extend one class which
I might be misunderstanding, but doesn't pushing
smarts into the URN string overload the URN in an
undesireable way since it ties the public service
name to its implemenation provider type?
Say you start with a service with URN:
urn:ejb:BuySomeFlowers
then you decide to reimplement without EJB as a plain Java class,
wouldn't this require the URN to change in your locator
scheme and force clients requesting the "BuySomeFlowers" web service
to have to change, too?
I would imagine that some kind of indirect mapping between:
1. Clean URI/URN that only "smells" of what the service does
without traces of its implementation/provider-type and
2. The provider type
would be more desireable.
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
Re: Provider Type of "EJB"
Posted by Steve Muench <sm...@us.oracle.com>.
Vahe,
| string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
| specific locator having it as an input will be able to find/create the
| instance of the specific provider. All locators extend one class which
I might be misunderstanding, but doesn't pushing
smarts into the URN string overload the URN in an
undesireable way since it ties the public service
name to its implemenation provider type?
Say you start with a service with URN:
urn:ejb:BuySomeFlowers
then you decide to reimplement without EJB as a plain Java class,
wouldn't this require the URN to change in your locator
scheme and force clients requesting the "BuySomeFlowers" web service
to have to change, too?
I would imagine that some kind of indirect mapping between:
1. Clean URI/URN that only "smells" of what the service does
without traces of its implementation/provider-type and
2. The provider type
would be more desireable.
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
Re: Provider Type of "EJB"
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
The Locator framework is very flexible and you generally can plugin any
type of service provider, providing that it is wrapped in Java. As I
mentioned - Locator is just a (much more) sophisticated class loader.
Basically, the RPCRouter accesses the Locator via interface like:
public interface Locator {
/** Based on the URN, returns an object reference.
*
* @param URNstr The URN of the object.
* @return Object located
* @exception ObjectNotFound - thrown if the object cannot be found
(or created)
* @exception LocatorExceptoion - trown if something went wrong when
attempted to locate
*
*/
public Object getObjectWithName(String URNstr) throws
LocatorException, ObjectNotFound;
}
which hides a (enhanced) chain of responsibility built out from specific
locators (e.g. EJBLocator). If you wish to add a new service provider
(e.g. SP1) you should add a specific locator (e.g. SP1Locator) and plug
it into the chain, and also you should decide on the ID string's (URN
string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
specific locator having it as an input will be able to find/create the
instance of the specific provider. All locators extend one class which
define the basic strategy of "responsibility passing". In most cases
specific kind of locator can be created by just overloading one
inherited (hook) function.
We actually were going to share our locator desigh/code in the next step
(after something is decided with the first portion of code we
contributed a week ago).
Hope this answers your question, Vahe
> > We married the EJB and SOAP by just replacing the RPCRouter's class
> > loader by our Locator framework, which takes the target object ID from
> > the Call and uses it to properly "locate" the target. If it is EJB - it
> > uses the target object ID to tie to the home interface and invoke create
> > on it (the key is also encoded into the object ID). I wrote more in one
> > of my previous messages (thread "Accessing instances in SOAP - ideas?").
> > Feel free to ask me for more details.
> >
> > We do not have any specialized RPCRouter for EJB.
[cut]
>
> Does the Locator framework allow to extend the SOAP handler with additional
> types of service providers? In other words, could I plug in a new type of service
> provider without changing RPCRouter?
>
> Diane
>
> --
> Diane L. Davison
> Portland Development Center
> Oracle Corporation
--
(\______________________________________________________/)
__|_| 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_)
Re: Provider Type of "EJB"
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
The Locator framework is very flexible and you generally can plugin any
type of service provider, providing that it is wrapped in Java. As I
mentioned - Locator is just a (much more) sophisticated class loader.
Basically, the RPCRouter accesses the Locator via interface like:
public interface Locator {
/** Based on the URN, returns an object reference.
*
* @param URNstr The URN of the object.
* @return Object located
* @exception ObjectNotFound - thrown if the object cannot be found
(or created)
* @exception LocatorExceptoion - trown if something went wrong when
attempted to locate
*
*/
public Object getObjectWithName(String URNstr) throws
LocatorException, ObjectNotFound;
}
which hides a (enhanced) chain of responsibility built out from specific
locators (e.g. EJBLocator). If you wish to add a new service provider
(e.g. SP1) you should add a specific locator (e.g. SP1Locator) and plug
it into the chain, and also you should decide on the ID string's (URN
string) format (e.g. urn:sp1:idinfo_enough_to_locate), so that the
specific locator having it as an input will be able to find/create the
instance of the specific provider. All locators extend one class which
define the basic strategy of "responsibility passing". In most cases
specific kind of locator can be created by just overloading one
inherited (hook) function.
We actually were going to share our locator desigh/code in the next step
(after something is decided with the first portion of code we
contributed a week ago).
Hope this answers your question, Vahe
> > We married the EJB and SOAP by just replacing the RPCRouter's class
> > loader by our Locator framework, which takes the target object ID from
> > the Call and uses it to properly "locate" the target. If it is EJB - it
> > uses the target object ID to tie to the home interface and invoke create
> > on it (the key is also encoded into the object ID). I wrote more in one
> > of my previous messages (thread "Accessing instances in SOAP - ideas?").
> > Feel free to ask me for more details.
> >
> > We do not have any specialized RPCRouter for EJB.
[cut]
>
> Does the Locator framework allow to extend the SOAP handler with additional
> types of service providers? In other words, could I plug in a new type of service
> provider without changing RPCRouter?
>
> Diane
>
> --
> Diane L. Davison
> Portland Development Center
> Oracle Corporation
--
(\______________________________________________________/)
__|_| 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_)
Re: Provider Type of "EJB"
Posted by "Diane L. Davison" <Di...@oracle.com>.
Vahe Amirbekyan wrote:
> Hi,
>
> > There are a few ways one could wed SOAP to EJB.
> > Right now we have a "Provider Type" that maps to Java classes
> > and to scripts. One approach would be to extend this to include
> > EJBs and then have a RPCRouterEJB "do the right thing"
> >
> > RPCRouterEJB would probably be an abstract class so the specifics
> > of the EJB call could be easily implemented.
>
> We married the EJB and SOAP by just replacing the RPCRouter's class
> loader by our Locator framework, which takes the target object ID from
> the Call and uses it to properly "locate" the target. If it is EJB - it
> uses the target object ID to tie to the home interface and invoke create
> on it (the key is also encoded into the object ID). I wrote more in one
> of my previous messages (thread "Accessing instances in SOAP - ideas?").
> Feel free to ask me for more details.
>
> We do not have any specialized RPCRouter for EJB.
>
> Hope this helps, Vahe
> --
> (\______________________________________________________/)
> __|_| 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_)
Does the Locator framework allow to extend the SOAP handler with additional
types of service providers? In other words, could I plug in a new type of service
provider without changing RPCRouter?
Diane
--
Diane L. Davison
Portland Development Center
Oracle Corporation
Re: Provider Type of "EJB"
Posted by "Diane L. Davison" <Di...@oracle.com>.
Vahe Amirbekyan wrote:
> Hi,
>
> > There are a few ways one could wed SOAP to EJB.
> > Right now we have a "Provider Type" that maps to Java classes
> > and to scripts. One approach would be to extend this to include
> > EJBs and then have a RPCRouterEJB "do the right thing"
> >
> > RPCRouterEJB would probably be an abstract class so the specifics
> > of the EJB call could be easily implemented.
>
> We married the EJB and SOAP by just replacing the RPCRouter's class
> loader by our Locator framework, which takes the target object ID from
> the Call and uses it to properly "locate" the target. If it is EJB - it
> uses the target object ID to tie to the home interface and invoke create
> on it (the key is also encoded into the object ID). I wrote more in one
> of my previous messages (thread "Accessing instances in SOAP - ideas?").
> Feel free to ask me for more details.
>
> We do not have any specialized RPCRouter for EJB.
>
> Hope this helps, Vahe
> --
> (\______________________________________________________/)
> __|_| 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_)
Does the Locator framework allow to extend the SOAP handler with additional
types of service providers? In other words, could I plug in a new type of service
provider without changing RPCRouter?
Diane
--
Diane L. Davison
Portland Development Center
Oracle Corporation
Re: Provider Type of "EJB"
Posted by Paul Fink <pf...@wamnet.com>.
Sorry I missed the earlier posts. I searched the index for a subject
that contained "EJB" and didn't find any ....
Your approach is very close to what I'm doing. One major difference
is that I had assumed that we would only be accessing sessions beans
and calling methods that may in turn do find's for entity beans.
I'll work on it while and then post my ideas.
Paul
----- Original Message -----
From: "Vahe Amirbekyan" <av...@techone.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 13, 2000 2:43 PM
Subject: Re: Provider Type of "EJB"
> Hi,
>
> > There are a few ways one could wed SOAP to EJB.
> > Right now we have a "Provider Type" that maps to Java classes
> > and to scripts. One approach would be to extend this to include
> > EJBs and then have a RPCRouterEJB "do the right thing"
> >
> > RPCRouterEJB would probably be an abstract class so the specifics
> > of the EJB call could be easily implemented.
>
> We married the EJB and SOAP by just replacing the RPCRouter's class
> loader by our Locator framework, which takes the target object ID from
> the Call and uses it to properly "locate" the target. If it is EJB - it
> uses the target object ID to tie to the home interface and invoke create
> on it (the key is also encoded into the object ID). I wrote more in one
> of my previous messages (thread "Accessing instances in SOAP - ideas?").
> Feel free to ask me for more details.
>
> We do not have any specialized RPCRouter for EJB.
>
> Hope this helps, Vahe
> --
> (\______________________________________________________/)
> __|_| 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_)
>
Re: Provider Type of "EJB"
Posted by Paul Fink <pf...@wamnet.com>.
Sorry I missed the earlier posts. I searched the index for a subject
that contained "EJB" and didn't find any ....
Your approach is very close to what I'm doing. One major difference
is that I had assumed that we would only be accessing sessions beans
and calling methods that may in turn do find's for entity beans.
I'll work on it while and then post my ideas.
Paul
----- Original Message -----
From: "Vahe Amirbekyan" <av...@techone.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 13, 2000 2:43 PM
Subject: Re: Provider Type of "EJB"
> Hi,
>
> > There are a few ways one could wed SOAP to EJB.
> > Right now we have a "Provider Type" that maps to Java classes
> > and to scripts. One approach would be to extend this to include
> > EJBs and then have a RPCRouterEJB "do the right thing"
> >
> > RPCRouterEJB would probably be an abstract class so the specifics
> > of the EJB call could be easily implemented.
>
> We married the EJB and SOAP by just replacing the RPCRouter's class
> loader by our Locator framework, which takes the target object ID from
> the Call and uses it to properly "locate" the target. If it is EJB - it
> uses the target object ID to tie to the home interface and invoke create
> on it (the key is also encoded into the object ID). I wrote more in one
> of my previous messages (thread "Accessing instances in SOAP - ideas?").
> Feel free to ask me for more details.
>
> We do not have any specialized RPCRouter for EJB.
>
> Hope this helps, Vahe
> --
> (\______________________________________________________/)
> __|_| 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_)
>
Re: Provider Type of "EJB"
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
> There are a few ways one could wed SOAP to EJB.
> Right now we have a "Provider Type" that maps to Java classes
> and to scripts. One approach would be to extend this to include
> EJBs and then have a RPCRouterEJB "do the right thing"
>
> RPCRouterEJB would probably be an abstract class so the specifics
> of the EJB call could be easily implemented.
We married the EJB and SOAP by just replacing the RPCRouter's class
loader by our Locator framework, which takes the target object ID from
the Call and uses it to properly "locate" the target. If it is EJB - it
uses the target object ID to tie to the home interface and invoke create
on it (the key is also encoded into the object ID). I wrote more in one
of my previous messages (thread "Accessing instances in SOAP - ideas?").
Feel free to ask me for more details.
We do not have any specialized RPCRouter for EJB.
Hope this helps, Vahe
--
(\______________________________________________________/)
__|_| 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_)
Re: Provider Type of "EJB"
Posted by Paul Fink <pf...@wamnet.com>.
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
> It can be done now. The service class is an ejb proxy that
> knows how to obtain, manage and make calls on the stub.
>
yea but I was after something more general, i.e., no proxy.
Basically I'm talking about what Vahe described in his note. I
have this working for XML-RPC and now that their are several
clients available for SOAP its time to implement it in SOAP.
And since I have some time I thought I could do it in a manner
that others may find useful.
Paul
Re: Provider Type of "EJB"
Posted by George I Matkovits <ma...@uswest.net>.
Thank you. I wrote something like that 6 moths ago for an in-house, dirty SOAP
like https transport. With Java life is much easier and so we have more time to
build monster Web Services. This way we stay employed, the economy goes up and
up until the ICE AGE cometh? (-:
Regards - George
Rich Johns wrote:
> It can be done now. The service class is an ejb proxy that
> knows how to obtain, manage and make calls on the stub.
>
> Paul Fink wrote:
>
> > There are a few ways one could wed SOAP to EJB.
> > Right now we have a "Provider Type" that maps to Java classes
> > and to scripts. One approach would be to extend this to include
> > EJBs and then have a RPCRouterEJB "do the right thing"
> >
> > RPCRouterEJB would probably be an abstract class so the specifics
> > of the EJB call could be easily implemented.
> >
> > Then I have to figure how to map the DD's scope to the bean's lifecycle.
Re: Provider Type of "EJB"
Posted by Paul Fink <pf...@wamnet.com>.
----- Original Message -----
From: "Rich Johns" <rj...@vignette.com>
> It can be done now. The service class is an ejb proxy that
> knows how to obtain, manage and make calls on the stub.
>
yea but I was after something more general, i.e., no proxy.
Basically I'm talking about what Vahe described in his note. I
have this working for XML-RPC and now that their are several
clients available for SOAP its time to implement it in SOAP.
And since I have some time I thought I could do it in a manner
that others may find useful.
Paul
Re: Provider Type of "EJB"
Posted by George I Matkovits <ma...@uswest.net>.
Thank you. I wrote something like that 6 moths ago for an in-house, dirty SOAP
like https transport. With Java life is much easier and so we have more time to
build monster Web Services. This way we stay employed, the economy goes up and
up until the ICE AGE cometh? (-:
Regards - George
Rich Johns wrote:
> It can be done now. The service class is an ejb proxy that
> knows how to obtain, manage and make calls on the stub.
>
> Paul Fink wrote:
>
> > There are a few ways one could wed SOAP to EJB.
> > Right now we have a "Provider Type" that maps to Java classes
> > and to scripts. One approach would be to extend this to include
> > EJBs and then have a RPCRouterEJB "do the right thing"
> >
> > RPCRouterEJB would probably be an abstract class so the specifics
> > of the EJB call could be easily implemented.
> >
> > Then I have to figure how to map the DD's scope to the bean's lifecycle.
Re: Provider Type of "EJB"
Posted by Rich Johns <rj...@vignette.com>.
It can be done now. The service class is an ejb proxy that
knows how to obtain, manage and make calls on the stub.
Paul Fink wrote:
> There are a few ways one could wed SOAP to EJB.
> Right now we have a "Provider Type" that maps to Java classes
> and to scripts. One approach would be to extend this to include
> EJBs and then have a RPCRouterEJB "do the right thing"
>
> RPCRouterEJB would probably be an abstract class so the specifics
> of the EJB call could be easily implemented.
>
> Then I have to figure how to map the DD's scope to the bean's lifecycle.
Re: Provider Type of "EJB"
Posted by Rich Johns <rj...@vignette.com>.
It can be done now. The service class is an ejb proxy that
knows how to obtain, manage and make calls on the stub.
Paul Fink wrote:
> There are a few ways one could wed SOAP to EJB.
> Right now we have a "Provider Type" that maps to Java classes
> and to scripts. One approach would be to extend this to include
> EJBs and then have a RPCRouterEJB "do the right thing"
>
> RPCRouterEJB would probably be an abstract class so the specifics
> of the EJB call could be easily implemented.
>
> Then I have to figure how to map the DD's scope to the bean's lifecycle.
Re: Provider Type of "EJB"
Posted by Steve Muench <sm...@us.oracle.com>.
| There are a few ways one could wed SOAP to EJB.
| Right now we have a "Provider Type" that maps to Java classes
| and to scripts. One approach would be to extend this to include
| EJBs and then have a RPCRouterEJB "do the right thing"
Has anyone considered an abstraction for the provider?
Seems like EJB's would be just one example of useful
additional kinds of SOAP provider implementations.
Would likely impact the deployment descriptor a little
but the abstraction would make Apache SOAP more powerful
to let users plug-in additional provider types that
don't natually fit into the Java or "Script-like-thing"
categories.
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
Re: Provider Type of "EJB"
Posted by Steve Muench <sm...@us.oracle.com>.
| There are a few ways one could wed SOAP to EJB.
| Right now we have a "Provider Type" that maps to Java classes
| and to scripts. One approach would be to extend this to include
| EJBs and then have a RPCRouterEJB "do the right thing"
Has anyone considered an abstraction for the provider?
Seems like EJB's would be just one example of useful
additional kinds of SOAP provider implementations.
Would likely impact the deployment descriptor a little
but the abstraction would make Apache SOAP more powerful
to let users plug-in additional provider types that
don't natually fit into the Java or "Script-like-thing"
categories.
______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/
Re: Provider Type of "EJB"
Posted by Vahe Amirbekyan <av...@techone.com>.
Hi,
> There are a few ways one could wed SOAP to EJB.
> Right now we have a "Provider Type" that maps to Java classes
> and to scripts. One approach would be to extend this to include
> EJBs and then have a RPCRouterEJB "do the right thing"
>
> RPCRouterEJB would probably be an abstract class so the specifics
> of the EJB call could be easily implemented.
We married the EJB and SOAP by just replacing the RPCRouter's class
loader by our Locator framework, which takes the target object ID from
the Call and uses it to properly "locate" the target. If it is EJB - it
uses the target object ID to tie to the home interface and invoke create
on it (the key is also encoded into the object ID). I wrote more in one
of my previous messages (thread "Accessing instances in SOAP - ideas?").
Feel free to ask me for more details.
We do not have any specialized RPCRouter for EJB.
Hope this helps, Vahe
--
(\______________________________________________________/)
__|_| 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_)