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
