RE: mid-course correction on abstract model for module processing

	From ksankar@cisco.com Sat Mar 17 02:53 EST 2001
	Delivered-To: jones@research.att.com
	From: "Krishna Sankar" <ksankar@cisco.com>
	To: "Yuhichi Nakamura" <NAKAMURY@jp.ibm.com>,
	        "Mark Jones" <jones@research.att.com>
	Cc: <xml-dist-app@w3.org>
	Subject: RE: mid-course correction on abstract model for module processing
	Date: Fri, 16 Mar 2001 23:54:33 -0800
	MIME-Version: 1.0
	Content-Transfer-Encoding: 7bit
	X-Priority: 3 (Normal)
	X-MSMail-Priority: Normal
	Importance: Normal
	X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

	Hi,

		SOAP defines Actor as the recipient of a message and in that sense (for the
	current discussion) the Application is the recipient. And the handlers are
	extensions of an Application i.e. a handler by itself is an idle mechanism ;
	only an application makes it alive and interesting. So your assertion that
	Application = Actor is correct and application of course "contains"
	handlers. (Remember, in an actual implementation they (handler and
	application) could even be in different namespaces and communicating via
	messaging, COM,CORBA,RMI et al. But logically Application "contains"
	handlers for communication)

Application in the SOAP sense seems to imply all of the functionality
available at the processor, so I don't think application and the
SOAP-actor are the same.  From recent comments, people seem to prefer
thinking of an XMLP handler (a chunk of code) as the appropriate
target for a block.  From this, I assume that the SOAP-actor is a way
of referring to a particular chunk of code in the procesor.  The
default chunk when no actor is specified might be thought of as the
"application actor" I suppose.

		On a related note, I assume the handler is the physical manifestation (=
	XML protocol Processor), which processes XMLP messages which are modules
	which in turn are made up of blocks. 

The handler is code that processes blocks.  The module is an
abstraction comprising a set of handlers and the *definition*
of the types of blocks that they process.

        The distinction between a module and a
	handler is not clear to me yet.

	cheers

It hasn't been too clear to me either, but even when you get a handle
on the distinction there are still different, valid ways of conceiving
how the enterprise should work and a host of different viewpoints on
the targetting and processing issues:
 * how many applications run on a processor?
 * are blocks targetted at applications, modules or handlers?
 * ...

--mark

Received on Monday, 19 March 2001 10:22:28 UTC