Hello Craig,
Tuesday, January 22, 2002, 3:39:38 AM, you wrote:
Comments below...
CRM> On Mon, 21 Jan 2002, Oleg V Alexeev wrote:
>> Hello David,
>>
>> Can you help me with services? A time ago I start services subproject
>> in commons-sandbox - it will be core lib to build service-oriented
>> struts architecture. Now we start new project and I have not time
>> enough to prepare it to the work with struts.
>> Is it interesting for you?
>>
CRM> It (integrating services) is finally getting to the top of my TODO list.
CRM> I presume we should really be doing this based on the version in
CRM> commons-sandbox, right?
Yes.
CRM> One thing I can't seem to find is the old mail
CRM> threads describing the roles of the various components -- Oleg, could you
CRM> please refresh my memory with a short description of the roles of all the
CRM> core components (Event, Module, Queue, Service, ServiceManager, and so
CRM> on)? (This stuff should really be added into the Javadoc comments also.)
There aren't any old mail with info about this classes... 8)
I develop it and put to the commons-sandbox without any proposal in
struts-dev or commons-dev.
Now I try to explane API of services -
ServiceManager - central class in lib. It loads all other components
and modules and dispatch calls to the appropriate service.
ServiceModule - module to hold and manage all Service-classes,
registered in system.
QueueModule - module to hold and manage all Queue-classes, registered
in system.
EventModule - module to manage Event-class instances. It uses
KeyedObjectPool as tool to manage Events.
Service - base class to extend and write custom modules to work under
control of ServiceManager. This class can rewrite initDigester()
method and register its own Rules to parse config.
Queue - instances of Queue-classes implements logic of calls to the
Services. For example - SequenceQueue holds a string with names of
services and process calls to the Service.execute() methods by the
order of service names from this string.
Event - instances of this class holds all information from custom
application that must be passed to the services with the
Servie.execute(Event) calls.
Now I try to explane logic of this classes interaction.
-------------------
Config and Init.
ServiceManager is independent built-in module to support mechanism of
servies - independent modules with simple API, which must implement
only one method - execute(Event). ServiceManager can read its own
config and can use Digester of parent application to load its config
(all config stuff is not ready now - may be it is for the better...).
ServiceModule contains tags with Services registrations.
ServiceManager register special rules to read Services regostrations,
which takes Service class name, creates it and call
Service.initDigester() to register service-config parse rules. So
every Service can register its own config inside of whole apllication
config.
EventModule section contains event-classes descriptions. Every
description is a tag with name of the class, name of the event. Any
additional properties for Events extended from base class can be
specified with set-property tags.
QueueModule section contains tags with registrations of Queues - every
Queue must implement execute(Event) method wich takes appropriate
Services and calls execute(Event) for it. Every Queue free to
implement logic of traversing via Services list. For example,
SequenceQueue takes comma-delimited list of service names and calls
every Service.execute() method.
---------------------
Work phase.
Parent application can call methods -
ServiceManager.execute() - to pass default Event via default Queue of
the Services.
ServiceManager.execute(Event evt) - to pass evt Event via default
Queue of the Services.
ServiceManager.execute(String queueName) - to pass default Event via
Queue with name queueName.
ServiceManager.execute(String queueName, Event evt) - to pass evt
Event via Queue, name as queueName.
To pass Event instance via any Queue parent application must take it
from events pool by the EventModule.getEvent(String queueName) method
call (ServiceManager itself returns object to the pool after execution).
ServiceManager.execute() method takes appropriate Queue by the name,
and call Queue.execute(Event) method with Event instance from parent
application or with instance of default Event type, registered in
ServiceManager.
Queue class takes Event instance and traverse via list of Services.
Queue class can be extended and implement any another logic in execute
method - for example call services in different threads or call it by
the some condition.
Every Servic.execute() method takes Event instance and "make
anything"... 8)
CRM> I note that Oleg proposes that a Service have an initDigester() method so
CRM> that it can add custom processing rules to the Digester that will be used
CRM> to process the struts-config.xml file. One implication of taking
CRM> advantage of this facility is that you won't be able to use a validating
CRM> XML parse of this file, because the custom elements for each service won't
CRM> be defined in the DTD.
Yes... But one question. Can we register a set of rules and set any
additional namespace for it? Now I walk throw Digester docs and find
xxxNamespaceURI() methods in some interfaces - can it be solution for
dynamically registered rules?
CRM> As an alternative, how about the idea that each Service implementation
CRM> class must be configured based on JavaBeans properties, so that we can use
CRM> nested <set-property> elements like we do with data sources to configure
CRM> each service?
No problem. I think that any config can be defined as set-property
tags. But there is one but great contra for such solution. For my
mind, set-property tags has very little level of clearness inside of
config file. Only aspiration to make it useful tend me to do so.
CRM> Craig
--
Best regards,
Oleg mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
