SV: [METRO] binary distribution 20051224 available
mhaavald at online.no
Thu Dec 29 08:26:22 EST 2005
I managed to read through the web yesterday and "by accident" the tutorials surfaced under /training.
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.
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".
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.
So, documentation may be more around the actual usage of metro, transit, and not on the internals.
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.
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.
I am sure this is in the training pages which I will get to.
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.
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.
<operation name="memory" method="getMemoryStats"/>
<operation name="stats" method="getStats"/>
How are thes operations called by other components or another program, e.g. hooked into the management server.
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.
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.
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...
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....
I guess what I am striving for is to separate the "dpml design internals" from the "dpml component" design guidelines *S*
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.
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.
> 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:
> Linux and Windows distributions are included.
> Cheers, Steve.
> Stephen McConnell
> mailto:mcconnell at dpml.net
> dev-dpml mailing list
> dev-dpml at lists.ibiblio.org
More information about the dev-dpml