embedlets-developer — Outpost Embedlet container developer list

RE: [Embedlets-dev] [Arch] JMX Management

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

 Topic tags:[Arch][Wiring][Doc][HW][PM]
 _______________________________________________

Sounds like we are very much in sync (see following excerpt).

Not to get hung up on the syntax, but I would like to point out that passing
around the XML serialized object itself as the response has one or two
advantages:

1. Multiple attributes can be returned in one request, as opposed to
multiple requests required for an RPC/SOAP based scheme.
2. The object packet is self documenting. The requester needs to know only
the id of the object and not every attribute. This decouples the
requester/responder very effectively.
3. The ability to 'turn-around' the packet with modifications forms the
basis for Embedlet update.
4. The 'object packet' scheme supports persistence in any form (flash, file,
database etc.) based on the provider, without additional code or XML
vocabulary.

Item 2 leads to a very nice bonus capability where a generic property editor
without prior knowledge can:

1. Query the container for its list of Embedlet names/ids
2. Select an Embedlet and send a 'getProperties' request. (Note the plural
form).
3. Display/edit the returned object properties in a name/value grid.
4. Modify and update via a 'setProperties' request that returns the modified
object packet.

The responder has control over the properties that are exposed/read/written
unlike native Java serialization.

The disadvantage of course is that getting the whole object packet is likely
to be more expensive than a single RPC query, but probably not more
expensive than 2. If this were an issue the container could filter the
response down to the requested property.


>
> > For example a request:
> >
> > <Request command="getProperties" identity="CB_OUTPUT_1"/>
> >
> > The response:
> >
> > <Light identity="CB_OUTPUT_1" name="Light 30212" value="On" .../>
> >
> > This can easily be handled by one of the small-footprint parsers or a
> > hand-rolled byte level parser. It is in stripped XML form so
> that an upper
> > level transport can simply enclose it into a full envelope or
> transform it
> > to established protocols. Collections, compound objects and
> reference links
> > are possible using this technique as well.
>
> Exactly right.  That is what I've been thinking all along,
> however, I think your example
> is too application specific.
>
> The name of the feature/embedlet /device (Lights) would probably
> never be an
> element or attribute.  Doing this ties your vocabulary to the
> specific domain
> application (light control in the this example). XML management
> syntax would have
> be more generic than that to provide a universal management
> capability across
> any/all embedlets.  For instance, the request to get a property
> from a managed
> object (embedlet) would look more like:
>
> <request target="embedlet"
> 	type="light"
> 	id="30212"
> 	operation="getProperty"
> 	property="CB_OUTPUT_1" />
>
> and the response would be more like:
>
> <response target="embedlet"
> 	type="light"
> 	id="30212"
> 	property="CB_OUTPUT_1"
>     	value="On" />
>
> Very similar to your example, but extensible to ALL management
> functions, since the
> element tags and attributes are defined by the Embedlet Management XML
> Schema....and only the values are unique to the specific
> embedlet/application. (Don't
> get hyper about the example syntax...it's just an example to get
> the concept across,
> not a "proposal" for how the Management XML Schema should
> actually look. In fact,
> there would be value in using a SOAP-based RPC approach to the
> XML managment
> schema since it maps nicely to the remote RPC-like JMX API's
> cleanly and there are
> a lot of back end tools that let you create/consume such Web Services RPC
> requests without having to bother with the SOAP/XML "plumbing").
>
> For example, to control a GPS device the request might look like:
>
> <request target="embedlet"
> 	type="GPS"
> 	id="myGPS"
> 	operation="setProperty"
> 	property="GPSProtocol"
> 	value="NMEA"/>
>
> Same syntax, different application altogether!  But this allows
> us to implement a
> generic Management Service that all Embedlets can utilize.  The
> user wouldn't even
> have to know anything about the underlying XML syntax, since this
> would be
> automatically assembled and then parsed at both ends (JMX API's
> used by the
> remote GUI control app to issue the request through the JMX
> Adapter, then across
> the comm link and the to the Outpost Managment Service API used
> by the Embedlet
> to respond to the request).
>
> I know I'm splitting hairs here...but such genericity has to be
> implicit in the design of
> our protocols and XML vocabularies/schemas for the container to
> be able to provide
> useful, generic, reuseable services, so I thought it worth noting.
>
> > This becomes the foundation for building complex systems out of
> very simple
> > rules, as Andrzej has proposed.
>
> Yuppers! ;-)
>

Re: [Embedlets-dev] Re: [Arch] ANT

[Brill P. <bri...@ro...>]

> One reason is because using Ant or not makes a significant impact on how
the
> Wiring Tool is designed.  If we make the decision to go with Ant then I
can see
> how the Wiring Tool could heavily leverage Ant's capabilities for
everything
> from application assembly to packaging and deployment.  It would be much
easier
> to start laying out the architecture of the Wiring Tool if this decision
were
> made up front.

Why would it matter to the wiring tool if you used Ant in the dev.
environment?
I assume the application does not need Ant to work.

If you want to use XML for the wiring "file format" you might try the
built-in registry stuff in JDK1.4.. its fairly good, and you can export the
XML... I've actually already used it that way to create a standard "file
format" for another application.
Anyway, using Ant would work and might provide a good tool for those who
want to use a command-line system... however I don't think the XML file
format *has* to be the Ant format... in fact I could think of some arguments
against it (also for it but thats another thing) starting with separation of
usage (which I think is a good idea in this case).

> The Wiring Tool is one reason to make this decision now and here is
another.
> After studying how Ant is leveraged in the Architecture document, it is
> becoming increasingly obvious to me that without something like Ant that
> Embedlets can not reach their full potential.

Embedlets should not depend on Ant... though tools may be written for Ant to
access the Embled implementation (Outpost). IMO.

- Brill Pappin

[Embedlets-dev] Re: ANT

[Andrzej J. T. <an...@ch...>]

Ted suggests:

> Of course, I am not saying that we should build all of these format
> customization capabilities up front but rather, allow a way for people to
> scratch this particular type of itch if they so desire.

Better still, let's defer the discussion of build tools till we have something to 
build. ;-)

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] [Arch] JMX Management

[Andrzej J. T. <an...@ch...>]

Chris said (re GUIs for Control functions):

>  am assuming that they have none. The devices that provide the UI need to
> be able to communicate directly and simply with the Embedlets. Envision a
> plant operator walking up to a device with his wireless or wired hand-held
> to make adjustments to the system. 

Makes sense.  I think it is well beyond our scope to try and create a UI library to 
support devices that have display capability, and it would likely be best to just adopt 
and implement the MIDP LCDUI API if such was needed on the platform itself, but 
that should be a separate project from Embedlets probably.

> Requiring JMX as the sole management
> interface would, I think, put a very large infrastructure demand on that
> simple interaction. 

I think you'll be pleasantly surprised.  If you compare the JMX standard with the 
Embedlets Architecture (as outlined in the discussion document), you'll find there is a 
lot of conceptual similarity (deliberate on my part ;-)  between Embedlets and JMX).  
At a conceptual level there are a lot of parallels between the two architectures, with 
the mapping (conceptual, not intended to imply inheritance or implementation 
dependency) looking something like:

Outpost/Embedlets			JMX
--------------------------			--------------------
Outpost Container			MBean Server (and managed resource 
itself)
Outpost Services			JMX Agents/Services
Embedlet				MBean (managed resource/properties)
Event Manager Service		JMX Notifications
Timer Service				JMX Timer Agent/Service
Monitoring Service			JMX Monitoring Agent/Service
Protocol/Transport Adapter		JMX Connector/Adapter

Now if you look at the JMX spec, external management is done through a 
protocol/transport adapter, which exposes the JMX interfaces/API's at the 
management end.  This means we can implement some hooks in the Outpost 
Container and Services, along with a custom Protocol/Transport Adapter (probably 
using Web Services, eg. SOAP/XML/HTTP) that exposes the Embedlet 
management functions outside the device.  Note that we do NOT need to implement 
the actual JMX interfaces in the embedded container!  On the management side 
(management console, server side JMX-aware management tool like Tivoli for 
instance) all we need to do is provide an adapter that can translate our Management 
Protocol (XML vocabulary) into the real JMX interfaces, classes and methods.  This 
can be done because the preliminary architecture I documented deliberately maps 
nicely onto JMX concepts as well.

So we get the best of both worlds, optional, but very lightweight Management Service 
on the embedded device, with an external JMX-compatible (but decoupled) adapter 
and tools (like your Process Control UI remote app) layer that translates from the 
Outpost Management protocol to JMX standard APIs (and vice versa).

One of the benefits of this is anyone writing external control or management 
applications can use a standard API to do this, namely JMX, which is gaining ground 
very rapidly.  If there is a standard way of doing something there is a lot of value to 
adopting that approach, since it widens the market and gives more 
credibility/acceptance value. Using this approach, the glass-house server operations 
boys could actually use Tivoli, OpenView or such to manage the distributed 
Embedlets!  In fact, this approach would let operations staff (which could be the shop 
floor operator, foreman, plant manager, etc.) receive real time alerts if things start to 
go amiss...and get those through the corporations normal management 
infrastructure. Wow...now that's a sales/adoption feature big time!  Management 
is/will be a big issue with thousands of Embedlets flung around a corporation and 
integrated to the back ends.

Just like Ted, you can have your cake and eat it too, Chris! <grins>

> It would also lock out other socket/XML capable
> interfaces such as ActiveX (yes it still lives), .NET, Perl etc.

With the solution that I envision (see above) with the Management capability 
exposed as a Web Service (SOAP/XML), it would be trivial to integrate into any other 
back end technology that was not JMX enabled, such as the ones you mention, yet 
still provide tight integration with JMX-based management solutions where desired, 
with minimal performance or footprint penalty.

> I agree
> that a JMX/Embedlet Adapter would defintely be a huge boost to the
> acceptablility at the Enterprise management level.

Absolutely!  Even if they don't use it right away (or ever) it's a very, VERY big selling 
feature.  Remote management of Embedlets, to the point of enabling integration with 
the large, common back end management systems (eg, Tivoli) would be a HUGE 
benefit for Embedlets.  I would even say it would be more important than many other 
features of Outpost.  Manageability is a key issue for corporate systems when they 
become integrated together (which is one of our key goals).

> It is my assertion, however that we need and can have a simple dynamic
> configuration, persistence and management interface without significant
> footprint bloat, possibly relieving the requirement for a tool-heavy
> static build process.

I agree that we need these capabilities, but there are very good architectural reasons 
to make them decoupled, independent (of each other) and optional Outpost 
Container services.  Take Persistence for instance.  It should be generic enough to 
store/retrieve any arbitrary data...not just config files.  There may be good reason for 
an application to use persistance, but it may not need dynamic reconfig.  Think 
"service-oriented" rather than "interface-oriented" (though it can be very convenient 
to have a Persistable interface implemented by objects that are candidates for 
storage).

Dynamic config has already been added as an optional service to the 1.2 
Architecture Discussion Doc.  So has Persistence.  Management I talked about 
earlier.  I expect to add more detail to all three of these service "definitions" in the 
document (to preserve our thinking) per my comments in this email, in the next 
release of the document (1.3).

I think that when more of the details of my (admittedly warped at times) thinking 
come to light, you'll see that you'll be able to handle the kind of applications you have 
described, without compromising the lightweight design goals of an Embedlet server, 
and also be able to leverage more modularity, flexibility and standards (eg. JMX).

> A bold statement I know, but I am prepared to back it up with some coded
> examples.

I've read some of your stuff already.....will be reviewing the JavaDocs in the next day 
or two regarding your implementation of some of these concepts.

Gregg then clarifies:

> The MBean would not necessarily have to be on the device.  If we spec
> a very simple text based admin protocol that provides 'events',
> 'properties' and 'actions', then we can write a single MBean that can
> run on the managers device, and talk via a serial network to the
> device.  This would facilitate remote management in places where
> device have a network to somewhere else....  But a serial port could
> be used for management of individual devices. 

Bingo! Exactly my thinking, Gregg!  Larger platforms (maybe JStik's or PC's) might 
want to actually implement MBeans on the controller (there are some benefits to that 
approach, and it could be implemented as a decorator layer without touching the 
core embedlet container code)....but for the most part, a decent XML-based 
management vocabulary, exposed as a web service over HTTP would give us way 
more flexibility, even to the point of providing management across serial cable 
connections (or wireless equivalents like Bluetooth).  The possbilities are very 
exciting and would make a very compelling "pitch".

Chris then provides an example:

> For example a request:
> 
> <Request command="getProperties" identity="CB_OUTPUT_1"/>
> 
> The response:
> 
> <Light identity="CB_OUTPUT_1" name="Light 30212" value="On" .../>
> 
> This can easily be handled by one of the small-footprint parsers or a
> hand-rolled byte level parser. It is in stripped XML form so that an upper
> level transport can simply enclose it into a full envelope or transform it
> to established protocols. Collections, compound objects and reference links
> are possible using this technique as well.

Exactly right.  That is what I've been thinking all along, however, I think your example 
is too application specific.

The name of the feature/embedlet /device (Lights) would probably never be an 
element or attribute.  Doing this ties your vocabulary to the specific domain 
application (light control in the this example). XML management syntax would have 
be more generic than that to provide a universal management capability across 
any/all embedlets.  For instance, the request to get a property from a managed 
object (embedlet) would look more like:  

<request target="embedlet" 
	type="light" 
	id="30212" 
	operation="getProperty"  		
	property="CB_OUTPUT_1" />

and the response would be more like:

<response target="embedlet" 
	type="light" 
	id="30212" 
	property="CB_OUTPUT_1" 
    	value="On" />

Very similar to your example, but extensible to ALL management functions, since the 
element tags and attributes are defined by the Embedlet Management XML 
Schema....and only the values are unique to the specific embedlet/application. (Don't 
get hyper about the example syntax...it's just an example to get the concept across, 
not a "proposal" for how the Management XML Schema should actually look. In fact, 
there would be value in using a SOAP-based RPC approach to the XML managment 
schema since it maps nicely to the remote RPC-like JMX API's cleanly and there are 
a lot of back end tools that let you create/consume such Web Services RPC 
requests without having to bother with the SOAP/XML "plumbing").

For example, to control a GPS device the request might look like:

<request target="embedlet" 
	type="GPS" 
	id="myGPS" 
	operation="setProperty"  		
	property="GPSProtocol" 
	value="NMEA"/>

Same syntax, different application altogether!  But this allows us to implement a 
generic Management Service that all Embedlets can utilize.  The user wouldn't even 
have to know anything about the underlying XML syntax, since this would be 
automatically assembled and then parsed at both ends (JMX API's used by the 
remote GUI control app to issue the request through the JMX Adapter, then across 
the comm link and the to the Outpost Managment Service API used by the Embedlet 
to respond to the request).

I know I'm splitting hairs here...but such genericity has to be implicit in the design of 
our protocols and XML vocabularies/schemas for the container to be able to provide 
useful, generic, reuseable services, so I thought it worth noting.

> This becomes the foundation for building complex systems out of very simple
> rules, as Andrzej has proposed.

Yuppers! ;-)

BTW....I'm typing this in a coffee shop while waiting to give a presentation on Web 
Services (the MGDP project) and ebXML to the Toronto Java Users Group in about 
an hour.  I'll be mentioning the Outpost/Embedlets initiative at the presentation. It 
might engender some more victims....ooops.....I mean interest and volunteers. ;-)



...Andrzej

Chaeron Corporation
http://www.chaeron.com

[Embedlets-dev] Re: What is Outpost?

[Ted K. <tk...@ya...>]

Brill,

> I'm a little confused about what we're doing here with Outpost, the original
> ideas was a pluggable system for monitoring/controlling hardware from an
> enterprise system... Of course Embedlets where to support that.
> 
> So, have we moved to a specifically embedlet focus, or is Outpost still the
> end product?
> 
> Personally, I think both can be done, but I think they are two different
> streams, and if we're not careful we'll get bogged down in the link between
> the two.

The 'Embedlet specification' is analogous to the 'Servlet specification'.

An 'Embedlet Container' is analogous to a 'Servlet Container'.

'Outpost' is analogous to 'Tomcat'.  Both are the reference implementations of
their respective specifications.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-dev] [PM] CVS 'management' folder

[Brill P. <bri...@ro...>]

I like this...
the sub projects could be further broken down depending on the context as
well...

I've been too busy, and the list has had so much activity, that I haven't
been able to read it all... I think it's high time some formal documentation
was created :)

- Brill Pappin
  Rogue Robotics
  www.roguerobotics.com


----- Original Message -----
From: "Ted Kosan" <tk...@ya...>
To: <emb...@li...>
Sent: Monday, February 03, 2003 10:18 PM
Subject: [Embedlets-dev] [PM] CVS 'management' folder


> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
> I like the way that Andrzej has broken down the project into the following
> subprojects.  Perhaps we should place a 'management' folder into the CVS
so
> that we can put management related documents like this in there?
>
>
> Ted
>
>
> SUBPROJECTS
>
> 1) Outpost Container for Embedlets  (the software infrastructure).
>   -Description:
>   -Goals:
>   -Members: Andrzej.
>
> 2) JAPL specification and concrete implementations
>   -Description:
>   -Goals:
>   -Members: CORK team.
>
> 3) Hardware interface standardization/development.
>   -Description:
>   -Goals:
>   -Members: CORK team.
>
> 4) Graphical Wiring Tool.
>   -Description:
>   -Goals:
>   -Members: Ted.
>
> 5) uVM
>   -Description:
>   -Goals:
>   -Members: James.
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>

[Embedlets-dev] Re: [Embedlets-developer] Re: Real Time

[Brill P. <bri...@ro...>]

I'm a little confused about what we're doing here with Outpost, the original
ideas was a pluggable system for monitoring/controlling hardware from an
enterprise system... Of course Embedlets where to support that.

So, have we moved to a specifically embedlet focus, or is Outpost still the
end product?

Personally, I think both can be done, but I think they are two different
streams, and if we're not careful we'll get bogged down in the link between
the two.

- Brill Pappin


----- Original Message -----
From: "Andrzej Jan Taramina" <an...@ch...>
To: <emb...@li...>
Sent: Sunday, February 02, 2003 12:13 PM
Subject: [Embedlets-developer] Re: Real Time


> James raises a good point:
>
> > I think it is the real-time nature of Embedded programming that puts
> > people in a bit of a spin.
>
> I've been thinking about this.  Creation of a container implementation
that can
> support real-time (in the strict, embedded sense of the word) is a very
difficult
> task.  My current thinking is that Embedlets won't be able to support pure
real
> time (with the millisecond response times and prioritizations this
requires) in
> it's first few incarnations, and that this would be too ambitious a goal
for us to
> try and tackle out of the gate.
>
> Thoughts?
>
> > only need to look back at the Nutty Threading problems to understand
that
> > simulataneous processes are confusing.
>
> That was primarily confusing due to the bug that is buried in the aJile
runtime.
> Though threads are confusing to many.
>
> > With the combinatorial problem of
> > so many things going on at once, embedded programmers first instinct is
to
> > reduce the number of possible things that can be wrong.
>
> Compared to modern server side containers, embedded controllers can be
> very simple, with much less simultaneous stuff going on that in something
like
> an EJB or Servlet container.  I see the push to simplify as something that
> happens in all levels of software development, from embedded to
enterprise.
> Part of the problem solving and debugging process.
>
> I think Ted hit a nerve, noting that many software guys are afraid of
hardware.
> Which is amusing, since so many of them have no problem building and
> reconfiguring their PC hardware.  Diff'rent strokes I suppose.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer

[Embedlets-dev] Re: [Embedlets-developer] Re: Dinner and drinks...

[Brill P. <bri...@ro...>]

> I'm also presenting to the Toronto Java Users Group this Tuesday....MGDP
> (embedded GPS/Systronix project) and ebXML topics.  Will probably mention

It was a good presentation... very interesting... I was particularly
impressed with the ebXML layer.

- Brill Pappin

RE: [Embedlets-dev] Re: Ant

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

Greg commented:
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> I am not trying to make an argument against Ant here.  I am
> trying to make an
> argument against unnecessary complications in the build step just
> because.
> Tools that provide automation become crutches quickly, and if you
> don't think
> about what you're doing, you can create such a dependency that
> suddenly your
> software architecture and many other things are suddenly governed by the
> tools, instead of the tools facilitating a good architecture...
>
> -----
> gr...@cy...  (Cyte Technologies Inc)
>

I tend to agree with Gregg and his desire to keep the architecture simple
enough as to preclude the requirement for a tool- dependent build process.

As successful as J2EE is, the development cycle is frustratingly complex,
slow, error prone and difficult to debug. With J2EE  the requirements for
ultimate scalability and performance overrode any developer friendly
considerations. It has taken hold and the tools are catching up but I think
that we should consider that it has had the weight of SUN, IBM, Netscape,
BEA etc behind it as well as a large void in the market. We are not likely
to find ourselves in that position.

Embedded systems are currently specked, designed and deployed by hardware
oriented engineers who like to see their bits twiddle. Their current cycle
involves: code, compile/link, load and debug... complex enough but
understandable and debug-gable at the source level. Adding several levels to
this, including a code generator is likely to meet some stiff resistance.

Chris Smith
OopScope

[Embedlets-dev] RE:[Arch] More Ant

[Ted K. <tk...@ya...>]

After studying how Andrzej leverages Ant across all parts of the Embedlet build
process I must agree that it is going to prove to be a great enabling
technology for us.

However, I also understand some of Gregg's concerns and I am now wondering if
one solution would be to leverage Ant more, instead of less, by using it to
generate project directories in the various formats that any given IDE, or even
a batch file oriented command line user, might want to use.

Of course, I am not saying that we should build all of these format
customization capabilities up front but rather, allow a way for people to
scratch this particular type of itch if they so desire.


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-dev] FW: Embedlets Architecture: Dynamic Configs and Persistence...

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

Here is a post of a background discussion that Andrzej and I had that I
think has general interest: (Andrzej's response to follow)

Andrzej,

The typical scenario is:

1. A new system is installed with new similar but significantly different
hardware, more inputs, valves, etc compared to the last 25 systems.
2. There is a flowchart or written specification of the process defining the
inputs, computations comparisons, logical operations and outputs.

3. The Embedlets required to implement the spec are pre-installed on the
target system, available to the Container.

4. The system is wired using a graphical tool or the XML configuration on
the Workstation.

5. The configuration is downloaded as an XML stream to the target.

6. The Container instantiates the required Embedlets and wires them together
based on the configuration.

7. Modifications to individual Embedlet settings (calibration, scale
factors, limit thresholds, time delays) are adjusted on the running system
similar to adjusting potentiometers on analog systems.

8. The finalized configuration and the adjustments are stored in the targets
flash ROM for immediate recall as well as on the workstation for backup and
versioning.

9. Any variations in the system or alternate configuration settings are done
in real time and likewise saved.

Notice that the code is compiled/linked/installed only once and is used on
all systems whose requirements are within the constraints of the available
Embedlets. This reduces the number of binary packages that need to be
generated, QA'ed and tracked. In my experience this is a very typical
scenario in facilities management, industrial controls, aerospace and home
automation.

Constrained systems might be deployed with workstation generated 'hard
wired' configuration, but they will still need some query capability and
quite likely the ability to update one or more Embedlet parameters.

I have found that the instantiation, serialization/deserialization,
local/remote persistence and property queries/updates can all be handled by
the same interface and a compact piece of implementation code at the
Component/Embedlet level. Please review the Persistence package of OPC for
details.

To respond to your suggestion that JMX and JMS be used as management and
communication protocols: I agree completely. I would not however think that
this would be a part of our mission statement. If we have defined a simple
XML payload with Socket based communication, this can be easily packaged
within a JMS, SOAP... envelope for transport to distributed Enterprise
systems.

I look forward to your document release and feedback on OPC applicability.

P.S. I am in Thousand Oaks, CA (PST)
805-276-0598

-----Original Message-----
From: Andrzej Jan Taramina [mailto:an...@ch...]
Sent: Sunday, February 02, 2003 10:17 AM
To: cs...@oo...
Subject: RE: Embedlets Architecture: Dynamic Configs and Persistence...


Chris:

> A very thoughtful, thorough and well presented document - think that it is
> ready for open discussion.

Thanks...I might tweak it a touch based on your comments, and it should go
out later today or tomorrow sometime.

> I am 90% in agreement with your spec and am struck by the very close
> parallel with the work that I have done so far. This is very encouraging!

Excellent.  I hope it's a case of "great minds thinking alike" rather than
"fools
seldom differ" ;-)

> I have put a little more emphasis on the dynamic configuration primarily
> because that was a requirement for the types of applications that I was
> working on. In the Ajile chips this is achieved by using the static
> 'forName' registration of classes in an available pool then instanciating
> then on demand via an XML configuration. This works pretty well in
> situations where you need to have flexibility within the contraints of the
> type of system deployed.
>
> For example: A system controlling X outputs via Y inputs (lighting
> control) where X and Y can vary. Here the number of Embedlet classes would
> be known and limited but the number of instances and their cross wiring
> can change often. It would be desirable to have the same deployed package
> handle hardware and functionality scaling without having to resort to a
> full deployment cycle.

Are you envisioning a situation where the new config information would be
sent over a connection (say XML over HTTP) to the embedded device, which
would then re-config itself for the new lighting situation?

If so, the architecture I am thinking of would allow for that.  Even though
the
initial config would be "hardcoded" in a generated java class (possibly as a
static singleton instance of the class), the methods to change the config or
build a new one would be still present.  Then all you would need is a
ConfigManager Embedlet that would get the new info (over a connection),
create the new config object, and would ask the Container to restart the
Lighting Embedlet, at which time it could read the new config and keep
running.  Maybe not right off the bat though.....need to get a prototype
running
first with static builds I think.

> Persistence is also an issue in these types of systems because you do not
> want to have to reload your lighting configuration remotely every time you
> have a power restart. The system should be able to automatically store and
> load a configuration locally. Other systems such as manufacturing controls
> may need to have several or even hundreds of configurations available to
> an operator without involving a remote (perhaps not available) system.

Many of these devices don't have external storage, so for a power cycle, you
would have to put the code/configs in flash.  That would solve the issue for
many embedded applications.

My gut feel tells me that the best way to tackle this type of approach (for
a first
cut) is to create a ConfigEmbedlet that handles multiple configs and can be
triggered externally (switch settings, TCP/IP, serial, etc) to restart the
application Embedlet (Lighting in the example).  This makes the container
lighter in weight for the more limited environments, and let's us get some
experience with this type of app before including the functionality as a
more
formal (though probably optional) Container Service.

My vision here is based on the use of the event model for most
command/control and service access functions.  All the ConfigEmbedlet would
need to do is produce a RestartEmbedlet event and send it to the container
to
effect a reconfig (it's a bit more complicated than that, but this is the
key
concept).

By allowing such things, the Container's services can be extended by adding
Embedlets that provide "services" in response to specific event types.  If
they
become common needs, then they can be wired more tightly into the container
implementations.

> Fortunately as you pointed out the solution to these can be easily
> incorporated. In OopScope there is a 'Persistent' interface which actually
> handles both issues and provides remote query capability - an issue in any
> size system.

Maybe the answer (initially) is to create a Container with the right API's
and
events that will support the creation of a Persistence Embedlet that can
provide these services to other Embedlets?  That sounds very attractive to
me,
since it keeps the actual Container footprint very small.

The whole thing revolves around a "fuzzy definition" of what a service is
and
how to add new ones.  Synchronous services (that require method calls)
would probably have to be part of the container.  But event initiated
services
(asynchronous) could be part of the Container, or just Embedlets themselves.

Does all this rambling make sense?  Is it a viable way to handle the Dynamic
Reconfig and Persistence issues, at least initially?

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

RE: [Embedlets-dev] RE: Embedlets Architecture: Dynamic Configs and Persistence...

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

> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
>
> >I am assuming that they have none. The devices that provide the
> UI need to
> >be able to communicate directly and simply with the Embedlets. Envision a
> >plant operator walking up to a device with his wireless or wired
> hand-held
> >to make adjustments to the system. Requiring JMX as the sole management
> >interface would, I think, put a very large infrastructure demand on that
> >simple interaction. It would also lock out other socket/XML capable
> >interfaces such as ActiveX (yes it still lives), .NET, Perl etc. I agree
> >that a JMX/Embedlet Adapter would defintely be a huge boost to the
> >acceptablility at the Enterprise management level.
>
> The MBean would not necessarily have to be on the device.  If we
> spec a very
> simple text based admin protocol that provides 'events', 'properties' and
> 'actions', then we can write a single MBean that can run on the managers
> device, and talk via a serial network to the device.  If you then
> make that
> protocol implementable as a Jini Surrogate implementation, then
> you could also
> use Jini's discovery mechanisms to allow embedlets to announce
> their presence.
> This would facilitate remote management in places where device
> have a network
> to somewhere else....  But a serial port could be used for management of
> individual devices.
> -----
> gr...@cy...  (Cyte Technologies Inc)
>

This is what I am advocating. The text based admin protocol would be a terse
XML form since it would not make sense to reinvent that wheel. I have found
that if XML elements are use to enclose objects and attributes are used to
define properties it can be very compact.

For example a request:

<Request command="getProperties" identity="CB_OUTPUT_1"/>

The response:

<Light identity="CB_OUTPUT_1" name="Light 30212" value="On" .../>

This can easily be handled by one of the small-footprint parsers or a
hand-rolled byte level parser. It is in stripped XML form so that an upper
level transport can simply enclose it into a full envelope or transform it
to established protocols. Collections, compound objects and reference links
are possible using this technique as well.

<Lights identity="LIGHT_COLLECTION_01"
class="org.embedlets.PersistentCollection">
	<Light identity="CB_OUTPUT_1" class="com.myCompany.GPIOOutputPin"
name="Light 30212" ...>
  		<EventSource href="SWITCH_992"/>
	</Light>
</Lights>

This becomes the foundation for building complex systems out of very simple
rules, as Andrzej has proposed.

[Embedlets-dev] [PM] Project management issue

[Ted K. <tk...@ya...>]

Chris stated:

>I emphasize that we need a solid action plan based on 
>Andrzej's architectural outline and at start to get some 
>roadbed down in preparation for actual track.

I do not know about the rest of you but this is my first experience with open
source software development and I do not have a good feel for how organized or
loose the management of these types of projects should be.  

Since Nicola has extensive open source development experience, perhaps he could
give us some pointers about how to manage the Embedlets project?


Also, last week I said that I would go through the list archives and place the
main ideas we had generated into a document.  After doing this I found that
these main ideas had already been nicely laid out in Andrzej's Architecture
document so I decided that there was no need for me to post anything in
addition to this.

Ted


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-dev] RE: Embedlets Architecture: Dynamic Configs and Persistence...

[Gregg G. W. <gr...@sk...>]

>I am assuming that they have none. The devices that provide the UI need to
>be able to communicate directly and simply with the Embedlets. Envision a
>plant operator walking up to a device with his wireless or wired hand-held
>to make adjustments to the system. Requiring JMX as the sole management
>interface would, I think, put a very large infrastructure demand on that
>simple interaction. It would also lock out other socket/XML capable
>interfaces such as ActiveX (yes it still lives), .NET, Perl etc. I agree
>that a JMX/Embedlet Adapter would defintely be a huge boost to the
>acceptablility at the Enterprise management level.

The MBean would not necessarily have to be on the device.  If we spec a very 
simple text based admin protocol that provides 'events', 'properties' and 
'actions', then we can write a single MBean that can run on the managers 
device, and talk via a serial network to the device.  If you then make that 
protocol implementable as a Jini Surrogate implementation, then you could also 
use Jini's discovery mechanisms to allow embedlets to announce their presence. 
This would facilitate remote management in places where device have a network 
to somewhere else....  But a serial port could be used for management of 
individual devices.
-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-dev] [PM] CVS 'management' folder

[Ted K. <tk...@ya...>]

I like the way that Andrzej has broken down the project into the following
subprojects.  Perhaps we should place a 'management' folder into the CVS so
that we can put management related documents like this in there?


Ted


SUBPROJECTS

1) Outpost Container for Embedlets  (the software infrastructure).
  -Description:  
  -Goals: 
  -Members: Andrzej.

2) JAPL specification and concrete implementations
  -Description:
  -Goals:
  -Members: CORK team.

3) Hardware interface standardization/development.
  -Description:
  -Goals:
  -Members: CORK team.

4) Graphical Wiring Tool.
  -Description:
  -Goals:
  -Members: Ted.
  
5) uVM
  -Description:
  -Goals:
  -Members: James.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Embedlets-dev] Re: Ant

[Gregg G. W. <gr...@sk...>]

>No need, since Ant is integrated with most IDE's out there.  In fact, Ant is 
an
>automation tool for complex builds (and wiring Embedlets, JAPL drivers, 
>adapters and the like into a runnable app WILL be complex).

One of the IDEs I use is the vi editor, and it doesn't do integrated commands 
directly.

>> I am really against leaning against Ant for any configuration management
>> that can also be done in the code itself where late binding can yield some
>> other advantages.
>
>Every other container-based server out there uses Ant to simplify the builds. 
I
>don't think that Outpost will be any different.

Ahh, but mine doesn't, so don't say all :-)  

I am not trying to make an argument against Ant here.  I am trying to make an 
argument against unnecessary complications in the build step just because.  
Tools that provide automation become crutches quickly, and if you don't think 
about what you're doing, you can create such a dependency that suddenly your 
software architecture and many other things are suddenly governed by the 
tools, instead of the tools facilitating a good architecture...

-----
gr...@cy...  (Cyte Technologies Inc)

[Embedlets-dev] Re: Ant

[Andrzej J. T. <an...@ch...>]

Gregg:

> Yes, it is an automation tool.  And, just like CPP is an automation tool,
> ant can be abused to do configuration management because it's possible. 
> The postgresql dist includes the use of Ant for no reason at all.  The
> build process is stricktly Linux/Make based, and Ant is not necessary when
> Make is already in place.

True enough...but Ant is just a make replacement (albeit a more powerful and 
easier to use one).  We won't be using makefiles on this project.  Doesn't 
make sense.  (all puns intended. ;-) ).

> My IDE includes the ability to do all the things that Ant does, so I don't
> need to use Ant for my projects.  Running unit tests and other such tasks
> is a good use for running these tests portably.

Not everyone's IDE does....Ant will run on any JDK-enabled platform, and 
provides a common platform for builds that no IDE can.

> I just want to make sure that complexity is only a necessity,
> not a chain reaction.

No argument there!


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] [PM] Ted drops the ball

[Andrzej J. T. <an...@ch...>]

Ted admits:

> Evidently Sourceforge has a 40K default limit on posts and since this post
> had a pdf file attached to it the SourceForge site blocked it.  Another
> problem was that Andrzej had copied me on the post and so I received it
> and just assumed that everyone had (I did not notice that I was copied). 
> Finally, as the site administrator, the Sourceforge site did notify me
> that there was a problem with the post but at the time I did not
> understand what it was trying to tell me.

You trying to get "fired" from the Project Manager job that we foisted upon 
you?  Ha!  Not gonna work....you're not escaping that easily!  <grins>

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] Re: I want it yesterday...

[Andrzej J. T. <an...@ch...>]

Chris noted:

> Gentlemen, we need a concerted effort to get an accepted Embedlet standard
> in place and convince these and other emerging vendors that it is in their
> interest and the market as a whole to embrace a standard, otherwise our
> efforts will amount to just a lot of email traffic and the industry will
> disintegrate into another 'my standard is best' scenario.

I'm not sure that we need to be too worried.  The market is way too young and 
fragmented for a proprietary system to emerge as a standard that quickly.  
Proprietary solutions have their place.

Keep in mind that JBoss has become one of the most popular EJB containers 
out there....despite competition from BEA and IBM (most of the other have 
died).  Tomcat is a very popular Servlet container, and Apache dominates the 
web server market.  There are plenty of examples where an Open 
Source/Open Standard solution has "whooped ass" as my southern brethern 
would say.

> I emphasize that we need a solid action plan based on Andrzej's
> architectural outline and at start to get some roadbed down in preparation
> for actual track.

My next step is to review your Oopscope stuff, Chris, and then start creating 
some interfaces for "discussion" based on the architecture document and 
ongoing discussions.  That will probably speed things along rapidly, since I've 
been building a "mental model" of what the implementation and contracts 
might look like (to more detail that I had time to flesh out in the intial discussion 
doc).

> As the Vulture said to his buddy: "Patience my ass, I'm going to kill
> something!"

True....but we also don't want to rush either.  The Embedlet standard has to be 
flexible, solid, and extensible, plus support a wide range of platform 
capabilities.  This will take some time to create, to ensure maximum effect and 
longevity....and I doubt that any proprietary vendor will be able to beat us to 
the punch before then.



Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] RE: Embedlets Architecture: Dynamic Configs and Persistence...

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

<Andrzej>
>Many controllers won't have any display capability.  I see JMX
instrumentation
>as the best way to handle this situation for the more capable controllers,
and a
>custom solution (lightweight HTTP/HTML server on the controller?) for the
>smaller devices.

I am assuming that they have none. The devices that provide the UI need to
be able to communicate directly and simply with the Embedlets. Envision a
plant operator walking up to a device with his wireless or wired hand-held
to make adjustments to the system. Requiring JMX as the sole management
interface would, I think, put a very large infrastructure demand on that
simple interaction. It would also lock out other socket/XML capable
interfaces such as ActiveX (yes it still lives), .NET, Perl etc. I agree
that a JMX/Embedlet Adapter would defintely be a huge boost to the
acceptablility at the Enterprise management level.

It is my assertion, however that we need and can have a simple dynamic
configuration, persistence and management interface without significant
footprint bloat, possibly relieving the requirement for a tool-heavy static
build process.

A bold statement I know, but I am prepared to back it up with some coded
examples.

Chris

RE: [Embedlets-dev] Re: Threads

[James C. <ca...@vi...>]

>One benefit of this is the KISS principle for
>developers of Embedlets.  Most Java developers have trouble with
>threads....so it would be much nicer if (like with Servlets) threading was
>transparent and you never had to use them directly.

I tend to agree, I think the real-time layer is the JAPL/Cork layer.

I know this may seem weird but I have a gut feeling that RTJ may not
actually the best place to look for real-time performance other than quite
high level scheduling. Real 'real-time' is just so close to the bone of the
platform that I suspect it will be a while before RTJ is the prefered way of
handling it.

I think real-time is not the Embedlets problem nor is threading or the way
things happen in the Container ie. This is the container implementors
problem and even though we will have a reference implementation for this I
don't think the Embedlet container should specify HOW* it is implemented.
For instance I fully expect the muvium container is going to be 100%
assembler implementation of the Container Interface specification.

JAPL/Cork is natural real-time layer and I really like Ted's idea of JAPL
components publishing their real-time capabilities. Poor-man's real-time..
Hardly! This is more fine grained real-time than RTJ! And again, it should
be an interface that supports non-java implementations behind the scenes.

Finally, I don't there is a Real-time Silver Bullet so we shouldn't try to
integrate it into the spec upfront but as we gain more insight by tackling
real world problems it might make more sense to attach more Real-Time
details to the spec.

James Caska
http://www.muvium.com
'Java Bred for Embedded'




> -----Original Message-----
> From: emb...@li...
> [mailto:emb...@li...]On Behalf Of
> Andrzej Jan Taramina
> Sent: Tuesday, February 04, 2003 11:12 AM
> To: emb...@li...
> Subject: [Embedlets-dev] Re: Threads
>
>
> Topic tags:[Arch][Wiring][Doc][HW][PM]
> _______________________________________________
>
> Chris says:
>
> > One way to address this would be to have Embedlets designated as
> > thread-aware or unaware. The guidelines for thread aware Embedlets would
> > be set out based on RT requirements. It seems that that the container
> > would not have to be  concerned with RT threading. Am I right??
>
> Yup...that is one way to deal with it.  But I don't like the idea
> of Embedlets that
> are thread aware or not.  I would prefer to see Embedlets not
> have to worry
> about that, and the Outpost Build system to add any extra thread-based
> requirements depending on whether the Container was build to support
> threads or not (based on the platform's capabilities).  That is,
> the design
> contracts and patterns that an Embedlet has to abide by should be
> of such a
> nature that whether the container was threaded or not should (ideally) be
> transparent to the Embedlet code.  One benefit of this is the
> KISS principle for
> developers of Embedlets.  Most Java developers have trouble with
> threads....so it would be much nicer if (like with Servlets)
> threading was
> transparent and you never had to use them directly.
>
> It may be possible to design the Embedlet base classes and
> Outpost Services
> so that even though they support the same invocation signatures,
> one version
> supports threads under the covers (using synchronized methods under the
> covers for instance) and another version just uses a co-operative
> approach
> without threads.  There would probably be two different versions of the
> Scheduler/Event Manager Services as well.
>
> My gut feel is to implement in a 3 phase process: to first get a
> non-threaded
> implementaton of the Container working.  Then learn from that and add
> threads.  Then look at how to handle the RT requirements.
>
> If we try to do threads and RT off the bat, it will probably take
> way too long to
> get the first implementation out the door.
>
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Embedlets-developer mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embedlets-developer
>
>

[Embedlets-dev] FW: Embedlets Architecture: Dynamic Configs and Persistence...

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

Chris:

Thanks for documenting the scenario....this will definitely help the design
thinking as I plow into the details.  Some comments inline below...

> The typical scenario is:
>
> 1. A new system is installed with new similar but significantly different
> hardware, more inputs, valves, etc compared to the last 25 systems. 2.
> There is a flowchart or written specification of the process defining the
> inputs, computations comparisons, logical operations and outputs.
>
> 3. The Embedlets required to implement the spec are pre-installed on the
> target system, available to the Container.
>
> 4. The system is wired using a graphical tool or the XML configuration on
> the Workstation.
>
> 5. The configuration is downloaded as an XML stream to the target.
>
> 6. The Container instantiates the required Embedlets and wires them
> together based on the configuration.

We could do this.....but the XML parsing might be a bit tough on the smaller
platforms.  As such, I added a Dynamic Config/Context Optional Service to
the
architecture document, intended to provide such a capability.

Part of the problem here is that I intend to use the full power of the XML
libraries available on the PC for the build process, in generating the
"control
tables" and maybe even some intialization code from the XML Config data.
That includes XML Parsing (Xerces, SAX, Jakarta Digester) and XSLT
transforms (which might be very useful for generating code/tables from XML-
tagged Java source files).  Obviously, this level of processing will not be
available on even a JStik level controller.   On the controller itself, I
figured to
use the Enhydra kXML, kSOAP libraries since they work well, are open source
and have very small footprints.  Now if I can find a way to use kXML and
implement a very lightweight SAX layer on top of it, this would ease the
implementation of such a dynamic Config service.

Anyhow...it's in the document....so it will definitely be on the list.

> 7. Modifications to individual Embedlet settings (calibration, scale
> factors, limit thresholds, time delays) are adjusted on the running system
> similar to adjusting potentiometers on analog systems.

Many controllers won't have any display capability.  I see JMX
instrumentation
as the best way to handle this situation for the more capable controllers,
and a
custom solution (lightweight HTTP/HTML server on the controller?) for the
smaller devices.

> 8. The finalized configuration and the adjustments are stored in the
> targets flash ROM for immediate recall as well as on the workstation for
> backup and versioning.
>
> 9. Any variations in the system or alternate configuration settings are
> done in real time and likewise saved.
>
> Notice that the code is compiled/linked/installed only once and is used on
> all systems whose requirements are within the constraints of the available
> Embedlets. This reduces the number of binary packages that need to be
> generated, QA'ed and tracked. In my experience this is a very typical
> scenario in facilities management, industrial controls, aerospace and home
> automation.

Yup....a situation that we need to handle nicely for sure.

> Constrained systems might be deployed with workstation generated 'hard
> wired' configuration, but they will still need some query capability and
> quite likely the ability to update one or more Embedlet parameters.

Yup.

> I have found that the instantiation, serialization/deserialization,
> local/remote persistence and property queries/updates can all be handled
> by the same interface and a compact piece of implementation code at the
> Component/Embedlet level. Please review the Persistence package of OPC for
> details.

I will definitely take a close look at the OPC Persistence package for this.
However, I believe that we will probably need to split up some of these
functions into separate "services" to keep the implementation as modular as
possible  and reuse the max amount of code between the Static Config,
Dynamic Config and back end Build/Construction code bases.

> To respond to your suggestion that JMX and JMS be used as management and
> communication protocols: I agree completely. I would not however think
> that this would be a part of our mission statement. If we have defined a
> simple XML payload with Socket based communication, this can be easily
> packaged within a JMS, SOAP... envelope for transport to distributed
> Enterprise systems.

I think the support of JMX as the optional Management Service does need to
be part of the spec.  Primarily since this is the "standard" way that
systems are
being monitored and managed these days (and gaining ground fast).  For
ultra-constrained devices, sure, a developer would have to do a custom
solution since JMX would be just too fat. But if it fits, it's better to
stick with the
standard, since it would make Embedlet adoption much more palatable to the
corporate/enterprise guys.  I would expect that the remote management would
be exposed using a HTTP/SOAP/XML approach, with a corresponding JMX
Adapter used at the other end to support this protocol (one of the side
projects
I have been looking at is generating a Web Services interface to JMX MBeans
automagically).

JMS is another matter...since it uses proprietary transport protocols, I
have no
intention of supporting it....but the Container would be flexible enough
that
someone could write adapters for their favourite JMS implementation if they
wanted to.

> I look forward to your document release and feedback on OPC applicability.

Will get back to you on the OPC stuff as soon as I get a chance to do some
reading....likely won't get there till Wed sometime.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] Re: Embedlets-developer digest, Vol 1 #42 - 9 msgs

[Andrzej J. T. <an...@ch...>]

> My initial impressions are very favorable and the system as you have laid
> it out is very close to what I imagined it would be like.  I especially
> like the transport and protocol adapter ideas and your build process has
> nicely solved a number of problems that I was uncertain about.

Super....glad that we're thinking alike (I'm assuming that "great minds think 
alike" is operational rather than the "fools seldom differ" option <grins>)

> At this point I do not see anything obvious that would prevent the types
> of operations that I envisioned for the Wiring Tool and in fact your XML
> Embedlet configuration file seems like it would allow for much more
> detailed information to be presented to a graphic Embedlet assembler than
> what is provided by the JavaBeans Introspection mechanism.  For example,
> Introspection exposes Properties and Event Registration methods using very
> terse descriptions but the availability of an XML configuration file would
> allow quite detailed descriptions of an Embedlet's public interface that
> would be very helpful to a graphic component assembler.

Excellent....that was my thinking as well.  It also neatly avoids some tricky 
versioning (and other container related) issues that serialization of JavaBean 
objects can raise.

> It is interesting how this discussion document deals with the Embedlets
> specification and its Outpost reference implementation materials
> concurrently but I think this does help one envision how the whole system
> fits together.

I did the combined approach since a spec cannot really be fleshed out and 
functional without an understanding of what an implementation is supposed to 
look like.

> Thank you very much for putting this all together!

You're most welcome!

Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com

[Embedlets-dev] [Arch] Re: Architecture document posting problem

[Ted K. <tk...@ya...>]

I finally figured out what happened with the original post that Andrzej
submitted which contained the Architecture document.

Evidently Sourceforge has a 40K default limit on posts and since this post had
a pdf file attached to it the SourceForge site blocked it.  Another problem was
that Andrzej had copied me on the post and so I received it and just assumed
that everyone had (I did not notice that I was copied).  Finally, as the site
administrator, the Sourceforge site did notify me that there was a problem with
the post but at the time I did not understand what it was trying to tell me.

Ok, so Andrzej already worked around the problem by placing the document in the
CVS but I also took the liberty to place an additional  copy of the document on
the Embedlets website for easier downloading:

http://embedlets.sourceforge.net/devdocs/architecture/


Live and learn...


Ted

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Embedlets-dev] Re: Ant

[Andrzej J. T. <an...@ch...>]

Gregg says:

> And what build tasks are going to be so complicated?  Odd jar packaging?

There will be all sorts of code generation steps (very possibly using XSLT and 
other tools).  Ant provides you with a good tool to script all of the steps into 
one build cycle.

> Adding your own source files, you should be able to compile into a single
> directory with 'javac -d' command line(s).  You should be able to package
> this directory into a jar, and 'go'.  You should also be able to provide
> this directory in your classpath to JEMBuilder like tools and get a linked
> product.

In the spirit of Ted's "Graphic Wiring Tool", I want a single command to build 
everything, and that will take more than one compile step, transform steps, 
code generation, packaging and maybe more.  It would also include the 
platform-specific link step (eg. JEMBuilder).  Ant can do all of that.  And Ant is 
integrated with almost every major IDE out there...so that's not an issue.  I do 
all my builds with Ant from within my editor these days, and it has definitely 
simplified my life.

> It should not be necessary for developers to do any kind of manual steps
> to develop with the platform. 

No need, since Ant is integrated with most IDE's out there.  In fact, Ant is an 
automation tool for complex builds (and wiring Embedlets, JAPL drivers, 
adapters and the like into a runnable app WILL be complex).

> I am really against leaning against Ant for any configuration management
> that can also be done in the code itself where late binding can yield some
> other advantages.

Every other container-based server out there uses Ant to simplify the builds.  I 
don't think that Outpost will be any different.

Writing your own build sequencer is a bit silly, IMNSHO.  You would just end 
up developing the same functionality that Ant already has.


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com