Uri,
Can you please give a more detailed example of how one would setup Stem to do a
simple email when a system fails for example?
Aaron Johnson
Uri Guttman wrote:
> i only just joined this list so i am replying to a post i saw in the
> archives. i wasn't cc'ed on this one.
>
> aaron johnson wrote:
>
> I read over the JMS information and I read over Stem, but this
> is still not what I am talking about doing. I am looking at how
> this would be applied that the final level, not the server or
> backend process. I am focusing on the rules that would
> determine the message transport and how to determine the sucess
> of such messaging. There is much more to this then system level
> messaging, which is what Spread and Stem seem to concentrate on.
> I am talking about person to person and this will need to extend
> all the way to VoiceXML. Part of the requirements of P5EE as
> outlined on Stephen's site is
>
> you haven't truly grokked stem yet. :)
>
> I want to apologize in advance for my possible lack of correct
> usage of terminology.
>
> that is a major issue when designing systems like this.
>
> The requirement of the application/tool is to message a person
> when a certain action occurs. The method by which the person is
> to contacted is stored in rules somewhere. These rules define
> status codes or other items that are known within current
> processes and can be added to as new processes are added.
>
> ok, let me clear up a terminology point. there are really two major uses
> of the word messaging. the one you use above is what i call end user
> messaging. its common forms are email, AIM, jabber, etc. it is an end
> user to end user message. the other use of the term is what i call
> system messaging where message passing is a low level technique used to
> transfer information. stem, JMS, MOM (message oriented middleware) and i
> think SOAP are among those types. so end user messaging is a service and
> system level messaging is a technology. it gets really confusing when
> end user messages are carried by a system messaging technology.
>
> So lets say that a cronjob application that updates a database
> with an XML stream of data for example has a complication. Bob
> needs to be notified that the process has failed. The
> send_notification function/method is called and passed only the
> body of the message. send_notification's job is to read the
> rules and based on the message body, or possible a secondary
> parameter, send the message via the correct transport system.
>
> that is end user messaging. you are really jumping many layers there. an
> end user message would never be able to call a function or a
> method. there are ways to relate the two and believe it or not, stem has
> a very neat technique for it. stem has a very powerful logical log
> subsystem. you can send it data from many sources and execute filter
> rules and actions upon each message. these filters and rules are not
> coded but configured and can be changed at runtime with new
> configurations or by changing selected variables. actions can forward a
> log entry to other logs (and it will get passed to more rules and
> actions), files, email, pager, external programs, etc. the idea is to separate
> generating log entries from how you handle them. logical logs can be
> local, remote, distributed, etc. log rules and actions can be modified
> from anywhere. one way of describing this is syslog on steroids and with
> brains. :)
>
> These are just quick thoughts that in no way explore the depth
> of difficulty in doing this. There would have to be a parameter
> system in place to allow for correct handling, but it should
> also have intelligence to do the right thing or notifiy the
> developer in an intelligent manner if it can not.
>
> just like i designed it already. :)
>
> My focus is and most likely always will be on making the API
> (interface) to functions/methods as simple as possible.
>
> same here.
>
> I feel that it will be the responsiblity of the
> send_notification to "know" what modules to use, this could be
> extended by configuration options. Lets say that on load
> Notification reads the conf file and it indicates that all email
> is processed by the Qmail module, those modules can be included
> in P5EE or added by third parties. (is this dispatching?)
>
> you are again conflating user level messaging (email) with system level
> messaging (dispatching, modules, etc.). it is critical that you separate
> those two layers in the concept and design. they can both be done in
> multiple ways and if you try to cross over you will have to have N x M
> ways to send user level messages. the api for that is ridiculous. some
> system will want to use jabber to send a pager message and another will
> want icq for an ftp server. :)
>
> All of these thoughts stem (no pun intended) from my own desire
> of getting messages via the correct transport to the correct
> person with out a lot of thinking on the developers end.
> Basicly all the developer wants to do in the end is send a
> chunck of text or a binary blob, they shouldn't have to do
> a lot of thinking to make it happen.
>
> i agree, but you have to separate the layers better in your mind and
> design. i have spent 2 years on this and have run up against many of the
> problems you are addressing. i designed the log subsystem to allow for
> this actual use, separation of message injection from message handling
> (filtering/rules/actions) and delivery. BTW, stem logs are not the same
> as stem messages. but they work closely together. transfering a stem log
> entry to another process is via a stem message. also a log entry could
> be converted to a stem message for delivery to any object that wants
> it.
>
> In other words this is what I want to avoid: "In messaging
> systems the point of communication between applications is the
> message itself, so a developer using JMS must understand messages.."
>
> this can only be avoided if you isolate user messages from transport.
> but you haven't done that in your examples above.
>
> anyhow, i am willing to offer both stem (in gpl form for now) and my
> ideas to this. i think a high level framework is a great idea and stem
> is my way of approaching it. it is not as large as POE but i think it
> has a better underlying architecture and simpler and cleaner API. POE
> has much more functioning code and better event loop support and
> integration. at some point, the two will intercommunicate so they can
> share advantages.
>
> for an example of how simple a stem message handler is:
>
> sub foo_cmd {
>
> return "foo was called\n" ;
> }
>
> that is a legal and working command message handler. if installed in a
> loaded and registered module, i could type a command to the Tty module:
>
> addr foo
>
> where addr is the address of that registered cell (stem object). the
> string will be printed on the tty. the object can be anywhere and the
> tty anywhere. can it get much simpler? :) that is what i mean about api
> design being critical. implementing that was worth the effort i paid in
> thinking about it for months before i coded a single line of code.
>
> and that is system level messaging.
>
> thanx,
>
> uri
>
> --
> Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
> -- Stem is an Open Source Network Development Toolkit and Application Suite -
> ----- Stem and Perl Development, Systems Architecture, Design and Coding ----
> Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
