Hi Richard: Late night thoughts in-line ...
Richard Wallace wrote:
On Tue, 2003-01-21 at 12:28, Stephen McConnell wrote:Basically the Tomcat embedded is packaged as a component that provides a web application publication facility. Other components can declare their dependency on the web gateway and use the service provided to publish into the service a web application. Typically the publishing component provides a reference to itself as part of the publication criteria and the established web application interacts with the publishing component and any component it establishes.
Cool, I was going to ask how you are embedding Tomcat.Any sample code for running Merlin in Tomcat?Give me a couple of weeks - and yes. There is some refactoring I need to take care of after which I will be able to provide some running demonstrations. In the meantime you may want to take a look though the following:
http://www.osm.net/doc/gateway/
The osm.net content is available to sponsors under an open source license (basically the process at osm.net is something equivalent to a managed open source environment - where managed refers to a process of a lot more top level design and some specific objectives concerning deliverables).I'll look it over. Is the source code available?
Anyway, once the package is updated to Merlin 2.1, I'll send you a copy of something off-line to help you get going.
There are several scenarios I've been dealing with:
1. componet has a depedency on a web-server - wants to register a presentation app
2. web application needs merlin to get component services to do its stuff
The two are very differnet - in the first case I've been playing around with meta attributes that describe presention policy but with mixed success. In the second case - no problem.
The second is the one that I am looking at right now. The basic layout of what I'm looking at is to have the servlet create the container. The container will create a ServiceSelector which will contain what I'm calling RequestHandlers. These are dependent on other services (for instance, a Authenticator and Authorizor, some kind of DAO(s), an order processor, etc). The servlet itself only needs access to the ServiceSelector for RequestHandlers, everything else is used by those handlers. That's one reason it would be nice to use the full blown Merlin is because there could be any number of handlers. So, the automagic abilities of Merlin could come in handy.
Sounds to me like you should be creating a Block instead of stuffing around with bootstrapping. 1. create an EngineClassLoader * this means referencing externally located jar files containing the components you want to use * if the web app is not running as a component within Merlin then you will need to create the logging system (see the engine test case in the assembly package for an example) 2. create a block * create a appliance context and populate it with everything it needs * use the engine to create the block using the appliance context as an argument see DefaultBlockLoader.createBlock( ...) for an example 3. start the block
Initially, the servlet and the services will all be on the same
machine. If the load gets to high on that box, though all we do is
replace the service implementations in the Merlin block configuration
file with proxy implementations that communicate with the actual work
components on another box (or a collection of boxes). I think embedding
Merlin would make this change over extremely simple because other than
creating the proxies and changing the Merlin block configuration no
other code needs to be changed.
That's the objective. This is working in the osm.net apps using IIOP as the inter-service communications mechanisms, but there is more work needed on synchronization of component availability, suspension, resumption and shutdown notification between containers. The principal is that your component will not need to know where a provider component is - could be local, could be remote.
Now comes the twist. The other part of the app is a SOAP interface. I'll be using the Axis servlet for that. Right now I'm not sure of howInitial hunch is that you want to drive the SOAP behavior from meta data. I.e. here is component type that handles SAOP messages - look at the type and figure out the message structures based on the type meta attributes (or something or other along those lines).
I'm going to integrate things together.
I was thinking that since tomcat can run in merlin I could do that and
have a Deployer service that would deploy the servlet and the web
service at startup.
Yep.
The only question then is whether to have theGenerally speaking - if a component needs something - then create it outside of the component and supply it to the component. At the end of the day it's less trouble.
Merlin embedded in the servlet create the actual work components and
then web service use proxies to access them or if the top level Merlin
container should create them. Then the servlet and soap service would
have proxies that connect to the local instances.
That way they are all still running in the same runtime so even havingKeep in mind that in a distributed Merlin environment your component will NEVER "do remote" - it will just "do" and the remoteness is something completely hidden.
to do "remote" connections shouldn't be to much overhead.
I guess it
depends on the state of local optimizations with AltRMI. Something I
have to ask Paul about. If it's not too much overhead I would rather
the latter case. Then the web service would have an embedded merlin to
automagically create the proxies for the services it needs and the
servlet would do the same and neither would have to worry about the
actual work components.
Anyways, that's my complete scenario. In the end I could wind up using
a mix of both of your scenarios above.
That's my impresion as well.
That was where I fist looked - but this is actually being handled by the DefaultBlockLoader before a block even gets instantiated. Basically the block loader goes through the process of building the entire containment scenario (classloaders, blocks, sub-blocks, etc.) and publishes information back into the kernel using urls. The url creation is where you hitting a problem because the URL in question is simply a URL to a local instance but the handler has not been registered. There are several ways of registering URL handlers and the current approach is not 100% satisfactory - in fact I've looking over code in the source resolver package in Excalibur as a possible alternative approach that would be more consistent with the Cocoon project.
Ok - you not registering the protocol handler.
Any ideas what's causing this?The DefaultRegistry constructor handles the establishment of the protocol handler. Seems to me like you not supply a registry which is used when aggregating services available in a block. Anyway - you will find the code for handler registration in the DefaultRegistry constructor - in the meantime - a confession - theis are of bootstrapping is probably the worst documented. Also I want to get in test cases for embeeded loading - ... zutt - so much to do - so little time!
:-)
Hmm... I thought the bootstrap code would take care of that stuff. I'll try and take a bit deeper of a look myself.
Give me a couple of weeks and I'll have a working demo in place.Looking forward to it. =)
Not sure where I'll put it - but I'll make sure something is available either here at Avalon or over on osm.net.
Me too! Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
