You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@commons.apache.org by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com> on 2005/12/16 04:52:04 UTC
[SCXML] SCXMLDigester setNamespaceAware
Hi Rahul,
Everything is working except one issue. As we added
setNamespaceAware(true) in the digester, it adds some "junk" to our soap
message within the send tags. For our specific purpose, it seems
unnecessary, but do you think making that setNamespaceAware(true) should
be configurable? This way, for our use, we have strictly defined the
xml format to client/app so we don't need namespaces but others may.
For now, we'll just change that value to false but I propose that is
configurable value.
Cheers,
Mike
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Wednesday, December 14, 2005 10:39 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] Concurrent users
On 12/14/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Two issues reported:
>
> EventDispatcher#send
> - inability to access context
<snip/>
Which is per design. Can you elaborate why the context should be
accessible?
> - inability to access externalNodes (solved in prior thread - adding
> externalNodes to method signature)
<snap/>
Yup, fixed in SVN :-)
>
> SCXMLExecutor#reset
> - reset method resets ALL context(s)
> ? should have reset for only that user's context, but to do that, we
> would have to instantiate an SCXML obj (stateMachine) for each as well
> as executor?
<snip/>
> You mention "appropriately configured Executor" below. I wonder if
> you suggest each Executor instance also has its own unique state
> machine (SCXML obj) instance too.
<snap/>
Yes, the SCXML object is the in-memory representation of an instance of
the state machine. The evaluation contexts hang off of each State within
the SCXML object, and so the reset method is clearing the contexts for
this instance of the state machine. For each new user/session, a new
instance is called for (SCXML as well as SCXMLExecutor).
> If so, I'm curious what implications this
> would have on memory.
<snip/>
The SCXML Java object model is fairly lightweight. Since your usecase is
in the servlet container -- and most web related frameworks /
technologies have much higher requirements -- I don't see any cause for
concern.
-Rahul
> Regards,
>
>
> Mike
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] SCXMLDigester setNamespaceAware
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/16/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Rahul,
>
> No, just namespace URIs (I'll confirm Sunday night), but as we
> constructed SOAP-ENV message within send tags, our web service wouldn't
> accept the format of the message. After turning off setNamespaceAware
> (set to false), it worked? We can either send via encoded URI (REST) or
> merely add the SOAP env and pass it on - very cool!
>
<snip/>
>
> Below is example of output to client (transform is determined by which
> plug-in they access, usually a servlet but can be IM Gateway, SMS
> Gateway, etc., just implementing our plug-in Interface)...
>
<snip-example/>
>
> We transform
> vxml response depending on client (rich text, vxml, text, html, etc.).
> It's built to be very flexible, we can even interact with REST WS or any
> encoded URI access to an app via <var> and namelist along with URI as
> target. I'm not sure about performance of the whole thing - may add LRU
> Cache - but it does what I wanted it to and qualifies as an end-to-end
> SCXML/VXML MMI Framework w/ single plug-in architecture for n Clients.
> :-) Probably first in the world I imagine! :-O Anyone need a bot
> built, in minutes?
>
<snap/>
Super! You've demonstrated what some of us have merely claimed to be
the advantages obtained by using Commons SCXML in web-based
applications:
* Separation of "dialog flow" from "views"
* The multiple channels and devices aspect (catering markup to device
and modality used by end user)
* Event triggered messages sent to external components (servlets,
web-services calls, SOAP over HTTP, what have you)
This is great stuff, Mike :-)
> Given digester is Open, a knowing (or unknowing like myself) individual
> can theoretically customize as they see fit. As such, perhaps just
> leave it alone or implement the solution you mention.
>
<snip/>
I see the theory, makes sense to give the SCXMLDigester class a
Factory flavor. I'll add this to my TODO list for the weekend, will
probably get to it tomorrow.
> As a final note, if you have any input to W3C spec, I suggest removing
> mutual exclusivity of either namelist vars OR send body contents. I
> believe they are supposed to throw fetch.error or something. Commons
> SCXML does not, but as I stated before, I think this is best as it's
> nice to access to some vars in context that may not necessarily be used
> for messages, etc.
>
<snap/>
As far as feedback is concerned, the W3C based on my understanding and
experience (arguably, limited experience), is open to suggestions from
everyone. There are public mailing lists -- to which anyone can
subscribe, just like the lists here at Apache -- and offer feedback. I
would recommend you post any suggestions about the specification
itself on the Voice Browser Working Group's (the SCXML spec is
currently a Working Draft out of the VBWG) public mailing list.
> Cheers,
>
>
> Mike
>
> P.S. - where do you work? And are you in US?
>
<snip/>
I'm in the big apple, where the big blue keeps me busy during the day.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
RE: [SCXML] SCXMLDigester setNamespaceAware
Posted by "Mike Sparr - www.goomzee.com" <mi...@goomzee.com>.
Rahul,
No, just namespace URIs (I'll confirm Sunday night), but as we
constructed SOAP-ENV message within send tags, our web service wouldn't
accept the format of the message. After turning off setNamespaceAware
(set to false), it worked? We can either send via encoded URI (REST) or
merely add the SOAP env and pass it on - very cool!
<transition event="double" >
<var name="cb" expr="${Conversation}" />
<send target="http://localhost:8080/goomzee/Calculator.jws"
targettype="appManager" event="talk" namelist="cb" delay="0" hints=""
sendid="2345" >
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:add
xmlns:ns1="http://localhost:8080/goomzee/Calculator.jws"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<i1 xsi:type="xsd:int">${cb.request}</i1>
<i2 xsi:type="xsd:int">${cb.request}</i2>
</ns1:add>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
</send>
<target next="state_login" />
</transition>
Everything's working but I am keeping things under wraps for now. Plus
there are a few automation/stub features that need tweaking and some
code cleanup and documentation TODO. Above is the transition we use
that actually interacts w/ our simple web service. For some reason,
when we had setNamespaceAware(true) the messages wouldn't work. I
suggested setting to false and it worked? We finished at 6am (6:30PM
Friday in india) so I sent my 'helper' away for RESTful weekend ;-).
I'll find out exactly what was wrong Sunday eve (Monday morn IST).
Below is example of output to client (transform is determined by which
plug-in they access, usually a servlet but can be IM Gateway, SMS
Gateway, etc., just implementing our plug-in Interface)...
<transition event="menu">
<var name="cb" expr="${Conversation}" />
<send target="http://localhost:8080/goomzee" targettype="scxml"
event="greet" namelist="cb" delay="0" hints="" sendid="2345">
<menu>
<prompt>
What do you want to do? <enumerate/>
</prompt>
<choice>
1. Chat
</choice>
<choice>
2. Logoff
</choice>
</menu>
</send >
<target next="state_welcome" />
</transition>
Above is an example transition that sends output to user. We transform
vxml response depending on client (rich text, vxml, text, html, etc.).
It's built to be very flexible, we can even interact with REST WS or any
encoded URI access to an app via <var> and namelist along with URI as
target. I'm not sure about performance of the whole thing - may add LRU
Cache - but it does what I wanted it to and qualifies as an end-to-end
SCXML/VXML MMI Framework w/ single plug-in architecture for n Clients.
:-) Probably first in the world I imagine! :-O Anyone need a bot
built, in minutes?
Given digester is Open, a knowing (or unknowing like myself) individual
can theoretically customize as they see fit. As such, perhaps just
leave it alone or implement the solution you mention.
As a final note, if you have any input to W3C spec, I suggest removing
mutual exclusivity of either namelist vars OR send body contents. I
believe they are supposed to throw fetch.error or something. Commons
SCXML does not, but as I stated before, I think this is best as it's
nice to access to some vars in context that may not necessarily be used
for messages, etc.
Cheers,
Mike
P.S. - where do you work? And are you in US?
-----Original Message-----
From: Rahul Akolkar [mailto:rahul.akolkar@gmail.com]
Sent: Friday, December 16, 2005 12:55 PM
To: Jakarta Commons Users List; mike@goomzee.com
Subject: Re: [SCXML] SCXMLDigester setNamespaceAware
On 12/15/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Everything is working except one issue. As we added
> setNamespaceAware(true) in the digester, it adds some "junk" to our
> soap message within the send tags.
<snip/>
"Junk" as in namespace URIs? Is there anything else?
> For our specific purpose, it seems
> unnecessary, but do you think making that setNamespaceAware(true)
> should be configurable? This way, for our use, we have strictly
> defined the xml format to client/app so we don't need namespaces but
> others may. For now, we'll just change that value to false but I
> propose that is configurable value.
>
<snap/>
If we need configurability, IMO, it would be better to open up some of
the SCXMLDigester API so it can also be treated as a Factory class for
suitably configured Digester instances, with the newInstance() method
-- and updateSCXML() for completion -- being public.
That would give users freedom to configure more than just
namespace-awareness. But, freedom has a price (being able to use it
correctly), so lets give this some more thought (which is why I'm asking
about your particular use case).
-Rahul
> Cheers,
>
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [SCXML] SCXMLDigester setNamespaceAware
Posted by Rahul Akolkar <ra...@gmail.com>.
On 12/15/05, Mike Sparr - www.goomzee.com <mi...@goomzee.com> wrote:
> Hi Rahul,
>
> Everything is working except one issue. As we added
> setNamespaceAware(true) in the digester, it adds some "junk" to our soap
> message within the send tags.
<snip/>
"Junk" as in namespace URIs? Is there anything else?
> For our specific purpose, it seems
> unnecessary, but do you think making that setNamespaceAware(true) should
> be configurable? This way, for our use, we have strictly defined the
> xml format to client/app so we don't need namespaces but others may.
> For now, we'll just change that value to false but I propose that is
> configurable value.
>
<snap/>
If we need configurability, IMO, it would be better to open up some of
the SCXMLDigester API so it can also be treated as a Factory class for
suitably configured Digester instances, with the newInstance() method
-- and updateSCXML() for completion -- being public.
That would give users freedom to configure more than just
namespace-awareness. But, freedom has a price (being able to use it
correctly), so lets give this some more thought (which is why I'm
asking about your particular use case).
-Rahul
> Cheers,
>
>
> Mike
>
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org