RE: [Embedlets-dev] RE: repost of JAPL question...

[Christopher S. <cs...@oo...>]

To clarify (I hope)

It is usually advisable to maintain unidirectional visibility from the top
of a functional stack toward the bottom. This allows lower levels to be
utilized in a variety of unforeseen but useful ways, without dependence on
superfluous functionality of the upper layers.

My feeling is that it is Ok for Embedlets to be aware of and utilize the
JAPL Abstract API only, not the concrete JAPL classes. JAPL should not be
aware of the Embedlet layer (with one caviate). Here is the logic:

1. JAPL is in place to buffer the application logic (Embedlets) from the
nasty details of hardware initialization, operation and vendor specifics.
All that JAPL needs to know for that task is the hardware details, some way
to receive initialization properties and send notifications back.

2. Asynchronous communication back to the application logic should be
handled by a JAPLEvent notifying a JAPLEventListener. Embedlets can receive
events in this manner and translate them into the appropriate EmbedletEvent.
(this is already agreed to by all, I believe )

4. The JAPL layer should be isolated from Embedlets via interfaces so that
the implementing JAPL classes can be readily swapped out to accommodate
different hardware platforms. Embedlets should NEVER reference or
instantiate a concrete JAPL class.

5. JAPL should provide for dynamic instantiation of the implementing classes
in order to disconnect the Embedlet from specific JAPL classes and
properties. This neatly skirts the issue of where the 'impedance match'
takes place as you will see below. Each class handles it's specific
responsibility.

6. The JAPL API should be devoid of hardware specific references like
setBaudRate(9600), setParity(1), getPinNumber(0x80), setRegister(0x10,0xf4)
etc. These should be handled in the JAPL initialization code under the
covers. Embedlets should be able to simply 'grab' an output and start
sending info.

Here is a short code segment that outlines my expectation of an
Embedlet/JAPLOutput interaction, The input scenario would be a mirror image.

/** An vendor neutral Embedlet to adapt a Vendor specific JAPL output
driver.
* Provides an initialization environment and Event translation for the
driver.
*/

public class BooleanOutput extends Embedlet implements EventComsumer,
Persistent{

	private JAPLBooleanOutput output; // Interface only - no reference to
concrete JAPL class
	private EventProducer eventSource;
	private boolean value;
//...

	/** Component property initialization from Persistent interface
	*/
	public void readProperties(Properties properties) {

		value = properties.getIntProperty("InitialValue", value);
			// The specific JAPL class and its properties are defined
			//  in the persistent initialization store. The Embedlet is just grabing
			//  a reference to a ready-to-go JAPL device
		output = properties.getObjectProperty("OutputDevice", output);

		// Embedlet wiring
		eventSource = properties.getObjectProperty("EventSource", eventSource);
	}

	/** Component initialization
	*/
	public void initialize() {
		// Housekeeping
		super.initialize();

		// These may be handled by the container
		// Connect the wiring
		eventSource.registerEventConsumer(this);

		// Notify the output to get ready
		output.initialize();
	}

	/** Component start signal
	*/
	public void start() {
		super.start();
		output.setValue(value);
	}

	/** Service the incoming embedlet event by sending the boolean value
	* on to the JAPLOutput
	*/
	public void receive(Event event) {
		BooleanEvent e = event;
		value = e.getValue();
		output.setValue(value);
	}
}

(Please excuse any none-compile-able code this is for demonstration of
principle only)

The assumption here is that JAPL class implements the Persistent interface
so that it can be dynamically instantiated and receive initialization
parameters independent of the Embedlet (I can hear the uproar already). Note
that the Embedlet does not know any of the specifics of the underlying JAPL
device, other than it takes a boolean value and makes something happen out
there.


The deployment scenario would be:

1. A vendor provides the JAPL driver class (jar) and an XML snippet to
initialize the device.
2. The class gets included in the classPath or 'forName' linker list
3. The XML snippet gets placed inside of the Embedlet deployment descriptor:

<Embedlet
	name="DoorOpen"
	class="org.embedlet.io.BooleanOutput"
	InitialValue="true">

	<!-- Vendor specific IO driver snippet-->
	<Output
		name="IODriver"
		class="com.acme.io.GPIOPortPin"
		pinNumber="0x80"
		direction="1"
	/>
	<!-- End of vendor IO driver snippet-->

	<!-- Embedlet event wiring -->
	<EventSource href="components.logic.overflowLimit">
</Embedlet>


Using these guidelines there should be little overlap of functionality or
control. The layers are cleanly isolated yet interact efficiently.

The issue is going to be the dependence on the Persistent interface. My
response to that is that there is no way to avoid 'persistence' in a general
sense. Hard coded initialization of variables is a form of read-only
persistence. If the issue is not addressed at the JAPL level then it just
gets pushed up to the Embedlet level. Then every JAPL driver would need to
have a 'brother' Embedlet to manage its initialization. Pushing the
Persistent interface down to the JAPL level allows the layers to work
independent of each other and manage their own initialization
responsibilities.

If the application uses hard coded initialization values it is easy to
create a 'HardCodedProperties' class that holds the values in code. In this
scenario the container instantiates the 'HardCodedProperties' class and
hands it to the Embedlet readProperties() method. The JAPLDriver and
Embedlet work the same, unaware of the source of the Properties.

This allows a common Embedlet and JAPL code base to handle the dynamic
persistence store such as XML or fileStream as well as the the hard-coded
set-and-forget initialization.

My recomendation to side step the 'unidirectional' dictate above is to move
the Persistence API outside of, but common to, the Embedlet and JAPL API's,
limiting the baggage that needs to be hauled around for that function.

I have rambled on enough for tonight, it will probably make as much sense in
the morning as those drug induced, inspirational evenings of my youth.


Christopher Smith
OopScope, LLC.
www.oopscope.com
cs...@oo...
805-276-0598

> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of Ted
> Kosan
> Sent: Thursday, May 29, 2003 3:54 PM
> To: emb...@li...
> Subject: [Embedlets-dev] RE: repost of JAPL question...
>
>
> Topic tags:[ARCH][JAPL][WIRING][DOCS][MGMT][STRATEGY][NEWBIE]
> _______________________________________________
>
> I am in the process of jumping back into Embedlets 'hot-and-heavy' again
> (details to follow) but I would like to work through the JAPL
> Wrapper issue
> first.  The following is a repost of my latest question on this
> issue and I
> still really want to be convinced that using a JAPL Wrapper to
> only receive
> messages from a JAPL device and using an Embedlet to only send
> messages to a
> JAPL device is a good idea.
>
> Ted
>
>
> </repost>
>
> Andrzej,
>
> >Have my explanations of the use of a JAPL Wrapper class helped
> resolve this?
>
> Well, we are getting there but I still have some more questions
> so I hope you
> will bear with me!  ;-)
>
>
>
> >Maybe I am misinterpreting what JAPL does. If all it provides is a
> >thin generalization layer for specific classes of peripherals, then
> >we may need a Device Driver level of code layered on top of that.
>
> The understanding of JAPL peripherals that I have been working
> under is that
> they are generic, standardized interfaces for any kind of peripheral I/O
> circuits from simple I/O ports through medium complexity devices
> like UARTs and
> up to highly sophisticated I/O systems like a RobotScanner.  My working
> definition of what a device driver means in the context of
> Embedlets is that it
> is the piece of software that is responsible for doing the
> impedance matching
> between the I/O level semantics of the JAPL peripheral and the application
> level semantics of the Embedlet based application.
>
> For example, if a cannon were attached to bit 3 of a JAPL I/O
> port, then an
> event like fire forward cannon from the FireControl Embedlet
> would eventually
> get translated into something like JaplPort.setBit(3, true);
>
>
> >As for the asynchronous notifications (interrupts basically), see my
> >last post about using a JAPL Wrapper class as a mediation layer that
> >converts such an async callback into an Embedlet Event.  There is
> >MASSIVE benefit to using such an approach....the principal one being
> >keeping the JAPL and Embedlet layers nicely decoupled and flexible
> >(so that JAPL can be used outside of an Embedlet Container).
>
> Well, I am trying to understand how the Embedlet registering itself as a
> listener for Events coming from a JAPL peripheral it already has
> a reference to
> makes the JAPL peripheral at all dependent on the Embedlet code base?  My
> approach was to have the JAPL library contain an interface like
> the following:
>
> package org.japl;
>
> public interface JaplEventListener
> {
>     void receiveJaplEvent(Object japlEvent);
> }//end method
>
> and then the Embedlet would implement this interface and then
> register itself
> as a JaplEventListener just like any other JAPL client would.  If
> the Embedlet
> already has a dependency on the JAPL peripheral, what is the harm
> of allowing
> it to have a further dependency on a JAPL interface?
>
> My thought was that for any given JAPL peripheral, one Embedlet in the
> application would be used to wrap around it and then all the code
> needed to
> perform the semantic impedance matching with this JAPL device
> would be isolated
> inside of this single Embedlet (including messaging code and JAPL event
> handling code).
>
>
> >1) Hold direct references to JAPL peripherals.
> >2) Accept interrupt events from these peripherals.
> >3) Convert the peripheral's interrupt events into Embedlet events.
> >
> >The combination of the JAPL peripheral (and any "device driver code)
> >and the proposed JAPL wrapper approach nicely handle all of the
> >above situations. But an Embedlet can hold a reference to a JAPL
> >peripheral (so as to issue API method calls on it to get it's work
> >done.  eg.  japl.setSwitch( true ) ).
>
> I am still trying to understand what the benefit is of allowing
> an Embedlet to
> send sub-application-semantic-level messages directly to a JAPL
> peripheral but
> to have sub-application-semantic-level  asynchronous events
> coming from the
> JAPL peripheral to be broadcast to an arbitrary number of
> Embedlets via the
> Embedlets event mechanism?
>
> I think you are going to say that the JAPL wrapper will convert
> between the I/O
> level semantics of the JAPL peripheral and the application-level
> semantics of
> the application but I still can't see why all of this impedance
> matching is not
> happening in one place (either all in one Embedlet or all in the
> JAPL wrapper)?
>
> From my perspective, this is the kind of situation that is confusing me:
>
> - A SerialTerminalEmbedlet instantiates a JaplUart peripheral and
> initializes
> it to 9600,8,N,1 in its initialize() method using I/O level semantics.
>
> - All application-semantic-level data that is sent to the
> terminal's screen by
> other Embedlets in the application is sent via Embedlet events to the
> SerialTerminalEmbedlet because it is the only piece of software in the
> application that has a reference to the JaplUart and so can send
> messages to
> it.
>
>
> - As asynchronous I/O level semantic data comes in from the
> JaplUart, it is
> routed through the JAPL wrapper and then published to the Embedlet event
> system.  As posted in earlier emails, only application level
> semantics should
> be sent through the Embedlet event system so the JAPL wrapper
> would need to
> convert the I/O event semantics into application level semantics before
> publishing to the application.
>
> So, why does all of the outgoing Embedlet/JAPL impedance matching
> happen in an
> Embedlet and all of the incoming JAPL/Embedlet impedance matching
> happen in a
> completely separate and unrelated piece of software (the JAPL
> wrapper)?  Why
> not let one Embedlet handle impedance matching in both directions
> since having
> an Embedlet implement something like the JaplEventListener
> interface completely
> prevents JAPL peripherals from having dependencies on Embedlets?
>
>
> Again, my main goal here is to completely understand the
> reasoning behind the
> decisions being made in this part of the architecture so please
> bear with me
> because I am having a tough time with it!  ;-)
>
> Ted
>
> </repost>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>