[METRO] binary distribution 20051224 available

Stephen McConnell mcconnell at dpml.net
Thu Dec 29 14:58:40 EST 2005


> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org 
> [mailto:dev-dpml-bounces at lists.ibiblio.org] On Behalf Of 
> Morten Haavaldsen
> Sent: Thursday, 29 December 2005 11:56 PM
> To: Stephen McConnell; 'DPML Development'; 'DPML Support'
> Subject: SV: [METRO] binary distribution 20051224 available
> Hi,
> I managed to read through the web yesterday and "by accident" 
>  the tutorials surfaced under /training.

I should mention that I have not been 'pushing' the tutorial content too
much just yet as the details concerning Transit and Depot have only just
been completed and the content concerning Metro (i.e. components) and
Station (application clusters) is only in the planning phase.

> Regardless, I read the info on metro, transit , depot. It is 
> very interesting! But, as it turns out, it may be that it is 
> an uphill battle what you try to achiece. I.e. the 
> documentation is very much "design doc". And on how the 
> internals of transit, metro etc is made.

The separation of documentation under DPML versus OSM is intentional.  The
aim is to establish the developer information about the DPML Platform under
www.dpml.net whereas the usage and best practice material is aimed at
www.osm.net.  The separation is to some extent a effort to make the
distinction between describing the mechanics of the implementation from
documentation dealing with the aims, principals, and vision (or as I like to
think of it 'the details versus the bigger picture'). 

> Documenting actual design is very hard to do in a few lines 
> on the web. Usually you need more pages to accomplish showing 
> static and dynamic views of object models.
> Hence perhaps at a later stage some doc may be refactored 
> into a "DPML developers area".

As a general indication of intent:


    - description of core products
    - formal specification of tools (e.g. transit, build, depot, 
      metro and station cli handlers)
    - formal description of sub-systems (Transit, Metro, Depot)
    - developer documentation (with a priority on being technical 
    - ultimately providing the long-term legal and organizational 


    - looking at the broader picture of:
      * the science of component-based-development
      * the application of component-based-development
    - guides to applying COP (and using the DPML SDK as an 
      example, and in doing so - critically evaluating the 
    - providing professional services backing the DPML

As to immediate content - well, there is still a lot to do and I believe
that there is a lot of room for improvement (even my mother-in-law has
complained about the complexity of some of the text on the DPML).

> What I found helpful was to read through the planet/http area.
> Especially enlightening how the Jetty is designed into metro.
> Looked at the build file and saw how types had type and 
> lastly Demo component got the defined type.
> This tells me how to do a server up of components.

I think the Jetty example is good in respect to the demonstration of
adoption of a product into a declarative component model - however - I have
a couple of reservations.  Firstly, the real meat of the HTTP package (the
planet/http/impl project) is largely oriented around the 'old-world' notion
of components - in effect 'flat-land'.  By 'flat-land' I mean that none of
the components in the impl package leverage the notion of parts. In the demo
package we see the usage of part of component as the means to construction
of a new component - however, I think that some more 'thinking' is needed
concerning part structures within the impl package.  One of the difficulties
here is dealing with the very notion of differentiating between 'service
dependencies' (declaring in a context object) and parts (declared
intrinsically within a component type).

It's a little like looking at a juggler juggling apples and recognizing that
we are dealing with (a) a person, (b) three apples, and in doing this,
recognizing that the brain, heart, liver, kidneys, and supporting systems
are a part of the juggler and not part of the picture of the juggler
juggling.  While the net.dpml.part package is doing a good job of
identifying and separating these distinctions, I think the 'concepts' are
not sufficiently clear just yet.  However, my own aim is to use the demo
package to explore this area further and hopefully tease out the final
details and establish clean conceptual separation of concerns.

> So, documentation may be more around the actual usage of 
> metro, transit, and not on the internals.

This is the aim of the OSM content (also hosted by BelioOS and Ibiblio).

> The SPI, API and IMPL  is as you say public ,protected and 
> private for a component.
> I will work through the training on the Widget example.

I've been talking to a friends about putting up a sample application dealing
with a simple but real work pond application - an application that takes
information about a garden pond (hole in the ground of a specific volume),
the global environment (sunshine, temperature, etc.), the pond environment
(fish, etc.), and from this deals with the engineering view - pumps, flows,
filtering, maps to a commercial view (product selection and pricing), ties
in suppler views (product trends, inventory, ..) - and linking all of this
into the http impl package as a dynamically deployed and remotely manageable

I figure this would be useful!

> What I am looking for now is how a component uses the a 
> service as offered by another component through the SPI. I.e. 
> how is it "wired" together.

Just a couple of comments:

  1. a component receives access to a 'service' by declaring the dependency
     within its Context definition
  2. the separation of API versus SPI (or PUBLIC versus PROTECTED) is much
     more related to the subject of a component implementation and the 
     selection of which classloader to use as a parent when creating a
     subsystem - it really does not come into play when dealing with runtime

     service access - but I know this statement is to some extent 'fuzzy' 
     so don't hesitate to post a separate message raising this subject
     using the application example in the test project as a case study)
  3. the wiring of a provider to a consumer is dealt with by the container.
     container has available information about a consumer component's 
     dependencies and a provider component capabilities (service
     The container matches providers with consumers using directives
     something like a "service:org.acme.Widget" type of statement (which
     the container to hunt for a provider of the service in the immediate or
     higher component and bind the provider to the consumer). 

> I am sure this is in the training pages which I will get to.

Not really.

The training pages on the component topic are in the pipeline - much better
to look at the testcases in the main/metro/test project (in particular take
a look at the build file and the related component implementations).  

> Looking at the http server I must say DPML is heading for 
> something which is missing for the java community and that is 
> a solid runtime framework.
> When I read through the doc I read it from a developers 
> viewpoint and I am eager to use it. An aspect is the 
> management of a solution of servers. I.a. the Station API. It 
> is perhaps possible to have servers hooked into a management solution.


The Station API is a part of a bigger picture.

In effect the Station represents a single point of management of a machine
(where machine means a physical cpu).  The Station provides support for the
management of multiple machine level processes and the intention is to
provide a framework for the exporting of the station API to an external
manager (i.e. a manager of n stations).  For example - a company managing
the deployment of 37,300 installations (remote machines), aggregating
information from all of these machines, managing these machines in whole or

> I.e. a "blue print" architecture could be a set of servers 
> constituting a solution. One of the servers is a Management 
> Server. It is interesting what the Station and the Station 
> API brings to the table ragarding monitoring, start, restart 
> etc of servers.
> The Demo has e.g. 
> <state>
>         <operation name="memory" method="getMemoryStats"/>
>         <operation name="stats" method="getStats"/> </state>
> How are thes operations called by other components or another 
> program, e.g. hooked into the management server.

After starting up the station and starting the demo application, take a look
at the control command:


> Also, the "blueprint" architecture has in my mind a "naming service".
> I.e. not the ORB NS, but an "internal" naming service.
> I.e. A component uses another service through a logical name.
> A resolver resolves the address using a naming service.
> What I have in mind is to have an dpml based server being a 
> naming server. Services register at the naming server.
> Components using the service uses the logical name and the 
> resolver resolves the actual network address.

If I understand correctly what you are describing is the distinction between
something that locates a service as opposed to something that identifies a
service.  In some respects this parallels the Transit separation of resource
identity for resource locality.  We have service locators such as
"registry:/demo/my-service" (which locates a RMI mounted remote service),
however, that's not the same as saying

While working with the OMG Naming Service (and in the context of the work of
Brokerage with the OMG's EC Task Force), I came up with some principals
concerning what could be called a distributed naming service (but more
correctly a service referral framework).  The following line includes
details about the overall model (validated in prototype form):


> This idea comes from my experience with Spring.
> In Spring you wire beans together. This is neat, BUT, is ties 
> components.
> On the drawing board based on Spring is to make an Service 
> exporter(like RMI exporter) which registeres the service in a 
> Naming Service Server.

While thinking in this area - some thing to keep in mind or be aware of:

  The registry protocol handler in Transit
  (which is basically nothing more that convenient RMI name lookup)

  And secondly (bugger - no docs available on the site).
  In effect there is a layer inside the component model that allows 
  the declaration of 'service:[interface-classname]' and this could 
  be a relevant hook into some of the things your thinking about.
  (check into the ComponentController class for more details).

  The is also the issue that we cannot presume that a component 
  implementation is remotable (but we can presume that its management
  view is).

> And also make a RMI Proxy which uses this naming service for 
> resolving the location of the service.
> Location transparency is important in distrubuted solutions.
> Having this also enables "failover", "clustering", "load 
> balancing" schemas.
> I am not sure how to accomplish all this in Metro but I know 
> it should be possible from what I have seen so far.
> Perhaps I should make for Metro as exist for Spring an 
> "exporter" and "resolver" which enables POJO's in separate 
> servers to seamlessly call eachother.
> The trend is more and more to have "non invasive" frameworks, 
> or "POJO Frameworks"....to some extent one will always "see" 
> the framework though...

I'm of the opinion that a POJO is the IT equivalent of a body without a
soul.  It's an object devoid of semantics and IMO a backlash from the strict
framework models.  The thing is that happing a soul does not necessarily
mean depending on a particular API - but this is a question of degree.  If I
write a component that leverages the Part API I'm gaining substantial value
with respect to long-term fine-grain management but I've left the agnostic
world of POJO.  In my mind there is a lot you can do with frameless
components in flatland - and flatland does not come close to addressing
multi-dimensional problems.

I.e. POJOs are like nuts and bolts - useful - but your not going to build a
city with just nuts and bolts.

> Regardless, my journey with DPML should continue now working 
> through the Widget example. 
> Also I will look into how to defined a new project using 
> module, how to set up my own local library etc...
> I, and others, should contribute to DPML with e.g. components 
> like "HTTP Service" based on e.g. apache HTTP Client. Also 
> components for publishing to JMS queues using connection 
> pooling etc...
> Perhaps also integrating ActiveMQ....
> Many possibilities....
> I guess what I am striving for is to separate the "dpml 
> design internals" from the "dpml component" design guidelines *S*

Guideline --> OSM
Internals --> DPML

> Hope to get there and to be more useful than just to "review" 
> what you are making!


> BTW, I set up a project in JBuilder and had to add a lot of 
> jars from metro. Also some "internal" jars.... Not quite 
> clear which jars I should add.

If you want to get info about the dependencies of the class you using, just
list the project in question.  For example if you want to use the part api
and your wondering what the dependencies are:

$ build -l -s dpml/metro/dpml-part-api

The above command will produce the following (-l) listing of the (-s)

  Listing project: dpml/metro/dpml-part-api


    version: SNAPSHOT
    basedir: C:\dev\dpml\main\metro\part\api
    types: (1)
    runtime providers: (2)
    test providers: (6)

You can see from the above command that the dpml-part-api project has two
runtime dependencies (dpml-state-api and dpml-transit-main).  Whenever you
list a project you will see the fully expanded dependencies implied by the

> I use the JBuilder to develop and magic/build to build it... 
> But I need "code completion" etc to be able to be productive...
> What does your development environment look like?
> What IDE do you use and which libraries do you include 
> developing components.

Your going to be very disappointed - I don't use an IDE.

My development environment consists of build.exe and Notepad2 version
However - I figure that the usual problem of setting up a project (within an
IDE) can be handled via a plugin that reads information from the common
project library.  Everything is there to fully populate a project definition
- it's no different to the way that the Depot builder is doing the setup of
a Ant project and the related context object.

Cheers Steve.

Stephen McConnell
mailto:mcconnell at dpml.net

> BR,
> /Morten
> > From: Stephen McConnell [mcconnell at dpml.net]
> > Sent: 2005-12-24 09:11:11 CET
> > To: 'DPML Development' [dev-dpml at lists.ibiblio.org], 'DPML Support' 
> > [support-dpml at lists.ibiblio.org]
> > Subject: [METRO] binary distribution 20051224 available
> > 
> > 
> > 
> > A binary distribution of Transit, Depot, and Metro has just 
> been uploaded:
> > 
> >   http://www.dpml.net/about/setup/index.html
> > 
> > Linux and Windows distributions are included.
> > 
> > Cheers, Steve.
> > 
> > --------------------------
> > Stephen McConnell
> > mailto:mcconnell at dpml.net
> > http://www.dpml.net
> > 
> > _______________________________________________
> > dev-dpml mailing list
> > dev-dpml at lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/dev-dpml
> > 

More information about the dev-dpml mailing list