You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Dennis Faynberg <de...@nj.paradyne.com> on 2000/10/04 14:50:52 UTC
RMI-SOAP
Hello everyone.
My name is Dennis Faynberg and I work at Paradyne NMS R&D.
We have been developing SOAP like protocol here for over a year now.
First it started out as just a package of native-to-external and vice
versa routines that used XML for external encoding. We used external
encoding on the wire between tiers I and II in our NMS solution.
At that time we used java's RMI for an rpc. Having tones of problems
with performance/scalability issues, we have decided to implement
an RMI "look & feel" object oriented rpc that used XML and HTTP as key
components. From a home project it grew into 2 SVC subtrees.
Quik description:
1)
a) XML v1.0, documents unvalidated.
b) Soap like protocol for data de/encoding.
c) Http as transport.
d) Ldap ACL for security.
e) Stub (no skel) based architecture.
2)
everything from version 1, plus:
a) Auto generated schema via DTDs at compile-time.
b) Auto generated html documentation on the schema at
compile-time.
c) Finer granularity of LDAP ACLs.
d) Remote objects use LDAP to advertize themselfs.
f) Blueprint application (Australian Olives):
f.1) Olive orchard management solution 8-)
(trees grew in much the same fashion as doggies
on screen savers)
f.2) tier I : JSP v1.1 GUI (tested on tomcat).
f.3) tier II: Remote objects (Gardner, Harvester).
Oh yeah, first version was based on java1.1 and second on java2.
For the third version of this package I have convinced my manager
to let us implement SOAP (I mean we do have a working clone)
for the following reasons:
1) I must admit that for a while we (or I mostly) thought
that our stuff was better and we can always
convert xml stream structures form one form
to another with XSL. If content is there
structure is negotiable.
2) We played with IBM SOAP
and really didn't like it (sorry people :-( ).
SOAP protocol itself was completly exposed.
It seemed that for a Simple Object Access Protocol
from a lib user prespective there was nothing
simple about it.
3) RMI is loved by everyone here for it's user accessibility.
A layer of abstraction is hiding of specifics of
transport and marshalling and rpc. Such architecture
greatly reduces user (application developer)
learning curve, allowing him to spend time he is paid
for on business logic code.
4) Observing SOAP's progress as what looks to be a dominating
protocol for XML/HTTP rpc and spending time to understand
Namespace and Scheme specs (just like the rest of the
world we found grave problems with DTD based schemas)
have convinced us that SOAP is the best candidate for
an rpc technology for inter-tier communication.
As our efforts continue we are watching Apache SOAP project and
waiting for Sun Microsystems to say something on this matter (why are they
so quiet?) or deliver a package of their own.
I guess I am writting this letter to ask your opinion
on question of validity of existance of an RMI like layer above SOAP.
Has anyone ever discussed such a thing on this project?
Denn.
Re: RMI-SOAP
Posted by Jacek Kopecky <ja...@idoox.com>.
Hi Dennis. 8-)
You can attend our weekly IRC chats discussing the upcoming 3.0
architecture. Or you can just start hacking on stuff and send patches
in, you would probably get a right to commit quite soon.
What I would suggest is either to participate in the arch talk or
just wait until that's ended, because it seems we want to have a clean
architecture in 3.0.
But generally - do what you feel like doing and send the results
in. 8-)
Regards
Jacek Kopecky
Idoox s.r.o.
On Thu, 5 Oct 2000, Dennisf wrote:
> I would love to. How do I proceed?
>
> George I Matkovits wrote:
>
> > Join the Apache Soap Team. There is lots and lots to do. V3_0 is just
> > starting....................
> > Regards - George
Re: RMI-SOAP
Posted by Jacek Kopecky <ja...@idoox.com>.
Hi Dennis. 8-)
You can attend our weekly IRC chats discussing the upcoming 3.0
architecture. Or you can just start hacking on stuff and send patches
in, you would probably get a right to commit quite soon.
What I would suggest is either to participate in the arch talk or
just wait until that's ended, because it seems we want to have a clean
architecture in 3.0.
But generally - do what you feel like doing and send the results
in. 8-)
Regards
Jacek Kopecky
Idoox s.r.o.
On Thu, 5 Oct 2000, Dennisf wrote:
> I would love to. How do I proceed?
>
> George I Matkovits wrote:
>
> > Join the Apache Soap Team. There is lots and lots to do. V3_0 is just
> > starting....................
> > Regards - George
Re: RMI-SOAP
Posted by Dennisf <de...@nj.paradyne.com>.
I would love to. How do I proceed?
George I Matkovits wrote:
> Join the Apache Soap Team. There is lots and lots to do. V3_0 is just
> starting....................
> Regards - George
>
> Dennis Faynberg wrote:
>
> > Hello everyone.
> > My name is Dennis Faynberg and I work at Paradyne NMS R&D.
> > We have been developing SOAP like protocol here for over a year now.
> > First it started out as just a package of native-to-external and vice
> > versa routines that used XML for external encoding. We used external
> > encoding on the wire between tiers I and II in our NMS solution.
> > At that time we used java's RMI for an rpc. Having tones of problems
> > with performance/scalability issues, we have decided to implement
> > an RMI "look & feel" object oriented rpc that used XML and HTTP as key
> > components. From a home project it grew into 2 SVC subtrees.
> > Quik description:
> > 1)
> > a) XML v1.0, documents unvalidated.
> > b) Soap like protocol for data de/encoding.
> > c) Http as transport.
> > d) Ldap ACL for security.
> > e) Stub (no skel) based architecture.
> > 2)
> > everything from version 1, plus:
> > a) Auto generated schema via DTDs at compile-time.
> > b) Auto generated html documentation on the schema at
> > compile-time.
> > c) Finer granularity of LDAP ACLs.
> > d) Remote objects use LDAP to advertize themselfs.
> > f) Blueprint application (Australian Olives):
> > f.1) Olive orchard management solution 8-)
> > (trees grew in much the same fashion as doggies
> > on screen savers)
> > f.2) tier I : JSP v1.1 GUI (tested on tomcat).
> > f.3) tier II: Remote objects (Gardner, Harvester).
> >
> > Oh yeah, first version was based on java1.1 and second on java2.
> > For the third version of this package I have convinced my manager
> > to let us implement SOAP (I mean we do have a working clone)
> > for the following reasons:
> > 1) I must admit that for a while we (or I mostly) thought
> > that our stuff was better and we can always
> > convert xml stream structures form one form
> > to another with XSL. If content is there
> > structure is negotiable.
> > 2) We played with IBM SOAP
> > and really didn't like it (sorry people :-( ).
> > SOAP protocol itself was completly exposed.
> > It seemed that for a Simple Object Access Protocol
> > from a lib user prespective there was nothing
> > simple about it.
> > 3) RMI is loved by everyone here for it's user accessibility.
> > A layer of abstraction is hiding of specifics of
> > transport and marshalling and rpc. Such architecture
> > greatly reduces user (application developer)
> > learning curve, allowing him to spend time he is paid
> > for on business logic code.
> > 4) Observing SOAP's progress as what looks to be a dominating
> > protocol for XML/HTTP rpc and spending time to understand
> > Namespace and Scheme specs (just like the rest of the
> > world we found grave problems with DTD based schemas)
> > have convinced us that SOAP is the best candidate for
> > an rpc technology for inter-tier communication.
> > As our efforts continue we are watching Apache SOAP project and
> > waiting for Sun Microsystems to say something on this matter (why are they
> > so quiet?) or deliver a package of their own.
> > I guess I am writting this letter to ask your opinion
> > on question of validity of existance of an RMI like layer above SOAP.
> > Has anyone ever discussed such a thing on this project?
> >
> > Denn.
Re: RMI-SOAP
Posted by Dennisf <de...@nj.paradyne.com>.
I would love to. How do I proceed?
George I Matkovits wrote:
> Join the Apache Soap Team. There is lots and lots to do. V3_0 is just
> starting....................
> Regards - George
>
> Dennis Faynberg wrote:
>
> > Hello everyone.
> > My name is Dennis Faynberg and I work at Paradyne NMS R&D.
> > We have been developing SOAP like protocol here for over a year now.
> > First it started out as just a package of native-to-external and vice
> > versa routines that used XML for external encoding. We used external
> > encoding on the wire between tiers I and II in our NMS solution.
> > At that time we used java's RMI for an rpc. Having tones of problems
> > with performance/scalability issues, we have decided to implement
> > an RMI "look & feel" object oriented rpc that used XML and HTTP as key
> > components. From a home project it grew into 2 SVC subtrees.
> > Quik description:
> > 1)
> > a) XML v1.0, documents unvalidated.
> > b) Soap like protocol for data de/encoding.
> > c) Http as transport.
> > d) Ldap ACL for security.
> > e) Stub (no skel) based architecture.
> > 2)
> > everything from version 1, plus:
> > a) Auto generated schema via DTDs at compile-time.
> > b) Auto generated html documentation on the schema at
> > compile-time.
> > c) Finer granularity of LDAP ACLs.
> > d) Remote objects use LDAP to advertize themselfs.
> > f) Blueprint application (Australian Olives):
> > f.1) Olive orchard management solution 8-)
> > (trees grew in much the same fashion as doggies
> > on screen savers)
> > f.2) tier I : JSP v1.1 GUI (tested on tomcat).
> > f.3) tier II: Remote objects (Gardner, Harvester).
> >
> > Oh yeah, first version was based on java1.1 and second on java2.
> > For the third version of this package I have convinced my manager
> > to let us implement SOAP (I mean we do have a working clone)
> > for the following reasons:
> > 1) I must admit that for a while we (or I mostly) thought
> > that our stuff was better and we can always
> > convert xml stream structures form one form
> > to another with XSL. If content is there
> > structure is negotiable.
> > 2) We played with IBM SOAP
> > and really didn't like it (sorry people :-( ).
> > SOAP protocol itself was completly exposed.
> > It seemed that for a Simple Object Access Protocol
> > from a lib user prespective there was nothing
> > simple about it.
> > 3) RMI is loved by everyone here for it's user accessibility.
> > A layer of abstraction is hiding of specifics of
> > transport and marshalling and rpc. Such architecture
> > greatly reduces user (application developer)
> > learning curve, allowing him to spend time he is paid
> > for on business logic code.
> > 4) Observing SOAP's progress as what looks to be a dominating
> > protocol for XML/HTTP rpc and spending time to understand
> > Namespace and Scheme specs (just like the rest of the
> > world we found grave problems with DTD based schemas)
> > have convinced us that SOAP is the best candidate for
> > an rpc technology for inter-tier communication.
> > As our efforts continue we are watching Apache SOAP project and
> > waiting for Sun Microsystems to say something on this matter (why are they
> > so quiet?) or deliver a package of their own.
> > I guess I am writting this letter to ask your opinion
> > on question of validity of existance of an RMI like layer above SOAP.
> > Has anyone ever discussed such a thing on this project?
> >
> > Denn.
Re: RMI-SOAP
Posted by George I Matkovits <ma...@uswest.net>.
Join the Apache Soap Team. There is lots and lots to do. V3_0 is just
starting....................
Regards - George
Dennis Faynberg wrote:
> Hello everyone.
> My name is Dennis Faynberg and I work at Paradyne NMS R&D.
> We have been developing SOAP like protocol here for over a year now.
> First it started out as just a package of native-to-external and vice
> versa routines that used XML for external encoding. We used external
> encoding on the wire between tiers I and II in our NMS solution.
> At that time we used java's RMI for an rpc. Having tones of problems
> with performance/scalability issues, we have decided to implement
> an RMI "look & feel" object oriented rpc that used XML and HTTP as key
> components. From a home project it grew into 2 SVC subtrees.
> Quik description:
> 1)
> a) XML v1.0, documents unvalidated.
> b) Soap like protocol for data de/encoding.
> c) Http as transport.
> d) Ldap ACL for security.
> e) Stub (no skel) based architecture.
> 2)
> everything from version 1, plus:
> a) Auto generated schema via DTDs at compile-time.
> b) Auto generated html documentation on the schema at
> compile-time.
> c) Finer granularity of LDAP ACLs.
> d) Remote objects use LDAP to advertize themselfs.
> f) Blueprint application (Australian Olives):
> f.1) Olive orchard management solution 8-)
> (trees grew in much the same fashion as doggies
> on screen savers)
> f.2) tier I : JSP v1.1 GUI (tested on tomcat).
> f.3) tier II: Remote objects (Gardner, Harvester).
>
> Oh yeah, first version was based on java1.1 and second on java2.
> For the third version of this package I have convinced my manager
> to let us implement SOAP (I mean we do have a working clone)
> for the following reasons:
> 1) I must admit that for a while we (or I mostly) thought
> that our stuff was better and we can always
> convert xml stream structures form one form
> to another with XSL. If content is there
> structure is negotiable.
> 2) We played with IBM SOAP
> and really didn't like it (sorry people :-( ).
> SOAP protocol itself was completly exposed.
> It seemed that for a Simple Object Access Protocol
> from a lib user prespective there was nothing
> simple about it.
> 3) RMI is loved by everyone here for it's user accessibility.
> A layer of abstraction is hiding of specifics of
> transport and marshalling and rpc. Such architecture
> greatly reduces user (application developer)
> learning curve, allowing him to spend time he is paid
> for on business logic code.
> 4) Observing SOAP's progress as what looks to be a dominating
> protocol for XML/HTTP rpc and spending time to understand
> Namespace and Scheme specs (just like the rest of the
> world we found grave problems with DTD based schemas)
> have convinced us that SOAP is the best candidate for
> an rpc technology for inter-tier communication.
> As our efforts continue we are watching Apache SOAP project and
> waiting for Sun Microsystems to say something on this matter (why are they
> so quiet?) or deliver a package of their own.
> I guess I am writting this letter to ask your opinion
> on question of validity of existance of an RMI like layer above SOAP.
> Has anyone ever discussed such a thing on this project?
>
> Denn.
Re: RMI-SOAP
Posted by George I Matkovits <ma...@uswest.net>.
Join the Apache Soap Team. There is lots and lots to do. V3_0 is just
starting....................
Regards - George
Dennis Faynberg wrote:
> Hello everyone.
> My name is Dennis Faynberg and I work at Paradyne NMS R&D.
> We have been developing SOAP like protocol here for over a year now.
> First it started out as just a package of native-to-external and vice
> versa routines that used XML for external encoding. We used external
> encoding on the wire between tiers I and II in our NMS solution.
> At that time we used java's RMI for an rpc. Having tones of problems
> with performance/scalability issues, we have decided to implement
> an RMI "look & feel" object oriented rpc that used XML and HTTP as key
> components. From a home project it grew into 2 SVC subtrees.
> Quik description:
> 1)
> a) XML v1.0, documents unvalidated.
> b) Soap like protocol for data de/encoding.
> c) Http as transport.
> d) Ldap ACL for security.
> e) Stub (no skel) based architecture.
> 2)
> everything from version 1, plus:
> a) Auto generated schema via DTDs at compile-time.
> b) Auto generated html documentation on the schema at
> compile-time.
> c) Finer granularity of LDAP ACLs.
> d) Remote objects use LDAP to advertize themselfs.
> f) Blueprint application (Australian Olives):
> f.1) Olive orchard management solution 8-)
> (trees grew in much the same fashion as doggies
> on screen savers)
> f.2) tier I : JSP v1.1 GUI (tested on tomcat).
> f.3) tier II: Remote objects (Gardner, Harvester).
>
> Oh yeah, first version was based on java1.1 and second on java2.
> For the third version of this package I have convinced my manager
> to let us implement SOAP (I mean we do have a working clone)
> for the following reasons:
> 1) I must admit that for a while we (or I mostly) thought
> that our stuff was better and we can always
> convert xml stream structures form one form
> to another with XSL. If content is there
> structure is negotiable.
> 2) We played with IBM SOAP
> and really didn't like it (sorry people :-( ).
> SOAP protocol itself was completly exposed.
> It seemed that for a Simple Object Access Protocol
> from a lib user prespective there was nothing
> simple about it.
> 3) RMI is loved by everyone here for it's user accessibility.
> A layer of abstraction is hiding of specifics of
> transport and marshalling and rpc. Such architecture
> greatly reduces user (application developer)
> learning curve, allowing him to spend time he is paid
> for on business logic code.
> 4) Observing SOAP's progress as what looks to be a dominating
> protocol for XML/HTTP rpc and spending time to understand
> Namespace and Scheme specs (just like the rest of the
> world we found grave problems with DTD based schemas)
> have convinced us that SOAP is the best candidate for
> an rpc technology for inter-tier communication.
> As our efforts continue we are watching Apache SOAP project and
> waiting for Sun Microsystems to say something on this matter (why are they
> so quiet?) or deliver a package of their own.
> I guess I am writting this letter to ask your opinion
> on question of validity of existance of an RMI like layer above SOAP.
> Has anyone ever discussed such a thing on this project?
>
> Denn.