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 Jackson George <Ja...@necx.com> on 2000/09/06 17:31:43 UTC
Jackson : How to Write the Server Side SOAP servlet to Communicat
e to the the STOCK Quote
Hi
We are trying to implement SOAP with Java, But for 'stockquoteClient' ,
how to write
a Java Servlet that could communicate to the EJB and Call a Method, What I
have to do for this
Server side Servlet. I know that Using RMI-from this Servlet I could
communicate to the EJB.
But Anybody COULD PLEASE send me a Step by step Instructions How to set up
the Client
and How set-up the SOAP server , Please send me the Code too.
http://www.xmethods.com/detail.html?id=2\
I am a beginner in SOAP, Just a Beginner Hope you could help me
Appreciate , Thanks in advance
Jackson George
jgeorge@necx.com
-----------------------------------
-----Original Message-----
From: Jacek Kopecky [mailto:jacek@idoox.com]
Sent: Tuesday, September 05, 2000 6:39 PM
To: 'soap-dev@xml.apache.org'
Subject: RE: IRC log
Just a few quick remarks before I go to sleep. 8-)
I first read the SOAP spec. early this summer and having forgotten
some details since then I thought SOAPAction should accompany every
SOAP request message. Today's discussion under this subject has lead
me to deciding to forget about the SOAPAction header entirely because
it's useless unless I want to have routing before processing, but even
then I can do that using different urls.
I used SOAPAction header for differentiating between instances. Using
SOAPAction or even the URL for that purpose means showing that the
instances are really different, but the main reason I used that over
information in headers is that you can send _the_same_message_ to
different addresses in order to request a service from different
instances. Otherwise (putting the instance identifier into a header or
even into the body) would feel like a good ole C style:
method(object, param, param, param)
instead of
object->method(param, param, param).
Thinking about it now leads me to the conclusion, though, that that's
what headers were created for.
James proposes to use the body's namespace to do the differentiation
of services (I'll talk about instances later) but that's feasible if
it's you who creates the service description. If you get a service
description and want to comply to it relying only on namespaces won't
do if the creator of that description put all the messages into a
single namespace. So as Glen just wrote (I just received his mail on
that) you generally have be ready to dispatch on the QName of the body
element or more.
And using namespaces to differentiate between instances is IMO
completely wrong because this way the whole body would have to change
when sending to a different instance. That just feels wrong (I lack
the vocabulary at this hour).
Now to the local/global handlers: why differentiate? If this
differentiation means only either mentioning the class in a
message-specific section of the configuration or in the fallback
section. then that's OK. And we could even have a whole configuration
tree where there would be classes of services and classes of classes
etc. and the root - the last fallback.
As for the xsi:type issue: what James proposes seems great to me with
only one exception: Why not use the same solution on the client side -
instead of only defaulting to strings (which could be useful on either
side if no type mapping is given) the client could specify the mapping
as well. I don't think Deployment Description should only be
understood as a static file - an equivalent can be given to the
client-side SOAP tools during the client set-up. 8-)
BTW: defaulting to strings is what we do in our lower (non-SCL) layer
in IdooXoap anyway.
Now lemme go home. 8-)
Jacek Kopecky
Idoox s.r.o.
On Tue, 5 Sep 2000, James Snell wrote:
> Alrighty... good conversation... sorry I missed it... on a short break so
> lemme see if I can't offer some comment on the discussion.
>
> >From what I gathered, the basic gist of the technical conversation was
how
> to map Messages to Services in terms of the Service Description API.
>
> First of all, I absolutely concur that a standardize API is required for
> service descriptions, irregardless of the actual grammar that is used.
The
> Service Description architecture should also consist of a plugable
approach
> that would allow for multiple service description language processors.
>
> In terms of how a message gets dispatched, I was imagining a URI-based
> approach based around the relationship of Ports/Bindings/Messages.
>
> Basically, a server exposes X number of ports. Each Port exposes Y
number
> of bindings, A binding implements Z number of Message Handlers (e.g. "A
> MESSAGE HANDLER is BOUND to PORT ABC").
>
> If you look at SCL (for example), Messages are defined, then grouped
> according to the ports that they are bound to. The public service
> description would include this information.
>
> Internally, we would keep a separate configuration file that would map
the
> Port Message Bindings to particular software components. Does that make
> sense?
>
> How the processor makes the leap (from receiving a message to knowing
which
> Port and Binding to dispatch it to) is by parsing the namespace for the
> message. Essentially, the namespace for the payload (the message) would
be
> defined as the URI of the server + the port name + the binding name + the
> message name:
>
> For example:
>
> http://soap.acmeco.com/portname/bindingname#messagetype
>
>
> The SOAPAction header (according to the spec) is only available for the
HTTP
> binding. Or at least, that is the only context in which it is used...
there
> is no explicit statement forbidding its use in other bindings, however,
at
> the same time there is no explicit statement allowing its use either,
> meaning that it should not be relied upon for any other transport
binding.
>
> The only other way to uniquely identify a message and link it to a
> particular port binding is through a unique namespace identifier. Since
the
> namespace is based on the port and binding names, the server processor
could
> absolutely identify and route the message accordingly.
>
> In summary, we would have a public service description and a private
> configuration file. The service description would instruct the client
how
> to build the request, including which namespace to use for the request.
The
> configuration file would map the namespaces to one or more message
handlers.
>
>
> The same basic technique can be used for header processing. The headers
can
> be uniquely identified by namespace, with the configuration file
providing
> the mapping information that tells the processor how to handle it.
>
> Different services can map the same headers differently by employing a
> different Namespace URI.
>
> For example:
>
> http://soap.acmeco.com/someheader/#1
> http://soap.acmeco.com/someheader/#2
>
> Or something along these lines.
>
> Does that make any sense? I could be way off here, so if I am, just give
me
> a virtual boot-to-the-head and set me straight :-)
>
> A couple of other comments:
>
> We would need a distinction between the following types of components:
>
> 1. Local Message Handlers
> A Message Handler is designed to handle the specific processing
> requirements of a single type of message bound to a single port.
>
> 2. Global Message Handlers
> A Global Message Handler is a SOAP Processor plugin designed to
handle
> a particular type of message no matter which port it is assigned to.
> Essentially, when a message is received and routed to a particular port,
the
> processor would first look to see if a Local Message Handler exists for
that
> message at that port, and if not, the processor would then query the
Global
> Message Handler registry to see if a global message handler has been
defined
> for that type of message. I haven't worked out all of the details for
this
> yet, so please be patient. These would include support for some kind of
> transaction based messaging architecture, etc that would be considered
> global for all services.
>
> 3. Message Specific Header Handlers
> A Message Specific Header Handler is a header handler specifically
> designed to provide context to the Local Message Handlers. This would
> include security/etc implemented for just a single service.
>
> 4. Global Header Handlers
> Global Header Handlers are handlers designed to handle specific
types
> of headers irregardless of the message they accompany. This would
include
> security/etc implemented across all services, etc.
>
> 5. Processor Plugins
> Processor Plugins are code components that layer in new
functionality
> to the processor that is completely independent of messages or headers.
> These would include such facilities as Logging, global transforms, etc.
>
>
> As for the existing xsi:type issue, why not just add the ability for a
> developer to map each parameter in the call to a specific xsi:type value
and
> store that in the deployment descriptor? When a call is received that
does
> not include those values, then query the deployment descriptor and
retrieve
> them from there. This would work great for the server side. As for the
> client side, I would say that if a response is received without the
> xsi:types, default each to string values. It's not the perfect approach,
> but it would work. And if we are planning a rewrite based around service
> descriptions anyway, doesn't it make sense to punt in the short term and
do
> it right the next go around? Again, I may be way off, but to me, I think
> that this is a valid approach to take.
>
> Let's see... anything else ((james is switching back and forth between
the
> log and the email...))
>
> Oh yeah.... using the Service Description API, we can transform the
internal
> configuration file automatically to whichever Service Description Grammar
is
> needed... again, I haven't worked out all the details on this yet, but,
in
> theory it sounds logical.
>
> Oh and Glen... if you plan on going further south (Fresno area) on your
> vacation, drop me a line. :-)
>
> - James
>
============================================================================
This message is intended only for the use of the Addressee(s) and may
contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
the intended recipient, dissemination of this communication is prohibited.
If you have received this communication in error, please erase all copies
of the message and its attachments and notify postmaster@verticalnet.com
immediately.
============================================================================
RE: Accessing instances in SOAP - ideas?
Posted by Ara Kassabian <ar...@techone.com>.
Oops! I take it back. We have NOT submitted it yet (we submitted a message
transformer framework). But we should be soon (You can talk to Vahe to find
out more in the meantime--avahe@techone.com).
----------------------------------------------
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: Ara Kassabian [mailto:ara@techone.com]
Sent: Wednesday, September 06, 2000 2:06 PM
To: soap-dev@xml.apache.org; Jackson.George@necx.com;
pzf@hursley.ibm.com
Cc: Vahe Amirbekyan
Subject: RE: Accessing instances in SOAP - ideas?
We have actually implemented a locator framework to handle the situation you
are referring to. The code was submitted to the SOAP mailing list a few days
ago. This is part of our larger XML messaging strategy. If you are
interested in further details, I suggest you take a look at the code and/or
contact us directly (Note: The code was submitted by Vahe Amirbekyan
(avahe@techone.com), in case you want to do a search through the archive).
----------------------------------------------
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: Paul Fremantle [mailto:pzf@hursley.ibm.com]
Sent: Wednesday, September 06, 2000 1:12 PM
To: soap-dev@xml.apache.org; Jackson.George@necx.com
Subject: Accessing instances in SOAP - ideas?
Jackson, SOAP gurus!
I've been thinking about this (how to specify instances) for EJB instances.
I've come up with two approaches. One is to call the EJB home to get the a
URI for the instance. This has the benefit of not requiring special headers.
The other is to put an instance identifier in a header. I'm interested in
comments on both approaches, and any other approaches?
I've prototyped both, and the Java Apache client code in each case is ok. I
haven't really thought through lightweight clients and other clients.
Regards,
Paul
----- Original Message -----
From: "Jackson George" <Ja...@necx.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 06, 2000 4:31 PM
Subject: Jackson : How to Write the Server Side SOAP servlet to Communicate
to the the STOCK Quote
>
>
> Hi
> We are trying to implement SOAP with Java, But for 'stockquoteClient'
,
> how to write
> a Java Servlet that could communicate to the EJB and Call a Method, What
I
> have to do for this
> Server side Servlet. I know that Using RMI-from this Servlet I could
> communicate to the EJB.
> But Anybody COULD PLEASE send me a Step by step Instructions How to set
up
> the Client
> and How set-up the SOAP server , Please send me the Code too.
>
> http://www.xmethods.com/detail.html?id=2\
>
> I am a beginner in SOAP, Just a Beginner Hope you could help me
> Appreciate , Thanks in advance
> Jackson George
> jgeorge@necx.com
>
> -----------------------------------
>
> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Tuesday, September 05, 2000 6:39 PM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: IRC log
>
>
> Just a few quick remarks before I go to sleep. 8-)
>
> I first read the SOAP spec. early this summer and having forgotten
> some details since then I thought SOAPAction should accompany every
> SOAP request message. Today's discussion under this subject has lead
> me to deciding to forget about the SOAPAction header entirely because
> it's useless unless I want to have routing before processing, but even
> then I can do that using different urls.
>
> I used SOAPAction header for differentiating between instances. Using
> SOAPAction or even the URL for that purpose means showing that the
> instances are really different, but the main reason I used that over
> information in headers is that you can send _the_same_message_ to
> different addresses in order to request a service from different
> instances. Otherwise (putting the instance identifier into a header or
> even into the body) would feel like a good ole C style:
>
> method(object, param, param, param)
>
> instead of
>
> object->method(param, param, param).
>
> Thinking about it now leads me to the conclusion, though, that that's
> what headers were created for.
>
> James proposes to use the body's namespace to do the differentiation
> of services (I'll talk about instances later) but that's feasible if
> it's you who creates the service description. If you get a service
> description and want to comply to it relying only on namespaces won't
> do if the creator of that description put all the messages into a
> single namespace. So as Glen just wrote (I just received his mail on
> that) you generally have be ready to dispatch on the QName of the body
> element or more.
>
> And using namespaces to differentiate between instances is IMO
> completely wrong because this way the whole body would have to change
> when sending to a different instance. That just feels wrong (I lack
> the vocabulary at this hour).
>
> Now to the local/global handlers: why differentiate? If this
> differentiation means only either mentioning the class in a
> message-specific section of the configuration or in the fallback
> section. then that's OK. And we could even have a whole configuration
> tree where there would be classes of services and classes of classes
> etc. and the root - the last fallback.
>
> As for the xsi:type issue: what James proposes seems great to me with
> only one exception: Why not use the same solution on the client side -
> instead of only defaulting to strings (which could be useful on either
> side if no type mapping is given) the client could specify the mapping
> as well. I don't think Deployment Description should only be
> understood as a static file - an equivalent can be given to the
> client-side SOAP tools during the client set-up. 8-)
>
> BTW: defaulting to strings is what we do in our lower (non-SCL) layer
> in IdooXoap anyway.
>
> Now lemme go home. 8-)
>
> Jacek Kopecky
> Idoox s.r.o.
>
>
>
> On Tue, 5 Sep 2000, James Snell wrote:
>
> > Alrighty... good conversation... sorry I missed it... on a short break
so
> > lemme see if I can't offer some comment on the discussion.
> >
> > >From what I gathered, the basic gist of the technical conversation was
> how
> > to map Messages to Services in terms of the Service Description API.
> >
> > First of all, I absolutely concur that a standardize API is required
for
> > service descriptions, irregardless of the actual grammar that is used.
> The
> > Service Description architecture should also consist of a plugable
> approach
> > that would allow for multiple service description language processors.
> >
> > In terms of how a message gets dispatched, I was imagining a URI-based
> > approach based around the relationship of Ports/Bindings/Messages.
> >
> > Basically, a server exposes X number of ports. Each Port exposes Y
> number
> > of bindings, A binding implements Z number of Message Handlers (e.g.
"A
> > MESSAGE HANDLER is BOUND to PORT ABC").
> >
> > If you look at SCL (for example), Messages are defined, then grouped
> > according to the ports that they are bound to. The public service
> > description would include this information.
> >
> > Internally, we would keep a separate configuration file that would map
> the
> > Port Message Bindings to particular software components. Does that
make
> > sense?
> >
> > How the processor makes the leap (from receiving a message to knowing
> which
> > Port and Binding to dispatch it to) is by parsing the namespace for the
> > message. Essentially, the namespace for the payload (the message)
would
> be
> > defined as the URI of the server + the port name + the binding name +
the
> > message name:
> >
> > For example:
> >
> > http://soap.acmeco.com/portname/bindingname#messagetype
> >
> >
> > The SOAPAction header (according to the spec) is only available for the
> HTTP
> > binding. Or at least, that is the only context in which it is used...
> there
> > is no explicit statement forbidding its use in other bindings, however,
> at
> > the same time there is no explicit statement allowing its use either,
> > meaning that it should not be relied upon for any other transport
> binding.
> >
> > The only other way to uniquely identify a message and link it to a
> > particular port binding is through a unique namespace identifier.
Since
> the
> > namespace is based on the port and binding names, the server processor
> could
> > absolutely identify and route the message accordingly.
> >
> > In summary, we would have a public service description and a private
> > configuration file. The service description would instruct the client
> how
> > to build the request, including which namespace to use for the request.
> The
> > configuration file would map the namespaces to one or more message
> handlers.
> >
> >
> > The same basic technique can be used for header processing. The
headers
> can
> > be uniquely identified by namespace, with the configuration file
> providing
> > the mapping information that tells the processor how to handle it.
> >
> > Different services can map the same headers differently by employing a
> > different Namespace URI.
> >
> > For example:
> >
> > http://soap.acmeco.com/someheader/#1
> > http://soap.acmeco.com/someheader/#2
> >
> > Or something along these lines.
> >
> > Does that make any sense? I could be way off here, so if I am, just
give
> me
> > a virtual boot-to-the-head and set me straight :-)
> >
> > A couple of other comments:
> >
> > We would need a distinction between the following types of components:
> >
> > 1. Local Message Handlers
> > A Message Handler is designed to handle the specific processing
> > requirements of a single type of message bound to a single port.
> >
> > 2. Global Message Handlers
> > A Global Message Handler is a SOAP Processor plugin designed to
> handle
> > a particular type of message no matter which port it is assigned to.
> > Essentially, when a message is received and routed to a particular
port,
> the
> > processor would first look to see if a Local Message Handler exists for
> that
> > message at that port, and if not, the processor would then query the
> Global
> > Message Handler registry to see if a global message handler has been
> defined
> > for that type of message. I haven't worked out all of the details for
> this
> > yet, so please be patient. These would include support for some kind
of
> > transaction based messaging architecture, etc that would be considered
> > global for all services.
> >
> > 3. Message Specific Header Handlers
> > A Message Specific Header Handler is a header handler
specifically
> > designed to provide context to the Local Message Handlers. This would
> > include security/etc implemented for just a single service.
> >
> > 4. Global Header Handlers
> > Global Header Handlers are handlers designed to handle specific
> types
> > of headers irregardless of the message they accompany. This would
> include
> > security/etc implemented across all services, etc.
> >
> > 5. Processor Plugins
> > Processor Plugins are code components that layer in new
> functionality
> > to the processor that is completely independent of messages or headers.
> > These would include such facilities as Logging, global transforms, etc.
> >
> >
> > As for the existing xsi:type issue, why not just add the ability for a
> > developer to map each parameter in the call to a specific xsi:type
value
> and
> > store that in the deployment descriptor? When a call is received that
> does
> > not include those values, then query the deployment descriptor and
> retrieve
> > them from there. This would work great for the server side. As for
the
> > client side, I would say that if a response is received without the
> > xsi:types, default each to string values. It's not the perfect
approach,
> > but it would work. And if we are planning a rewrite based around
service
> > descriptions anyway, doesn't it make sense to punt in the short term
and
> do
> > it right the next go around? Again, I may be way off, but to me, I
think
> > that this is a valid approach to take.
> >
> > Let's see... anything else ((james is switching back and forth between
> the
> > log and the email...))
> >
> > Oh yeah.... using the Service Description API, we can transform the
> internal
> > configuration file automatically to whichever Service Description
Grammar
> is
> > needed... again, I haven't worked out all the details on this yet, but,
> in
> > theory it sounds logical.
> >
> > Oh and Glen... if you plan on going further south (Fresno area) on your
> > vacation, drop me a line. :-)
> >
> > - James
> >
>
>
>
>
============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
>
============================================================================
>
RE: Accessing instances in SOAP - ideas?
Posted by Ara Kassabian <ar...@techone.com>.
Oops! I take it back. We have NOT submitted it yet (we submitted a message
transformer framework). But we should be soon (You can talk to Vahe to find
out more in the meantime--avahe@techone.com).
----------------------------------------------
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: Ara Kassabian [mailto:ara@techone.com]
Sent: Wednesday, September 06, 2000 2:06 PM
To: soap-dev@xml.apache.org; Jackson.George@necx.com;
pzf@hursley.ibm.com
Cc: Vahe Amirbekyan
Subject: RE: Accessing instances in SOAP - ideas?
We have actually implemented a locator framework to handle the situation you
are referring to. The code was submitted to the SOAP mailing list a few days
ago. This is part of our larger XML messaging strategy. If you are
interested in further details, I suggest you take a look at the code and/or
contact us directly (Note: The code was submitted by Vahe Amirbekyan
(avahe@techone.com), in case you want to do a search through the archive).
----------------------------------------------
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: Paul Fremantle [mailto:pzf@hursley.ibm.com]
Sent: Wednesday, September 06, 2000 1:12 PM
To: soap-dev@xml.apache.org; Jackson.George@necx.com
Subject: Accessing instances in SOAP - ideas?
Jackson, SOAP gurus!
I've been thinking about this (how to specify instances) for EJB instances.
I've come up with two approaches. One is to call the EJB home to get the a
URI for the instance. This has the benefit of not requiring special headers.
The other is to put an instance identifier in a header. I'm interested in
comments on both approaches, and any other approaches?
I've prototyped both, and the Java Apache client code in each case is ok. I
haven't really thought through lightweight clients and other clients.
Regards,
Paul
----- Original Message -----
From: "Jackson George" <Ja...@necx.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 06, 2000 4:31 PM
Subject: Jackson : How to Write the Server Side SOAP servlet to Communicate
to the the STOCK Quote
>
>
> Hi
> We are trying to implement SOAP with Java, But for 'stockquoteClient'
,
> how to write
> a Java Servlet that could communicate to the EJB and Call a Method, What
I
> have to do for this
> Server side Servlet. I know that Using RMI-from this Servlet I could
> communicate to the EJB.
> But Anybody COULD PLEASE send me a Step by step Instructions How to set
up
> the Client
> and How set-up the SOAP server , Please send me the Code too.
>
> http://www.xmethods.com/detail.html?id=2\
>
> I am a beginner in SOAP, Just a Beginner Hope you could help me
> Appreciate , Thanks in advance
> Jackson George
> jgeorge@necx.com
>
> -----------------------------------
>
> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Tuesday, September 05, 2000 6:39 PM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: IRC log
>
>
> Just a few quick remarks before I go to sleep. 8-)
>
> I first read the SOAP spec. early this summer and having forgotten
> some details since then I thought SOAPAction should accompany every
> SOAP request message. Today's discussion under this subject has lead
> me to deciding to forget about the SOAPAction header entirely because
> it's useless unless I want to have routing before processing, but even
> then I can do that using different urls.
>
> I used SOAPAction header for differentiating between instances. Using
> SOAPAction or even the URL for that purpose means showing that the
> instances are really different, but the main reason I used that over
> information in headers is that you can send _the_same_message_ to
> different addresses in order to request a service from different
> instances. Otherwise (putting the instance identifier into a header or
> even into the body) would feel like a good ole C style:
>
> method(object, param, param, param)
>
> instead of
>
> object->method(param, param, param).
>
> Thinking about it now leads me to the conclusion, though, that that's
> what headers were created for.
>
> James proposes to use the body's namespace to do the differentiation
> of services (I'll talk about instances later) but that's feasible if
> it's you who creates the service description. If you get a service
> description and want to comply to it relying only on namespaces won't
> do if the creator of that description put all the messages into a
> single namespace. So as Glen just wrote (I just received his mail on
> that) you generally have be ready to dispatch on the QName of the body
> element or more.
>
> And using namespaces to differentiate between instances is IMO
> completely wrong because this way the whole body would have to change
> when sending to a different instance. That just feels wrong (I lack
> the vocabulary at this hour).
>
> Now to the local/global handlers: why differentiate? If this
> differentiation means only either mentioning the class in a
> message-specific section of the configuration or in the fallback
> section. then that's OK. And we could even have a whole configuration
> tree where there would be classes of services and classes of classes
> etc. and the root - the last fallback.
>
> As for the xsi:type issue: what James proposes seems great to me with
> only one exception: Why not use the same solution on the client side -
> instead of only defaulting to strings (which could be useful on either
> side if no type mapping is given) the client could specify the mapping
> as well. I don't think Deployment Description should only be
> understood as a static file - an equivalent can be given to the
> client-side SOAP tools during the client set-up. 8-)
>
> BTW: defaulting to strings is what we do in our lower (non-SCL) layer
> in IdooXoap anyway.
>
> Now lemme go home. 8-)
>
> Jacek Kopecky
> Idoox s.r.o.
>
>
>
> On Tue, 5 Sep 2000, James Snell wrote:
>
> > Alrighty... good conversation... sorry I missed it... on a short break
so
> > lemme see if I can't offer some comment on the discussion.
> >
> > >From what I gathered, the basic gist of the technical conversation was
> how
> > to map Messages to Services in terms of the Service Description API.
> >
> > First of all, I absolutely concur that a standardize API is required
for
> > service descriptions, irregardless of the actual grammar that is used.
> The
> > Service Description architecture should also consist of a plugable
> approach
> > that would allow for multiple service description language processors.
> >
> > In terms of how a message gets dispatched, I was imagining a URI-based
> > approach based around the relationship of Ports/Bindings/Messages.
> >
> > Basically, a server exposes X number of ports. Each Port exposes Y
> number
> > of bindings, A binding implements Z number of Message Handlers (e.g.
"A
> > MESSAGE HANDLER is BOUND to PORT ABC").
> >
> > If you look at SCL (for example), Messages are defined, then grouped
> > according to the ports that they are bound to. The public service
> > description would include this information.
> >
> > Internally, we would keep a separate configuration file that would map
> the
> > Port Message Bindings to particular software components. Does that
make
> > sense?
> >
> > How the processor makes the leap (from receiving a message to knowing
> which
> > Port and Binding to dispatch it to) is by parsing the namespace for the
> > message. Essentially, the namespace for the payload (the message)
would
> be
> > defined as the URI of the server + the port name + the binding name +
the
> > message name:
> >
> > For example:
> >
> > http://soap.acmeco.com/portname/bindingname#messagetype
> >
> >
> > The SOAPAction header (according to the spec) is only available for the
> HTTP
> > binding. Or at least, that is the only context in which it is used...
> there
> > is no explicit statement forbidding its use in other bindings, however,
> at
> > the same time there is no explicit statement allowing its use either,
> > meaning that it should not be relied upon for any other transport
> binding.
> >
> > The only other way to uniquely identify a message and link it to a
> > particular port binding is through a unique namespace identifier.
Since
> the
> > namespace is based on the port and binding names, the server processor
> could
> > absolutely identify and route the message accordingly.
> >
> > In summary, we would have a public service description and a private
> > configuration file. The service description would instruct the client
> how
> > to build the request, including which namespace to use for the request.
> The
> > configuration file would map the namespaces to one or more message
> handlers.
> >
> >
> > The same basic technique can be used for header processing. The
headers
> can
> > be uniquely identified by namespace, with the configuration file
> providing
> > the mapping information that tells the processor how to handle it.
> >
> > Different services can map the same headers differently by employing a
> > different Namespace URI.
> >
> > For example:
> >
> > http://soap.acmeco.com/someheader/#1
> > http://soap.acmeco.com/someheader/#2
> >
> > Or something along these lines.
> >
> > Does that make any sense? I could be way off here, so if I am, just
give
> me
> > a virtual boot-to-the-head and set me straight :-)
> >
> > A couple of other comments:
> >
> > We would need a distinction between the following types of components:
> >
> > 1. Local Message Handlers
> > A Message Handler is designed to handle the specific processing
> > requirements of a single type of message bound to a single port.
> >
> > 2. Global Message Handlers
> > A Global Message Handler is a SOAP Processor plugin designed to
> handle
> > a particular type of message no matter which port it is assigned to.
> > Essentially, when a message is received and routed to a particular
port,
> the
> > processor would first look to see if a Local Message Handler exists for
> that
> > message at that port, and if not, the processor would then query the
> Global
> > Message Handler registry to see if a global message handler has been
> defined
> > for that type of message. I haven't worked out all of the details for
> this
> > yet, so please be patient. These would include support for some kind
of
> > transaction based messaging architecture, etc that would be considered
> > global for all services.
> >
> > 3. Message Specific Header Handlers
> > A Message Specific Header Handler is a header handler
specifically
> > designed to provide context to the Local Message Handlers. This would
> > include security/etc implemented for just a single service.
> >
> > 4. Global Header Handlers
> > Global Header Handlers are handlers designed to handle specific
> types
> > of headers irregardless of the message they accompany. This would
> include
> > security/etc implemented across all services, etc.
> >
> > 5. Processor Plugins
> > Processor Plugins are code components that layer in new
> functionality
> > to the processor that is completely independent of messages or headers.
> > These would include such facilities as Logging, global transforms, etc.
> >
> >
> > As for the existing xsi:type issue, why not just add the ability for a
> > developer to map each parameter in the call to a specific xsi:type
value
> and
> > store that in the deployment descriptor? When a call is received that
> does
> > not include those values, then query the deployment descriptor and
> retrieve
> > them from there. This would work great for the server side. As for
the
> > client side, I would say that if a response is received without the
> > xsi:types, default each to string values. It's not the perfect
approach,
> > but it would work. And if we are planning a rewrite based around
service
> > descriptions anyway, doesn't it make sense to punt in the short term
and
> do
> > it right the next go around? Again, I may be way off, but to me, I
think
> > that this is a valid approach to take.
> >
> > Let's see... anything else ((james is switching back and forth between
> the
> > log and the email...))
> >
> > Oh yeah.... using the Service Description API, we can transform the
> internal
> > configuration file automatically to whichever Service Description
Grammar
> is
> > needed... again, I haven't worked out all the details on this yet, but,
> in
> > theory it sounds logical.
> >
> > Oh and Glen... if you plan on going further south (Fresno area) on your
> > vacation, drop me a line. :-)
> >
> > - James
> >
>
>
>
>
============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
>
============================================================================
>
RE: Accessing instances in SOAP - ideas?
Posted by Ara Kassabian <ar...@techone.com>.
We have actually implemented a locator framework to handle the situation you
are referring to. The code was submitted to the SOAP mailing list a few days
ago. This is part of our larger XML messaging strategy. If you are
interested in further details, I suggest you take a look at the code and/or
contact us directly (Note: The code was submitted by Vahe Amirbekyan
(avahe@techone.com), in case you want to do a search through the archive).
----------------------------------------------
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: Paul Fremantle [mailto:pzf@hursley.ibm.com]
Sent: Wednesday, September 06, 2000 1:12 PM
To: soap-dev@xml.apache.org; Jackson.George@necx.com
Subject: Accessing instances in SOAP - ideas?
Jackson, SOAP gurus!
I've been thinking about this (how to specify instances) for EJB instances.
I've come up with two approaches. One is to call the EJB home to get the a
URI for the instance. This has the benefit of not requiring special headers.
The other is to put an instance identifier in a header. I'm interested in
comments on both approaches, and any other approaches?
I've prototyped both, and the Java Apache client code in each case is ok. I
haven't really thought through lightweight clients and other clients.
Regards,
Paul
----- Original Message -----
From: "Jackson George" <Ja...@necx.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 06, 2000 4:31 PM
Subject: Jackson : How to Write the Server Side SOAP servlet to Communicate
to the the STOCK Quote
>
>
> Hi
> We are trying to implement SOAP with Java, But for 'stockquoteClient'
,
> how to write
> a Java Servlet that could communicate to the EJB and Call a Method, What
I
> have to do for this
> Server side Servlet. I know that Using RMI-from this Servlet I could
> communicate to the EJB.
> But Anybody COULD PLEASE send me a Step by step Instructions How to set
up
> the Client
> and How set-up the SOAP server , Please send me the Code too.
>
> http://www.xmethods.com/detail.html?id=2\
>
> I am a beginner in SOAP, Just a Beginner Hope you could help me
> Appreciate , Thanks in advance
> Jackson George
> jgeorge@necx.com
>
> -----------------------------------
>
> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Tuesday, September 05, 2000 6:39 PM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: IRC log
>
>
> Just a few quick remarks before I go to sleep. 8-)
>
> I first read the SOAP spec. early this summer and having forgotten
> some details since then I thought SOAPAction should accompany every
> SOAP request message. Today's discussion under this subject has lead
> me to deciding to forget about the SOAPAction header entirely because
> it's useless unless I want to have routing before processing, but even
> then I can do that using different urls.
>
> I used SOAPAction header for differentiating between instances. Using
> SOAPAction or even the URL for that purpose means showing that the
> instances are really different, but the main reason I used that over
> information in headers is that you can send _the_same_message_ to
> different addresses in order to request a service from different
> instances. Otherwise (putting the instance identifier into a header or
> even into the body) would feel like a good ole C style:
>
> method(object, param, param, param)
>
> instead of
>
> object->method(param, param, param).
>
> Thinking about it now leads me to the conclusion, though, that that's
> what headers were created for.
>
> James proposes to use the body's namespace to do the differentiation
> of services (I'll talk about instances later) but that's feasible if
> it's you who creates the service description. If you get a service
> description and want to comply to it relying only on namespaces won't
> do if the creator of that description put all the messages into a
> single namespace. So as Glen just wrote (I just received his mail on
> that) you generally have be ready to dispatch on the QName of the body
> element or more.
>
> And using namespaces to differentiate between instances is IMO
> completely wrong because this way the whole body would have to change
> when sending to a different instance. That just feels wrong (I lack
> the vocabulary at this hour).
>
> Now to the local/global handlers: why differentiate? If this
> differentiation means only either mentioning the class in a
> message-specific section of the configuration or in the fallback
> section. then that's OK. And we could even have a whole configuration
> tree where there would be classes of services and classes of classes
> etc. and the root - the last fallback.
>
> As for the xsi:type issue: what James proposes seems great to me with
> only one exception: Why not use the same solution on the client side -
> instead of only defaulting to strings (which could be useful on either
> side if no type mapping is given) the client could specify the mapping
> as well. I don't think Deployment Description should only be
> understood as a static file - an equivalent can be given to the
> client-side SOAP tools during the client set-up. 8-)
>
> BTW: defaulting to strings is what we do in our lower (non-SCL) layer
> in IdooXoap anyway.
>
> Now lemme go home. 8-)
>
> Jacek Kopecky
> Idoox s.r.o.
>
>
>
> On Tue, 5 Sep 2000, James Snell wrote:
>
> > Alrighty... good conversation... sorry I missed it... on a short break
so
> > lemme see if I can't offer some comment on the discussion.
> >
> > >From what I gathered, the basic gist of the technical conversation was
> how
> > to map Messages to Services in terms of the Service Description API.
> >
> > First of all, I absolutely concur that a standardize API is required
for
> > service descriptions, irregardless of the actual grammar that is used.
> The
> > Service Description architecture should also consist of a plugable
> approach
> > that would allow for multiple service description language processors.
> >
> > In terms of how a message gets dispatched, I was imagining a URI-based
> > approach based around the relationship of Ports/Bindings/Messages.
> >
> > Basically, a server exposes X number of ports. Each Port exposes Y
> number
> > of bindings, A binding implements Z number of Message Handlers (e.g.
"A
> > MESSAGE HANDLER is BOUND to PORT ABC").
> >
> > If you look at SCL (for example), Messages are defined, then grouped
> > according to the ports that they are bound to. The public service
> > description would include this information.
> >
> > Internally, we would keep a separate configuration file that would map
> the
> > Port Message Bindings to particular software components. Does that
make
> > sense?
> >
> > How the processor makes the leap (from receiving a message to knowing
> which
> > Port and Binding to dispatch it to) is by parsing the namespace for the
> > message. Essentially, the namespace for the payload (the message)
would
> be
> > defined as the URI of the server + the port name + the binding name +
the
> > message name:
> >
> > For example:
> >
> > http://soap.acmeco.com/portname/bindingname#messagetype
> >
> >
> > The SOAPAction header (according to the spec) is only available for the
> HTTP
> > binding. Or at least, that is the only context in which it is used...
> there
> > is no explicit statement forbidding its use in other bindings, however,
> at
> > the same time there is no explicit statement allowing its use either,
> > meaning that it should not be relied upon for any other transport
> binding.
> >
> > The only other way to uniquely identify a message and link it to a
> > particular port binding is through a unique namespace identifier.
Since
> the
> > namespace is based on the port and binding names, the server processor
> could
> > absolutely identify and route the message accordingly.
> >
> > In summary, we would have a public service description and a private
> > configuration file. The service description would instruct the client
> how
> > to build the request, including which namespace to use for the request.
> The
> > configuration file would map the namespaces to one or more message
> handlers.
> >
> >
> > The same basic technique can be used for header processing. The
headers
> can
> > be uniquely identified by namespace, with the configuration file
> providing
> > the mapping information that tells the processor how to handle it.
> >
> > Different services can map the same headers differently by employing a
> > different Namespace URI.
> >
> > For example:
> >
> > http://soap.acmeco.com/someheader/#1
> > http://soap.acmeco.com/someheader/#2
> >
> > Or something along these lines.
> >
> > Does that make any sense? I could be way off here, so if I am, just
give
> me
> > a virtual boot-to-the-head and set me straight :-)
> >
> > A couple of other comments:
> >
> > We would need a distinction between the following types of components:
> >
> > 1. Local Message Handlers
> > A Message Handler is designed to handle the specific processing
> > requirements of a single type of message bound to a single port.
> >
> > 2. Global Message Handlers
> > A Global Message Handler is a SOAP Processor plugin designed to
> handle
> > a particular type of message no matter which port it is assigned to.
> > Essentially, when a message is received and routed to a particular
port,
> the
> > processor would first look to see if a Local Message Handler exists for
> that
> > message at that port, and if not, the processor would then query the
> Global
> > Message Handler registry to see if a global message handler has been
> defined
> > for that type of message. I haven't worked out all of the details for
> this
> > yet, so please be patient. These would include support for some kind
of
> > transaction based messaging architecture, etc that would be considered
> > global for all services.
> >
> > 3. Message Specific Header Handlers
> > A Message Specific Header Handler is a header handler
specifically
> > designed to provide context to the Local Message Handlers. This would
> > include security/etc implemented for just a single service.
> >
> > 4. Global Header Handlers
> > Global Header Handlers are handlers designed to handle specific
> types
> > of headers irregardless of the message they accompany. This would
> include
> > security/etc implemented across all services, etc.
> >
> > 5. Processor Plugins
> > Processor Plugins are code components that layer in new
> functionality
> > to the processor that is completely independent of messages or headers.
> > These would include such facilities as Logging, global transforms, etc.
> >
> >
> > As for the existing xsi:type issue, why not just add the ability for a
> > developer to map each parameter in the call to a specific xsi:type
value
> and
> > store that in the deployment descriptor? When a call is received that
> does
> > not include those values, then query the deployment descriptor and
> retrieve
> > them from there. This would work great for the server side. As for
the
> > client side, I would say that if a response is received without the
> > xsi:types, default each to string values. It's not the perfect
approach,
> > but it would work. And if we are planning a rewrite based around
service
> > descriptions anyway, doesn't it make sense to punt in the short term
and
> do
> > it right the next go around? Again, I may be way off, but to me, I
think
> > that this is a valid approach to take.
> >
> > Let's see... anything else ((james is switching back and forth between
> the
> > log and the email...))
> >
> > Oh yeah.... using the Service Description API, we can transform the
> internal
> > configuration file automatically to whichever Service Description
Grammar
> is
> > needed... again, I haven't worked out all the details on this yet, but,
> in
> > theory it sounds logical.
> >
> > Oh and Glen... if you plan on going further south (Fresno area) on your
> > vacation, drop me a line. :-)
> >
> > - James
> >
>
>
>
>
============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
>
============================================================================
>
RE: Accessing instances in SOAP - ideas?
Posted by Ara Kassabian <ar...@techone.com>.
We have actually implemented a locator framework to handle the situation you
are referring to. The code was submitted to the SOAP mailing list a few days
ago. This is part of our larger XML messaging strategy. If you are
interested in further details, I suggest you take a look at the code and/or
contact us directly (Note: The code was submitted by Vahe Amirbekyan
(avahe@techone.com), in case you want to do a search through the archive).
----------------------------------------------
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: Paul Fremantle [mailto:pzf@hursley.ibm.com]
Sent: Wednesday, September 06, 2000 1:12 PM
To: soap-dev@xml.apache.org; Jackson.George@necx.com
Subject: Accessing instances in SOAP - ideas?
Jackson, SOAP gurus!
I've been thinking about this (how to specify instances) for EJB instances.
I've come up with two approaches. One is to call the EJB home to get the a
URI for the instance. This has the benefit of not requiring special headers.
The other is to put an instance identifier in a header. I'm interested in
comments on both approaches, and any other approaches?
I've prototyped both, and the Java Apache client code in each case is ok. I
haven't really thought through lightweight clients and other clients.
Regards,
Paul
----- Original Message -----
From: "Jackson George" <Ja...@necx.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 06, 2000 4:31 PM
Subject: Jackson : How to Write the Server Side SOAP servlet to Communicate
to the the STOCK Quote
>
>
> Hi
> We are trying to implement SOAP with Java, But for 'stockquoteClient'
,
> how to write
> a Java Servlet that could communicate to the EJB and Call a Method, What
I
> have to do for this
> Server side Servlet. I know that Using RMI-from this Servlet I could
> communicate to the EJB.
> But Anybody COULD PLEASE send me a Step by step Instructions How to set
up
> the Client
> and How set-up the SOAP server , Please send me the Code too.
>
> http://www.xmethods.com/detail.html?id=2\
>
> I am a beginner in SOAP, Just a Beginner Hope you could help me
> Appreciate , Thanks in advance
> Jackson George
> jgeorge@necx.com
>
> -----------------------------------
>
> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Tuesday, September 05, 2000 6:39 PM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: IRC log
>
>
> Just a few quick remarks before I go to sleep. 8-)
>
> I first read the SOAP spec. early this summer and having forgotten
> some details since then I thought SOAPAction should accompany every
> SOAP request message. Today's discussion under this subject has lead
> me to deciding to forget about the SOAPAction header entirely because
> it's useless unless I want to have routing before processing, but even
> then I can do that using different urls.
>
> I used SOAPAction header for differentiating between instances. Using
> SOAPAction or even the URL for that purpose means showing that the
> instances are really different, but the main reason I used that over
> information in headers is that you can send _the_same_message_ to
> different addresses in order to request a service from different
> instances. Otherwise (putting the instance identifier into a header or
> even into the body) would feel like a good ole C style:
>
> method(object, param, param, param)
>
> instead of
>
> object->method(param, param, param).
>
> Thinking about it now leads me to the conclusion, though, that that's
> what headers were created for.
>
> James proposes to use the body's namespace to do the differentiation
> of services (I'll talk about instances later) but that's feasible if
> it's you who creates the service description. If you get a service
> description and want to comply to it relying only on namespaces won't
> do if the creator of that description put all the messages into a
> single namespace. So as Glen just wrote (I just received his mail on
> that) you generally have be ready to dispatch on the QName of the body
> element or more.
>
> And using namespaces to differentiate between instances is IMO
> completely wrong because this way the whole body would have to change
> when sending to a different instance. That just feels wrong (I lack
> the vocabulary at this hour).
>
> Now to the local/global handlers: why differentiate? If this
> differentiation means only either mentioning the class in a
> message-specific section of the configuration or in the fallback
> section. then that's OK. And we could even have a whole configuration
> tree where there would be classes of services and classes of classes
> etc. and the root - the last fallback.
>
> As for the xsi:type issue: what James proposes seems great to me with
> only one exception: Why not use the same solution on the client side -
> instead of only defaulting to strings (which could be useful on either
> side if no type mapping is given) the client could specify the mapping
> as well. I don't think Deployment Description should only be
> understood as a static file - an equivalent can be given to the
> client-side SOAP tools during the client set-up. 8-)
>
> BTW: defaulting to strings is what we do in our lower (non-SCL) layer
> in IdooXoap anyway.
>
> Now lemme go home. 8-)
>
> Jacek Kopecky
> Idoox s.r.o.
>
>
>
> On Tue, 5 Sep 2000, James Snell wrote:
>
> > Alrighty... good conversation... sorry I missed it... on a short break
so
> > lemme see if I can't offer some comment on the discussion.
> >
> > >From what I gathered, the basic gist of the technical conversation was
> how
> > to map Messages to Services in terms of the Service Description API.
> >
> > First of all, I absolutely concur that a standardize API is required
for
> > service descriptions, irregardless of the actual grammar that is used.
> The
> > Service Description architecture should also consist of a plugable
> approach
> > that would allow for multiple service description language processors.
> >
> > In terms of how a message gets dispatched, I was imagining a URI-based
> > approach based around the relationship of Ports/Bindings/Messages.
> >
> > Basically, a server exposes X number of ports. Each Port exposes Y
> number
> > of bindings, A binding implements Z number of Message Handlers (e.g.
"A
> > MESSAGE HANDLER is BOUND to PORT ABC").
> >
> > If you look at SCL (for example), Messages are defined, then grouped
> > according to the ports that they are bound to. The public service
> > description would include this information.
> >
> > Internally, we would keep a separate configuration file that would map
> the
> > Port Message Bindings to particular software components. Does that
make
> > sense?
> >
> > How the processor makes the leap (from receiving a message to knowing
> which
> > Port and Binding to dispatch it to) is by parsing the namespace for the
> > message. Essentially, the namespace for the payload (the message)
would
> be
> > defined as the URI of the server + the port name + the binding name +
the
> > message name:
> >
> > For example:
> >
> > http://soap.acmeco.com/portname/bindingname#messagetype
> >
> >
> > The SOAPAction header (according to the spec) is only available for the
> HTTP
> > binding. Or at least, that is the only context in which it is used...
> there
> > is no explicit statement forbidding its use in other bindings, however,
> at
> > the same time there is no explicit statement allowing its use either,
> > meaning that it should not be relied upon for any other transport
> binding.
> >
> > The only other way to uniquely identify a message and link it to a
> > particular port binding is through a unique namespace identifier.
Since
> the
> > namespace is based on the port and binding names, the server processor
> could
> > absolutely identify and route the message accordingly.
> >
> > In summary, we would have a public service description and a private
> > configuration file. The service description would instruct the client
> how
> > to build the request, including which namespace to use for the request.
> The
> > configuration file would map the namespaces to one or more message
> handlers.
> >
> >
> > The same basic technique can be used for header processing. The
headers
> can
> > be uniquely identified by namespace, with the configuration file
> providing
> > the mapping information that tells the processor how to handle it.
> >
> > Different services can map the same headers differently by employing a
> > different Namespace URI.
> >
> > For example:
> >
> > http://soap.acmeco.com/someheader/#1
> > http://soap.acmeco.com/someheader/#2
> >
> > Or something along these lines.
> >
> > Does that make any sense? I could be way off here, so if I am, just
give
> me
> > a virtual boot-to-the-head and set me straight :-)
> >
> > A couple of other comments:
> >
> > We would need a distinction between the following types of components:
> >
> > 1. Local Message Handlers
> > A Message Handler is designed to handle the specific processing
> > requirements of a single type of message bound to a single port.
> >
> > 2. Global Message Handlers
> > A Global Message Handler is a SOAP Processor plugin designed to
> handle
> > a particular type of message no matter which port it is assigned to.
> > Essentially, when a message is received and routed to a particular
port,
> the
> > processor would first look to see if a Local Message Handler exists for
> that
> > message at that port, and if not, the processor would then query the
> Global
> > Message Handler registry to see if a global message handler has been
> defined
> > for that type of message. I haven't worked out all of the details for
> this
> > yet, so please be patient. These would include support for some kind
of
> > transaction based messaging architecture, etc that would be considered
> > global for all services.
> >
> > 3. Message Specific Header Handlers
> > A Message Specific Header Handler is a header handler
specifically
> > designed to provide context to the Local Message Handlers. This would
> > include security/etc implemented for just a single service.
> >
> > 4. Global Header Handlers
> > Global Header Handlers are handlers designed to handle specific
> types
> > of headers irregardless of the message they accompany. This would
> include
> > security/etc implemented across all services, etc.
> >
> > 5. Processor Plugins
> > Processor Plugins are code components that layer in new
> functionality
> > to the processor that is completely independent of messages or headers.
> > These would include such facilities as Logging, global transforms, etc.
> >
> >
> > As for the existing xsi:type issue, why not just add the ability for a
> > developer to map each parameter in the call to a specific xsi:type
value
> and
> > store that in the deployment descriptor? When a call is received that
> does
> > not include those values, then query the deployment descriptor and
> retrieve
> > them from there. This would work great for the server side. As for
the
> > client side, I would say that if a response is received without the
> > xsi:types, default each to string values. It's not the perfect
approach,
> > but it would work. And if we are planning a rewrite based around
service
> > descriptions anyway, doesn't it make sense to punt in the short term
and
> do
> > it right the next go around? Again, I may be way off, but to me, I
think
> > that this is a valid approach to take.
> >
> > Let's see... anything else ((james is switching back and forth between
> the
> > log and the email...))
> >
> > Oh yeah.... using the Service Description API, we can transform the
> internal
> > configuration file automatically to whichever Service Description
Grammar
> is
> > needed... again, I haven't worked out all the details on this yet, but,
> in
> > theory it sounds logical.
> >
> > Oh and Glen... if you plan on going further south (Fresno area) on your
> > vacation, drop me a line. :-)
> >
> > - James
> >
>
>
>
>
============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
>
============================================================================
>
Accessing instances in SOAP - ideas?
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Jackson, SOAP gurus!
I've been thinking about this (how to specify instances) for EJB instances.
I've come up with two approaches. One is to call the EJB home to get the a
URI for the instance. This has the benefit of not requiring special headers.
The other is to put an instance identifier in a header. I'm interested in
comments on both approaches, and any other approaches?
I've prototyped both, and the Java Apache client code in each case is ok. I
haven't really thought through lightweight clients and other clients.
Regards,
Paul
----- Original Message -----
From: "Jackson George" <Ja...@necx.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 06, 2000 4:31 PM
Subject: Jackson : How to Write the Server Side SOAP servlet to Communicate
to the the STOCK Quote
>
>
> Hi
> We are trying to implement SOAP with Java, But for 'stockquoteClient'
,
> how to write
> a Java Servlet that could communicate to the EJB and Call a Method, What
I
> have to do for this
> Server side Servlet. I know that Using RMI-from this Servlet I could
> communicate to the EJB.
> But Anybody COULD PLEASE send me a Step by step Instructions How to set
up
> the Client
> and How set-up the SOAP server , Please send me the Code too.
>
> http://www.xmethods.com/detail.html?id=2\
>
> I am a beginner in SOAP, Just a Beginner Hope you could help me
> Appreciate , Thanks in advance
> Jackson George
> jgeorge@necx.com
>
> -----------------------------------
>
> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Tuesday, September 05, 2000 6:39 PM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: IRC log
>
>
> Just a few quick remarks before I go to sleep. 8-)
>
> I first read the SOAP spec. early this summer and having forgotten
> some details since then I thought SOAPAction should accompany every
> SOAP request message. Today's discussion under this subject has lead
> me to deciding to forget about the SOAPAction header entirely because
> it's useless unless I want to have routing before processing, but even
> then I can do that using different urls.
>
> I used SOAPAction header for differentiating between instances. Using
> SOAPAction or even the URL for that purpose means showing that the
> instances are really different, but the main reason I used that over
> information in headers is that you can send _the_same_message_ to
> different addresses in order to request a service from different
> instances. Otherwise (putting the instance identifier into a header or
> even into the body) would feel like a good ole C style:
>
> method(object, param, param, param)
>
> instead of
>
> object->method(param, param, param).
>
> Thinking about it now leads me to the conclusion, though, that that's
> what headers were created for.
>
> James proposes to use the body's namespace to do the differentiation
> of services (I'll talk about instances later) but that's feasible if
> it's you who creates the service description. If you get a service
> description and want to comply to it relying only on namespaces won't
> do if the creator of that description put all the messages into a
> single namespace. So as Glen just wrote (I just received his mail on
> that) you generally have be ready to dispatch on the QName of the body
> element or more.
>
> And using namespaces to differentiate between instances is IMO
> completely wrong because this way the whole body would have to change
> when sending to a different instance. That just feels wrong (I lack
> the vocabulary at this hour).
>
> Now to the local/global handlers: why differentiate? If this
> differentiation means only either mentioning the class in a
> message-specific section of the configuration or in the fallback
> section. then that's OK. And we could even have a whole configuration
> tree where there would be classes of services and classes of classes
> etc. and the root - the last fallback.
>
> As for the xsi:type issue: what James proposes seems great to me with
> only one exception: Why not use the same solution on the client side -
> instead of only defaulting to strings (which could be useful on either
> side if no type mapping is given) the client could specify the mapping
> as well. I don't think Deployment Description should only be
> understood as a static file - an equivalent can be given to the
> client-side SOAP tools during the client set-up. 8-)
>
> BTW: defaulting to strings is what we do in our lower (non-SCL) layer
> in IdooXoap anyway.
>
> Now lemme go home. 8-)
>
> Jacek Kopecky
> Idoox s.r.o.
>
>
>
> On Tue, 5 Sep 2000, James Snell wrote:
>
> > Alrighty... good conversation... sorry I missed it... on a short break
so
> > lemme see if I can't offer some comment on the discussion.
> >
> > >From what I gathered, the basic gist of the technical conversation was
> how
> > to map Messages to Services in terms of the Service Description API.
> >
> > First of all, I absolutely concur that a standardize API is required
for
> > service descriptions, irregardless of the actual grammar that is used.
> The
> > Service Description architecture should also consist of a plugable
> approach
> > that would allow for multiple service description language processors.
> >
> > In terms of how a message gets dispatched, I was imagining a URI-based
> > approach based around the relationship of Ports/Bindings/Messages.
> >
> > Basically, a server exposes X number of ports. Each Port exposes Y
> number
> > of bindings, A binding implements Z number of Message Handlers (e.g.
"A
> > MESSAGE HANDLER is BOUND to PORT ABC").
> >
> > If you look at SCL (for example), Messages are defined, then grouped
> > according to the ports that they are bound to. The public service
> > description would include this information.
> >
> > Internally, we would keep a separate configuration file that would map
> the
> > Port Message Bindings to particular software components. Does that
make
> > sense?
> >
> > How the processor makes the leap (from receiving a message to knowing
> which
> > Port and Binding to dispatch it to) is by parsing the namespace for the
> > message. Essentially, the namespace for the payload (the message)
would
> be
> > defined as the URI of the server + the port name + the binding name +
the
> > message name:
> >
> > For example:
> >
> > http://soap.acmeco.com/portname/bindingname#messagetype
> >
> >
> > The SOAPAction header (according to the spec) is only available for the
> HTTP
> > binding. Or at least, that is the only context in which it is used...
> there
> > is no explicit statement forbidding its use in other bindings, however,
> at
> > the same time there is no explicit statement allowing its use either,
> > meaning that it should not be relied upon for any other transport
> binding.
> >
> > The only other way to uniquely identify a message and link it to a
> > particular port binding is through a unique namespace identifier.
Since
> the
> > namespace is based on the port and binding names, the server processor
> could
> > absolutely identify and route the message accordingly.
> >
> > In summary, we would have a public service description and a private
> > configuration file. The service description would instruct the client
> how
> > to build the request, including which namespace to use for the request.
> The
> > configuration file would map the namespaces to one or more message
> handlers.
> >
> >
> > The same basic technique can be used for header processing. The
headers
> can
> > be uniquely identified by namespace, with the configuration file
> providing
> > the mapping information that tells the processor how to handle it.
> >
> > Different services can map the same headers differently by employing a
> > different Namespace URI.
> >
> > For example:
> >
> > http://soap.acmeco.com/someheader/#1
> > http://soap.acmeco.com/someheader/#2
> >
> > Or something along these lines.
> >
> > Does that make any sense? I could be way off here, so if I am, just
give
> me
> > a virtual boot-to-the-head and set me straight :-)
> >
> > A couple of other comments:
> >
> > We would need a distinction between the following types of components:
> >
> > 1. Local Message Handlers
> > A Message Handler is designed to handle the specific processing
> > requirements of a single type of message bound to a single port.
> >
> > 2. Global Message Handlers
> > A Global Message Handler is a SOAP Processor plugin designed to
> handle
> > a particular type of message no matter which port it is assigned to.
> > Essentially, when a message is received and routed to a particular
port,
> the
> > processor would first look to see if a Local Message Handler exists for
> that
> > message at that port, and if not, the processor would then query the
> Global
> > Message Handler registry to see if a global message handler has been
> defined
> > for that type of message. I haven't worked out all of the details for
> this
> > yet, so please be patient. These would include support for some kind
of
> > transaction based messaging architecture, etc that would be considered
> > global for all services.
> >
> > 3. Message Specific Header Handlers
> > A Message Specific Header Handler is a header handler
specifically
> > designed to provide context to the Local Message Handlers. This would
> > include security/etc implemented for just a single service.
> >
> > 4. Global Header Handlers
> > Global Header Handlers are handlers designed to handle specific
> types
> > of headers irregardless of the message they accompany. This would
> include
> > security/etc implemented across all services, etc.
> >
> > 5. Processor Plugins
> > Processor Plugins are code components that layer in new
> functionality
> > to the processor that is completely independent of messages or headers.
> > These would include such facilities as Logging, global transforms, etc.
> >
> >
> > As for the existing xsi:type issue, why not just add the ability for a
> > developer to map each parameter in the call to a specific xsi:type
value
> and
> > store that in the deployment descriptor? When a call is received that
> does
> > not include those values, then query the deployment descriptor and
> retrieve
> > them from there. This would work great for the server side. As for
the
> > client side, I would say that if a response is received without the
> > xsi:types, default each to string values. It's not the perfect
approach,
> > but it would work. And if we are planning a rewrite based around
service
> > descriptions anyway, doesn't it make sense to punt in the short term
and
> do
> > it right the next go around? Again, I may be way off, but to me, I
think
> > that this is a valid approach to take.
> >
> > Let's see... anything else ((james is switching back and forth between
> the
> > log and the email...))
> >
> > Oh yeah.... using the Service Description API, we can transform the
> internal
> > configuration file automatically to whichever Service Description
Grammar
> is
> > needed... again, I haven't worked out all the details on this yet, but,
> in
> > theory it sounds logical.
> >
> > Oh and Glen... if you plan on going further south (Fresno area) on your
> > vacation, drop me a line. :-)
> >
> > - James
> >
>
>
>
>
============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
>
============================================================================
>
Accessing instances in SOAP - ideas?
Posted by Paul Fremantle <pz...@hursley.ibm.com>.
Jackson, SOAP gurus!
I've been thinking about this (how to specify instances) for EJB instances.
I've come up with two approaches. One is to call the EJB home to get the a
URI for the instance. This has the benefit of not requiring special headers.
The other is to put an instance identifier in a header. I'm interested in
comments on both approaches, and any other approaches?
I've prototyped both, and the Java Apache client code in each case is ok. I
haven't really thought through lightweight clients and other clients.
Regards,
Paul
----- Original Message -----
From: "Jackson George" <Ja...@necx.com>
To: <so...@xml.apache.org>
Sent: Wednesday, September 06, 2000 4:31 PM
Subject: Jackson : How to Write the Server Side SOAP servlet to Communicate
to the the STOCK Quote
>
>
> Hi
> We are trying to implement SOAP with Java, But for 'stockquoteClient'
,
> how to write
> a Java Servlet that could communicate to the EJB and Call a Method, What
I
> have to do for this
> Server side Servlet. I know that Using RMI-from this Servlet I could
> communicate to the EJB.
> But Anybody COULD PLEASE send me a Step by step Instructions How to set
up
> the Client
> and How set-up the SOAP server , Please send me the Code too.
>
> http://www.xmethods.com/detail.html?id=2\
>
> I am a beginner in SOAP, Just a Beginner Hope you could help me
> Appreciate , Thanks in advance
> Jackson George
> jgeorge@necx.com
>
> -----------------------------------
>
> -----Original Message-----
> From: Jacek Kopecky [mailto:jacek@idoox.com]
> Sent: Tuesday, September 05, 2000 6:39 PM
> To: 'soap-dev@xml.apache.org'
> Subject: RE: IRC log
>
>
> Just a few quick remarks before I go to sleep. 8-)
>
> I first read the SOAP spec. early this summer and having forgotten
> some details since then I thought SOAPAction should accompany every
> SOAP request message. Today's discussion under this subject has lead
> me to deciding to forget about the SOAPAction header entirely because
> it's useless unless I want to have routing before processing, but even
> then I can do that using different urls.
>
> I used SOAPAction header for differentiating between instances. Using
> SOAPAction or even the URL for that purpose means showing that the
> instances are really different, but the main reason I used that over
> information in headers is that you can send _the_same_message_ to
> different addresses in order to request a service from different
> instances. Otherwise (putting the instance identifier into a header or
> even into the body) would feel like a good ole C style:
>
> method(object, param, param, param)
>
> instead of
>
> object->method(param, param, param).
>
> Thinking about it now leads me to the conclusion, though, that that's
> what headers were created for.
>
> James proposes to use the body's namespace to do the differentiation
> of services (I'll talk about instances later) but that's feasible if
> it's you who creates the service description. If you get a service
> description and want to comply to it relying only on namespaces won't
> do if the creator of that description put all the messages into a
> single namespace. So as Glen just wrote (I just received his mail on
> that) you generally have be ready to dispatch on the QName of the body
> element or more.
>
> And using namespaces to differentiate between instances is IMO
> completely wrong because this way the whole body would have to change
> when sending to a different instance. That just feels wrong (I lack
> the vocabulary at this hour).
>
> Now to the local/global handlers: why differentiate? If this
> differentiation means only either mentioning the class in a
> message-specific section of the configuration or in the fallback
> section. then that's OK. And we could even have a whole configuration
> tree where there would be classes of services and classes of classes
> etc. and the root - the last fallback.
>
> As for the xsi:type issue: what James proposes seems great to me with
> only one exception: Why not use the same solution on the client side -
> instead of only defaulting to strings (which could be useful on either
> side if no type mapping is given) the client could specify the mapping
> as well. I don't think Deployment Description should only be
> understood as a static file - an equivalent can be given to the
> client-side SOAP tools during the client set-up. 8-)
>
> BTW: defaulting to strings is what we do in our lower (non-SCL) layer
> in IdooXoap anyway.
>
> Now lemme go home. 8-)
>
> Jacek Kopecky
> Idoox s.r.o.
>
>
>
> On Tue, 5 Sep 2000, James Snell wrote:
>
> > Alrighty... good conversation... sorry I missed it... on a short break
so
> > lemme see if I can't offer some comment on the discussion.
> >
> > >From what I gathered, the basic gist of the technical conversation was
> how
> > to map Messages to Services in terms of the Service Description API.
> >
> > First of all, I absolutely concur that a standardize API is required
for
> > service descriptions, irregardless of the actual grammar that is used.
> The
> > Service Description architecture should also consist of a plugable
> approach
> > that would allow for multiple service description language processors.
> >
> > In terms of how a message gets dispatched, I was imagining a URI-based
> > approach based around the relationship of Ports/Bindings/Messages.
> >
> > Basically, a server exposes X number of ports. Each Port exposes Y
> number
> > of bindings, A binding implements Z number of Message Handlers (e.g.
"A
> > MESSAGE HANDLER is BOUND to PORT ABC").
> >
> > If you look at SCL (for example), Messages are defined, then grouped
> > according to the ports that they are bound to. The public service
> > description would include this information.
> >
> > Internally, we would keep a separate configuration file that would map
> the
> > Port Message Bindings to particular software components. Does that
make
> > sense?
> >
> > How the processor makes the leap (from receiving a message to knowing
> which
> > Port and Binding to dispatch it to) is by parsing the namespace for the
> > message. Essentially, the namespace for the payload (the message)
would
> be
> > defined as the URI of the server + the port name + the binding name +
the
> > message name:
> >
> > For example:
> >
> > http://soap.acmeco.com/portname/bindingname#messagetype
> >
> >
> > The SOAPAction header (according to the spec) is only available for the
> HTTP
> > binding. Or at least, that is the only context in which it is used...
> there
> > is no explicit statement forbidding its use in other bindings, however,
> at
> > the same time there is no explicit statement allowing its use either,
> > meaning that it should not be relied upon for any other transport
> binding.
> >
> > The only other way to uniquely identify a message and link it to a
> > particular port binding is through a unique namespace identifier.
Since
> the
> > namespace is based on the port and binding names, the server processor
> could
> > absolutely identify and route the message accordingly.
> >
> > In summary, we would have a public service description and a private
> > configuration file. The service description would instruct the client
> how
> > to build the request, including which namespace to use for the request.
> The
> > configuration file would map the namespaces to one or more message
> handlers.
> >
> >
> > The same basic technique can be used for header processing. The
headers
> can
> > be uniquely identified by namespace, with the configuration file
> providing
> > the mapping information that tells the processor how to handle it.
> >
> > Different services can map the same headers differently by employing a
> > different Namespace URI.
> >
> > For example:
> >
> > http://soap.acmeco.com/someheader/#1
> > http://soap.acmeco.com/someheader/#2
> >
> > Or something along these lines.
> >
> > Does that make any sense? I could be way off here, so if I am, just
give
> me
> > a virtual boot-to-the-head and set me straight :-)
> >
> > A couple of other comments:
> >
> > We would need a distinction between the following types of components:
> >
> > 1. Local Message Handlers
> > A Message Handler is designed to handle the specific processing
> > requirements of a single type of message bound to a single port.
> >
> > 2. Global Message Handlers
> > A Global Message Handler is a SOAP Processor plugin designed to
> handle
> > a particular type of message no matter which port it is assigned to.
> > Essentially, when a message is received and routed to a particular
port,
> the
> > processor would first look to see if a Local Message Handler exists for
> that
> > message at that port, and if not, the processor would then query the
> Global
> > Message Handler registry to see if a global message handler has been
> defined
> > for that type of message. I haven't worked out all of the details for
> this
> > yet, so please be patient. These would include support for some kind
of
> > transaction based messaging architecture, etc that would be considered
> > global for all services.
> >
> > 3. Message Specific Header Handlers
> > A Message Specific Header Handler is a header handler
specifically
> > designed to provide context to the Local Message Handlers. This would
> > include security/etc implemented for just a single service.
> >
> > 4. Global Header Handlers
> > Global Header Handlers are handlers designed to handle specific
> types
> > of headers irregardless of the message they accompany. This would
> include
> > security/etc implemented across all services, etc.
> >
> > 5. Processor Plugins
> > Processor Plugins are code components that layer in new
> functionality
> > to the processor that is completely independent of messages or headers.
> > These would include such facilities as Logging, global transforms, etc.
> >
> >
> > As for the existing xsi:type issue, why not just add the ability for a
> > developer to map each parameter in the call to a specific xsi:type
value
> and
> > store that in the deployment descriptor? When a call is received that
> does
> > not include those values, then query the deployment descriptor and
> retrieve
> > them from there. This would work great for the server side. As for
the
> > client side, I would say that if a response is received without the
> > xsi:types, default each to string values. It's not the perfect
approach,
> > but it would work. And if we are planning a rewrite based around
service
> > descriptions anyway, doesn't it make sense to punt in the short term
and
> do
> > it right the next go around? Again, I may be way off, but to me, I
think
> > that this is a valid approach to take.
> >
> > Let's see... anything else ((james is switching back and forth between
> the
> > log and the email...))
> >
> > Oh yeah.... using the Service Description API, we can transform the
> internal
> > configuration file automatically to whichever Service Description
Grammar
> is
> > needed... again, I haven't worked out all the details on this yet, but,
> in
> > theory it sounds logical.
> >
> > Oh and Glen... if you plan on going further south (Fresno area) on your
> > vacation, drop me a line. :-)
> >
> > - James
> >
>
>
>
>
============================================================================
> This message is intended only for the use of the Addressee(s) and may
> contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
> the intended recipient, dissemination of this communication is prohibited.
> If you have received this communication in error, please erase all copies
> of the message and its attachments and notify postmaster@verticalnet.com
> immediately.
>
============================================================================
>