incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: J2EE user stories
Date Tue, 03 Mar 2009 16:51:20 GMT
I would see the layout being like this:

  JEE View
============
 JVM View
============
Process View

Where the higher level views can refer to elements of the view below.

IBM centric example:

Websphere Application Server (WAS)
=====================
      IBM JVM
=====================
       Linux

Where tools written ontop of "JEE" view would be able to query, say, 
stateless session bean in WAS.
But equally, the same tool should work with:

Sun GlassFish
=============
 Sun Hotspot
=============
   Solaris

The reason I suggest a stacked API is because JEE is Java, and so has 
all the same issues as Java programs. I don't see the JEE View as being 
a peer with the JVM View.

What I'd actually suggest is a little broader. JEE is just one framework 
that sits on Java. I'd envisage OSGi, Hibernate, all able to sit on top. 
In fact, if we view JEE as just an umbrella, then we might have a 
picture like:

 >-------------JEE---------------------<
+-------------------------------------+--------------+
|EJB|JTA|XMLstream|JMS|JSF|persistence|Hibernate|OSGi|
+----------------------------------------------------+
|                    JVM View                        |
+----------------------------------------------------+
|                   Process View                     |
+----------------------------------------------------+

How much the JVM View is encapsulated within JEE view would depend on 
the use cases that are generated.
Regardless of the degree of encapsulation, I'd see us accessing JEE 
container like so:

    JEERuntime jee1 = com.sun.glassfish.JEEFactory(JavaRuntime jr);
    JEERuntime jee2 = com.ibm.was.JEEFactory(JavaRuntime jr2);

Anyhow, I always viewed the JVM View as being rather basic and in need 
of interpretation.
The reason I use the term "JVM View" rather than "Java View" is to 
recognise that languages other than Java run on JVMs.

e.g.:

+------------------------------------------------------------------+
| Java View? | Scala View | Groovy View | Jython View | JRuby View |
+------------------------------------------------------------------+
|                         JVM View                                 |
+------------------------------------------------------------------+
|                         Process View                             |
+------------------------------------------------------------------+


Regards,
    Stuart


Adam Pilkington wrote:
> I was thinking about the user stories that we currently have and realise
> that we don't have anything to cover the J2EE arena. I'm not sure how much a
> typical J2EE developer actually makes use of a dump, given that they are
> running within a container there is the possibility that they just refer the
> problem to their particular vendor. However, assuming that a J2EE developer
> is going to make use of a postmortem artifact, then I'm not sure that I have
> any more new user stories than those already posted to the list, but what I
> do think is that there are some refinements to be made. Primarily the
> additional issue I see is being able to present the developer with
> information that they are interested in, rather than it being swamped by the
> much larger amount of container data. This means that I would like to add
> the following extension to the existing user stories (I'm not sure if
> extensions are even possible but I don't really want to duplicate the
> previous stores)
>
> * As a J2EE developer I only want to see my application artifacts and not
> those of the hosting container.
>
>   

Mime
View raw message