Re[2]: [Myrpg-development] Non-EJB level services framework

[Alexey M. <am...@so...>]

Hi!

Friday, March 01, 2002, 12:27:09 PM, you wrote:

LL> Hi Alexey,
LL> For the work, I think we all are busy ;)

LL> To answer to your propositions

LL> The important idea here is NON-EJB =3D> we will *not* discuss of EJB =
:)

LL> (continue below...)

>> -----Message d'origine-----
>> De : myr...@li...
>> [mailto:myr...@li...]De la part de
>> Alexey Maslov
>> Envoy=E9 : vendredi 1 mars 2002 09:52
>> =C0 : MyRPG Dev Mailing List
>> Objet : [Myrpg-development] Non-EJB level services framework
>>
>>
>> Hi!
>>
>>   I think that we need framework for non-EJB level services (ID
>> generation, caching etc).

LL> I think so ;)

LL> To tell it more clearly (than my old words), ID generation will be
LL> needed to identify one object on an Atlas Server. When we create a
LL> new monster, it must be uniquely defined. In the database world, we
LL> would speak of primary key.

LL> Could you Alexey explain what you mean by caching (something related
LL> to the Application Servers or not?)

  You have to cache some data to achieve acceptable performance. Data
caching is widely used in J2EE application.

>>
>>   Main requirements for the framework:
>> - implementation of lifecycle for managed components

LL> Indeed, I think it'll be a big part to define and to implement.
LL> Do you have any experience of it?
  It's already implemented in the two frameworks mentioned below.

>> - simple to develop services

LL> Abstract class? and so on? Could you give an example?

  Just simple to develop :). Only interfaces should be visible outside
of the framework.

>> - ability to acquire the same instance for each access (kind of
>>   Singleton, probably using JNDI)

LL> example? (sorry ;) )
  Often there's a need to have only required number of
object(component) instances. Singleton pattern is usually applied in
such cases based on the static method in the class.
  This approach is practically not usable for J2EE application due to
existence of different classloaders/servers.
  That's why it's better to use some kind of centralized repository
like JNDI for instance.

>> - full support for threads

LL> Yes, it is an important point too, for the server and for the client.
LL> I think of the AI engine, the Renderer Engine...

  We're talking about server-side framework. You can easily manage
threads on the clients. But it's prohibited and practically impossible
to do it in the EJBs.

>> - support for service configuration, dynamic reconfiguration, hot
>>   deployment

LL> I think the web application can handle this.

  Web application and services framework are completely different
things. They probably should be even deployed independently.


>> - implementation of the JMX standard.

LL> Could you explain too? url... :)

  JMX is an acronym (yes, one more :)) for "Java Management
Extension".
"JavaTM Management Extensions (JMX) represent a universal, open technolog=
y for management,
ready to be deployed across all industries, wherever management is or
will be needed.".
For more see http://java.sun.com/products/JavaManagement/index.html


>>   Maybe for now the list is too comprehensive and we would have to
>> remove some requirements or change the chosen framework to implement
>> them. Time will tell.

LL> Totally agree with you, but this work has to be done :)
LL> Thanks to begin it :)

>>
>>   Now I'm evaluating two possible candidates: HP Core Services
>> Framework and Avalon (Excalibur).

LL> I'll look about the second one too. It belongs to the jakarta
LL> project :)

>>
>>   Waiting for your opinions and propositions.

LL> Waiting for your opinions and propositions too.

>>
>>
>> P.S. Sorry for my being too quiet - I've had too much work to do for t=
he
LL> last weeks :(.

LL> As many of us :(

>>
>> --
>> Best regards,
>>  Alexey Maslov               mailto:am...@so...
>>

LL> Thanks Alexey,
LL> Lo=EFc Lef=E8vre


LL> P.S. And for the Yahoo group?
Yes, please.


--=20
Best regards,
 Alexey Maslov               mailto:am...@so...