dbt-4 (tpc-app) kit

Mark,

I'd like to help out, let me know what you need help doing.

Personally, doing this with EJB's is distasteful, but I'll help where
I can.

Dave
On 2-Sep-05, at 12:53 PM, Mark Wong wrote:

Hi Dave,

Oops, EJB's are distasteful? My experience in this area is quite
lacking. Not that I necessarily want to be 100% strict but the spec
says this needs to conform to WS-I BP 1.0 specification, which I
understand is basically using the SOAP transport? I just thought it
would be nice to have something that could be plugged into any
application server (Geronimo, JBoss, etc.) with minimal configuration
changes and that was where I started. I don't mind doing away with the
EJB altogether. What do you suggest?

To give you a little better idea of where I'm at, I have most of 7 of 9
interactions implemented, the remaining two I haven't started. The
driver needs to be expanded to simulate multiple users. I haven't
started any of the post processing or data collection scripts yet and
some of that can be used from our other kits. My Java programming style
should probably be reviewed too. ;)

Mark

On Fri, 2 Sep 2005 15:17:46 -0400
Dave Cramer <pg@fastcrypt.com> wrote:

On 2-Sep-05, at 3:38 PM, Mark Wong wrote:

Hi Dave,

Oops, EJB's are distasteful? My experience in this area is quite
lacking.

Well, I said "personally" distasteful.

Not that I necessarily want to be 100% strict but the spec
says this needs to conform to WS-I BP 1.0 specification, which I
understand is basically using the SOAP transport? I just thought it
would be nice to have something that could be plugged into any
application server (Geronimo, JBoss, etc.) with minimal configuration
changes and that was where I started. I don't mind doing away with
the
EJB altogether. What do you suggest?

I use hibernate, which would allow this to be used without an
application server.
However strictly speaking, many people are going to want to see EJB's
as this is
what the appserver types like to use.

To give you a little better idea of where I'm at, I have most of 7
of 9
interactions implemented, the remaining two I haven't started. The
driver needs to be expanded to simulate multiple users. I haven't
started any of the post processing or data collection scripts yet and
some of that can be used from our other kits. My Java programming
style
should probably be reviewed too. ;)

I had a very (very) quick look at your code, one suggestion would be
log4j, (or other configurable logging API ) for your debugging
statements.

If I have some time, I'll look at it some more, I've come to like
using the spring framework. This allows something referred to as IOC
(Inversion of Control) Basically, the problem is how to stub test
code in when we have static factory objects, the solution is to build
the application using a container which specifies the concrete
classes which are instantiated. This would in theory allow us to have
tow versions. One which uses hibernate, and the other which uses
EJB's. So one thing to think about is to code in interfaces more, and
instantiate concrete classes which implement the interface.

Dave

On Fri, 2 Sep 2005 15:50:25 -0400
Dave Cramer <pg@fastcrypt.com> wrote:

On 2-Sep-05, at 3:38 PM, Mark Wong wrote:

Hi Dave,

Oops, EJB's are distasteful? My experience in this area is quite
lacking.

Well, I said "personally" distasteful.

Not that I necessarily want to be 100% strict but the spec
says this needs to conform to WS-I BP 1.0 specification, which I
understand is basically using the SOAP transport? I just thought it
would be nice to have something that could be plugged into any
application server (Geronimo, JBoss, etc.) with minimal configuration
changes and that was where I started. I don't mind doing away with
the
EJB altogether. What do you suggest?

I use hibernate, which would allow this to be used without an
application server.
However strictly speaking, many people are going to want to see EJB's
as this is
what the appserver types like to use.

To give you a little better idea of where I'm at, I have most of 7
of 9
interactions implemented, the remaining two I haven't started. The
driver needs to be expanded to simulate multiple users. I haven't
started any of the post processing or data collection scripts yet and
some of that can be used from our other kits. My Java programming
style
should probably be reviewed too. ;)

I had a very (very) quick look at your code, one suggestion would be
log4j, (or other configurable logging API ) for your debugging
statements.

Ok, I'll have to learn how to do that. :)

If I have some time, I'll look at it some more, I've come to like
using the spring framework. This allows something referred to as IOC
(Inversion of Control) Basically, the problem is how to stub test
code in when we have static factory objects, the solution is to build
the application using a container which specifies the concrete
classes which are instantiated. This would in theory allow us to have
tow versions. One which uses hibernate, and the other which uses
EJB's. So one thing to think about is to code in interfaces more, and
instantiate concrete classes which implement the interface.

That sounds like a very good idea. I'll probably need some coaching
though...

Mark

On 6-Sep-05, at 11:37 AM, Mark Wong wrote:

On Fri, 2 Sep 2005 15:50:25 -0400
Dave Cramer <pg@fastcrypt.com> wrote:

On 2-Sep-05, at 3:38 PM, Mark Wong wrote:

Hi Dave,

Oops, EJB's are distasteful? My experience in this area is quite
lacking.

Well, I said "personally" distasteful.

Not that I necessarily want to be 100% strict but the spec
says this needs to conform to WS-I BP 1.0 specification, which I
understand is basically using the SOAP transport? I just thought it
would be nice to have something that could be plugged into any
application server (Geronimo, JBoss, etc.) with minimal
configuration
changes and that was where I started. I don't mind doing away with
the
EJB altogether. What do you suggest?

I use hibernate, which would allow this to be used without an
application server.
However strictly speaking, many people are going to want to see EJB's
as this is
what the appserver types like to use.

To give you a little better idea of where I'm at, I have most of 7
of 9
interactions implemented, the remaining two I haven't started. The
driver needs to be expanded to simulate multiple users. I haven't
started any of the post processing or data collection scripts yet
and
some of that can be used from our other kits. My Java programming
style
should probably be reviewed too. ;)

I had a very (very) quick look at your code, one suggestion would be
log4j, (or other configurable logging API ) for your debugging
statements.

Ok, I'll have to learn how to do that. :)

Ok, I'll make some changes to your code and send you a diff

If I have some time, I'll look at it some more, I've come to like
using the spring framework. This allows something referred to as IOC
(Inversion of Control) Basically, the problem is how to stub test
code in when we have static factory objects, the solution is to build
the application using a container which specifies the concrete
classes which are instantiated. This would in theory allow us to have
tow versions. One which uses hibernate, and the other which uses
EJB's. So one thing to think about is to code in interfaces more, and
instantiate concrete classes which implement the interface.

That sounds like a very good idea. I'll probably need some coaching
though...

Yeah, I'll try to find some time to do this as well. At least part of
it.I've given some thought
as to how to code this in hibernate, it shouldn't be too hard.