[JETSPEED 2] Service framework progress

[Sami Leino <sa...@netorek.fi>]

I was finally able to catch up with the developer list postings sent after
Nov 2003. I'm propably late with this, since the most active discussion
has already passed by. If I'm late, just discard the message and don't
bother answering.

Here are the questions I would like to ask:

1) I got the impression that you have decided to use PicoContainer as the
underlying service framework, possibly using a common services layer
and/or Jetspeed-Cornerstone to hide it's presence. Am I correct?

2) You seem to have arranged an IRC session on Feb 10 about the service
framework issues. Is there a log available anywhere on the net?

3) Did anyone construct a full comparison chart at any phase listing the
pros and cons of alternative frameworks?

4) Have you been able to set up a component acquire/release policy
already? Of course it's not an issue at all if you will only provide
singletons, but it's a major issue if your framework delivers pooled
instances as well. Have you found any frameworks containing some kind of
support for automatic releasing?

5) What kind of scheduling support there will be?

About comparing frameworks: I found this comparison about Spring and
PicoContainer on the net. I presume you all have read this before, but
here it is anyway:

  http://www.springframework.org/docs/lightweight_container.html

The chapter 6 compares Spring and PicoContainer. I presume you are aware
of PicoContainer's characteristics already, and you won't see the listed
issues as major drawbacks, like I do. But, I think one can live with them
- they just make your life a bit harder.

Spring, on the otherhand, seems to include many things that aren't needed
by most of us. I'm not sure if there is a proper separation between the
core microkernel and other features (like support for AOP, MVC,
transactions and so on) - there certainly should be. Otherwise, the
framework won't be widely adopted.

Again, I apologize for being this late.

Sami

-- 

Sami Leino
Software Developer
Netorek Oy

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Re: [JETSPEED 2] Service framework progress

[Sami Leino <sa...@netorek.fi>]

> What is your experience with Spring and how would it
> enable events + AOP around service invocation?  Why
> would you use Spring AOP?

Very little (see my previous posting). I have used my own component
framework so far, but this is the time when I need to decide if I continue
its development or adopt some other framework. Before I can make this
decision, I have to get a test-ride with the available candidates.

>> 4) Have you been able to set up a component
>> acquire/release policy already?
>>
> Not explored at this point.  Some suggestions?

Well, most of the frameworks require you to always release the obtained
component, or to never release it. Those who only support lookup
operations without release limit the framework's applicability severely.
But if the framework always requires you to release, writing client code
will become tedious because of those try {} finally {} blocks.

I have considered this issue to some extent, but I haven't yet found a
good solution. Automatic releasing is problematic because you might put
the acquired object to a long lifecycly container such as HTTP session, so
it's hard to resolve if the instance could be released or not.

The current solution I utilize is to define two alternative lookup
signatures, get(String key) and getAndHold(String key). The first one will
only allow you to obtain components that need not to be released, and the
latter one will provide you with components that should be manually
released.

I have defined two factory exception classes, FactoryException and
CheckedFactoryException. FactoryException is a subclass of
RuntimeException, so the client does not need to check it if she doesn't
want to.

In my solution, getAndHold(String key) throws a CheckedFactoryException.
This ensures that the client cannot obtain such a component without
writing the try{} finally{} block or propagating the exception further. On
the other hand, if the client tries to acquire a pooled component using
the get(String key) signature, a FactoryException will be thrown to inform
the client that the requested component is something that must be released
manually.

Since the FactoryException class extends RuntimeException, the client
doesn't need to catch it. Therefore, I can write methods like these ("Off"
stands for "Object Factory Framework"):

    public void doSomething()
    {
        SomeSingletonComponent ssc =
            (SomeSingletonComponent)Off.get("/services/ssc");
        ssc.doSomething();
    }

    public void doSomethingElse()
    {
        SomePooledComponent spc = null;

        try
        {
            spc = (SomePooledComponent)Off.getAndHold("/services/spc");
            spc.doSomething();
        }
        finally
        {
            Off.free(spc);
        }
    }

The following method, on the other hand, would result in FactoryException
to fall through to the upper layer:

    public void doSomethingIllegal()
    {
        SomePooledComponent spc =
            (SomePooledComponent)Off.get("/services/spc");
        spc.doSomething();
    }

The drawback of this solution is that in order to use the first signature
(get(String key)), the client needs to make on assumption about the
configuration. I don't like it, but I haven't yet found a better way to
deal with it.

The ideal solution would be if there was some kind of automatic releasing
of acquired objects, but I'm not sure how it could be done without AOP.

I'm very interested in hearing your ideas concerning this problem.

Sami

-- 

Sami Leino
Software Developer
Netorek Oy

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

Re: [JETSPEED 2] Service framework progress

[David Le Strat <dl...@yahoo.com>]

Sami,

Thanks for your feedback. I don't think you are too
late.  Last time I looked at Spring there was not a
clear separation of the core.  However in RC1, this
seems to have changed.  They also seem to have
separated out the context part which is interesting.

I made some comments below.

David.

--- Sami Leino <sa...@netorek.fi> wrote:
> I was finally able to catch up with the developer
> list postings sent after
> Nov 2003. I'm propably late with this, since the
> most active discussion
> has already passed by. If I'm late, just discard the
> message and don't
> bother answering.

After many debates, we are getting to the point where
we are close to getting the work started. Jun and Emad
have done a great job at creating a nice JMX module. 
Now, we need to move to the core.  Decisions are being
made now.

> 
> Here are the questions I would like to ask:
> 
> 1) I got the impression that you have decided to use
> PicoContainer as the
> underlying service framework, possibly using a
> common services layer
> and/or Jetspeed-Cornerstone to hide it's presence.
> Am I correct?

That's the direction we are moving towards. Please
find enclosed some notes summarizing (not exhaustive
though) multiple brainstorming sessions with Scott,
David, Jun and others.

The definition of service is quite broad and we are
moving towards:

1. Any number of component containers
(through pico or whatever). These are components NOT
services.  We would be possibly looking at supporting
multiple containers.  Can you do this with Spring? Can
you have multiple Spring containers running?

2. Services which fall into request in /
response out.

Conerstone for "services" makes sense where
Cornerstone provides Orchestration + JMX + web
services support for multiple transports (http, JMS,
etc.).

We would also like to add events and/or AOP "around"
service invocation (transparent to the service as part
of the component framework).

What is your experience with Spring and how would it
enable events + AOP around service invocation?  Why
would you use Spring AOP?

We need still need to formalize several thing:

- The root concept.  Instead of one application root,
support 1..n and have properties be relative to a root

- The distinction between different kinds of services:
 - formal Java services that equate to a Java class.
 - WSDL-like services, which basically define an
end-point.

Any ideas in that regard?

> 
> 2) You seem to have arranged an IRC session on Feb
> 10 about the service
> framework issues. Is there a log available anywhere
> on the net?

We probably need to formalize a proposal. I know that
David started to work on something.

> 
> 3) Did anyone construct a full comparison chart at
> any phase listing the
> pros and cons of alternative frameworks?

We have done some of that.  You can look in CVS at
/docs/J2ServiceFramework.  The landscape changes
quickly though.

> 
> 4) Have you been able to set up a component
> acquire/release policy
> already? Of course it's not an issue at all if you
> will only provide
> singletons, but it's a major issue if your framework
> delivers pooled
> instances as well. Have you found any frameworks
> containing some kind of
> support for automatic releasing?

Not explored at this point.  Some suggestions?

> 
> 5) What kind of scheduling support there will be?
> 
> About comparing frameworks: I found this comparison
> about Spring and
> PicoContainer on the net. I presume you all have
> read this before, but
> here it is anyway:
> 
>  
>
http://www.springframework.org/docs/lightweight_container.html
> 
> The chapter 6 compares Spring and PicoContainer. I
> presume you are aware
> of PicoContainer's characteristics already, and you
> won't see the listed
> issues as major drawbacks, like I do. But, I think
> one can live with them
> - they just make your life a bit harder.
> 
> Spring, on the otherhand, seems to include many
> things that aren't needed
> by most of us. I'm not sure if there is a proper
> separation between the
> core microkernel and other features (like support
> for AOP, MVC,
> transactions and so on) - there certainly should be.
> Otherwise, the
> framework won't be widely adopted.

RC1 seems to be addressing these.  We are now at a
point where we need to make a decision.  It is
actually a good time to voice your opinion.  Speaking
for myself, I am always looking forward to
constructive and well articulated feedback like yours.

I hope that helps.

Regards, 

David Le Strat.

> 
> Again, I apologize for being this late.
> 
> Sami
> 
> -- 
> 
> Sami Leino
> Software Developer
> Netorek Oy
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jetspeed-dev-help@jakarta.apache.org
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org