J2EE is our bread and butter. Its why most people initially come to JBoss.
We will continue to follow the specs religiously.
AOP + EJB:
For JB4, the average every-day J2EE developer won't notice anything. But,
implementing EJB in terms of the AOP framework will greatly enhance the
abilities of ISV's, system integrators, and third-party tool vendors to
tightly integrate with JBoss.
How?
1) The JBoss 3.x series has some limitations in regard to interceptor chains
and configuration. Sure, you can add new interceptors easily to container
configurations, but, if you want to add any time of configuration, you have
to modify JBoss code. AOP will provide a pluggable mechanism for those who
want to extend JBoss configuration. Basically, interceptors and their
configuration will be formalized into a packaged format. You'll be able to
deploy extensions to the EJB framework in much the same way you deploy a
SAR, WAR, EAR, RAR, etc....
2) The AOP framework will also give third-party integrators the ability to
actually expand the EJB API. For instance, if a distributed caching vendor
wanted to provide a Caching API to every EJB deployed they could easily do
it as a deployed package. Users will be able to use these new API's simply
by typecasting:
{
MyEJB ejb = home.create();
CacheAPI cachedObj = (CacheAPI)ejb;
cachedObj.flushCache();
}
3) In JB4, metadata/configuration will be resolved through the context of
the Invocation enabling interceptors to override existing configuration on
one side, or to provide default configuration values cross-cluster.
IMHO, these features alone will make JBoss the preferred platform for ISV
integration since they will so easily, completely, and tightly be able to
integrate their products with all aspects of JBoss.
New AOP Services: Beyond J2EE
Now for beyond J2EE, we're also doing some very cool things. IMO, Aspect
Oriented Programming is the next big wave on par of what OOP did to
functional programming. One of our main goals is to totally isolate
infrastructure from business logic by providing system-level aspects for:
security, transaction demarcation, caching, ACIDity, remoteness, clustering,
and persistence. This means you can write plain old Java classes and either
statically or dynamically apply these types of aspects making your business
logic totally INDEPENDENT of any system level API's. This is a grand
departure from following specifications like CORBA or J2EE in that these
standards create specification lock-in.
AOP gives us other advantages as well by being able to dynamically attach
behavior to any type of object at runtime. Need to dynamically monitor a
specific object for debugging purposes? Deploy and aspect at runtime. Need
to expand the scope of a system-level aspect? Write your own interceptor.
Need to apply your own system-wide proprietary API? AOP will provide you
with the hooks.
Our new AOP framework and services, also, IMHO, take you beyond J2EE where
J2EE fails or is inflexible. For instance, the J2EE specification really
has no concrete concept or definition of caching or ACIDity.
Conclusion:
We are strictly adhering to the new J2EE 1.4 and EJB 2.1 specifications.
J2EE is a fine and good specification and JBoss will remain J2EE compliant.
The new AOP framework will allow JBoss extension writers better and tighter
integration with EJB and the rest of the JBoss core. The AOP framework and
AOP services will take developers beyond J2EE to simplify application
development and provide services where J2EE leaves off. Development with
JBoss AOP finally allows business logic to be totally INDEPENDENT of
system-level infrastructure.
Regards,
XXXXXXXXXXXXXXXX
Bill Burke
Chief Architect
JBoss Group, LLC
XXXXXXXXXXXXXXXX
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom
> Elrod
> Sent: Monday, March 24, 2003 10:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Jboss/David Vs. Sun/Goliath?
>
>
> Obviously, being J2EE compliant is not my call, just expressing
> my opinion.
> Would really be nice if Marc, Bill, or Scott could chime in. You
> guys there?
> What is your plan in regards to this for JBoss 4?
>
> Dain Sundstrom wrote:
>
> > Being compliant and the AOP features are not mutually exclusive. We
> > will do both.
> >
> > To Brian Wallis, even if Jboss were to get certified, it would not make
> > your J2EE compliant applications portable. Why? There are may
> > important things considered outside the specification. For example,
> > all database mappings for CMP are outside the spec, even using a
> > database for CMP is outside the spec. Then you get into things like
> > exception recovery and tuning, and you are way outside the spec.
> > Unless you have a very simple application it will not be portable
> > without multiple configuration files and possibly a portably a
> > portability layer.
> >
> > Having the TDK would be nice to help identify new bugs, and eliminate
> > the of the minor differences between the platforms, but I doubt it will
> > seriously help you with making a cross platform application.
> >
> > -dain
> >
> > On Monday, March 24, 2003, at 07:52 AM, danch wrote:
> >
> > > I have never heard any of the main developers talk about JBoss4 _not_
> > > being J2EE compatible. It has always been my understanding that the
> > > AOP framework would form the underpinnings of JBoss4's EJB
> > > implementation and be available as a more-flexible, lighter weight API
> > > for people who aren't concerned with portability.
> > >
> > > Scott, Bill, Marc - can one of you clarify?
> > >
> > > thanks,
> > > danch
> > >
> > > Rahul Ganjoo wrote:
> > >> "but one of the goals of JBoss 4 is to make it so developers don't
> > >> have
> > >> to deal with all the J2EE APIs"
> > >> from this and the discussion in general.. Jboss4 and J2EE compliance
> > >> are
> > >> two entirely
> > >> different "roadmaps" (IMHU).. i mean its important for everyone here
> > >> to
> > >> know what direction Jboss
> > >> is going to take.. is j2EE compliance important and is Jboss
> going for
> > >> it..or
> > >> is it keeping up the Jboss4 AOP vision and hence chucking compliance?
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Jboss-development mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
