Novell has announced an expanded relationship with JBoss, with Novell contributing code and engineering resources to the development of the open source JBoss Enterprise Middleware System (JEMS) project.

The impact for JBoss is three-fold:

• Novell will contribute to JEMS development. Novell will be the first major partner to contribute to JBoss Portal by open sourcing large portions of their own portal offering, including more than 70 portlets as well as their WSRP implementation.
• Novell is intending to migrate exteNd's SOA layer and identity management suite (built on SilverStream) to JEMS, which is replacing SilverStream in Novell's exteNd stack as the application server component.
• Novell will be supporting the current JEMS stack.

This doesn't affect the project scheduling for JBoss JEMS (due in June), but greatly enhances the product offering, Bob Bickel said.

Novell's changes for the JBoss product line are expected to be released under the LGPL.

Links:

• Novell exteNd
• JBoss JEMS

a bad idea surely? shouldn't they have chosen an app server with a more commercially friendly license? then theres the issue of the complexity of the server, i've found jboss is fine where people are willing to get involved and learn about the app server, but it is the least friendly server for a corporate environment IMO.

I think this is a great move for Novell. First, they gain access to high-quality product with a decent community. They should be able to pull in some of that community to help improve some of thier code. And, they should be able to package it all in such a way that customer have no idea that they're using JBoss or any other particular product.

As far as complexity, I never really found it all that complex. The two big differences I found were features (JBoss has lots more), and configuration methodolgies (files vs web-ui). I'm also of the mind that a developer deploying on an application server should know about that server, which I thnk JBoss kinda of forces you in to. It is, afterall, probably adding a lot of code to your project, perhaps even more than you are, depending on how big the project is.

Chad: "I'm also of the mind that a developer deploying on an application server should know about that server, which I thnk JBoss kinda of forces you in to."

I have yet to see one of our customers have a developer deploy a relatively large J2EE application into a pre-production or production environment. I cannot even recall a deployment done by a developer into a test environment.

I am sure that the JBoss team are working very hard on creating better development and deployment tool support. The recents updates to WebLogic (9.0 beta) and WebShere are focused around better deployment and runtime management and monitoring tooling for architects, deployers, system administrators, and operations staff.

Regards,

William Louth
JXInsight Product Architect
JInspired

"J2EE tuning, tracing and testing with JXInsight"
http://www.jinspired.com

I have yet to see one of our customers have a developer deploy a relatively large J2EE application into a pre-production or production environment. I cannot even recall a deployment done by a developer into a test environment.

Sad, isn't it.

I have yet to see one of our customers have a developer deploy a relatively large J2EE application into a pre-production or production environment. I cannot even recall a deployment done by a developer into a test environment.

Sad, isn't it.

What's sad about it? Developers tend to not think about deployment roles and responsibilities - they're focused on development, after all.

I've been at a lot of fortune 500 companies, and I would have to agree with the original assertion: developers don't deploy, not in the larger enterprises, and they shouldn't. In fact, I'd say that they shouldn't do so - as developers - in the smaller enterprises either.

What's sad about it? Developers tend to not think about deployment roles and responsibilities - they're focused on development, after all.I've been at a lot of fortune 500 companies, and I would have to agree with the original assertion: developers don't deploy, not in the larger enterprises, and they shouldn't. In fact, I'd say that they shouldn't do so - as developers - in the smaller enterprises either.

Perhaps not, but I think this is one of the main reasons why app developers don't get why SAML,WSRP,XACML and LDAP is important. They don't generally understand the consequences of not thinking about deployment. And as long as that is the case, application integration is going to be messy.

So if developers never deploy stuff, how do you suggest that they learn about the hard reality of deployment issues that they, realtively unknowingly, cause?

Hi Rickard,

I think what is needed is accountability but probably dressed differently.

Architects and developers should be "made aware" of the problems other face when deploying their deliveries but I would hope that such awareness does not require a fulltime occupation. I do not think developers make the decision regarding the usage of mentioned technologies. This should be coming from the architect and his/her architectural product vision. Most "real" systems architects are aware of deployment issues and will try to incorporate support into the initial product/project inception. Of course some teams with a large percentage of highly skilled and experienced team members might operate differently and delegate more technology choices.

William

I do not think developers make the decision regarding the usage of mentioned technologies. This should be coming from the architect and his/her architectural product vision.

If your architect is not an active developer, well - I hope you have good luck.

Is there such a thing? An architect who does not develop? How does one earn the respect of the development team which is a key requirement in ensuring the architectural integrity of the developed solution?

William

Is there such a thing? An architect who does not develop? How does one earn the respect of the development team which is a key requirement in ensuring the architectural integrity of the developed solution?William

Glad you agree. Some don't develop but have the title. Not sure how they can architect, at least not well. The same thing goes for those who make technology decisions.

Is there such a thing? An architect who does not develop? How does one earn the respect of the development team which is a key requirement in ensuring the architectural integrity of the developed solution?William

Glad you agree. Some don't develop but have the title. Not sure how they can architect, at least not well. The same thing goes for those who make technology decisions.

Well, let's draw a line between the two concepts. As a good commanding officer should be able and ready to do anything that he commands his troops to do, including crawling in the mud, an architect should be able to develop as fast and competently as any developer in his/her team. But he should not be developing while he is acting as an architect. In my experionce, whenever a team reaches the gigantic size of four people, one of them has no time left to develop. If he tries to continue writing code by himself, he is probably not doing well what he is supposed to do, i.e. supervising the team and thinking about the overall technical solutions.
As for those who make technical decisions, well, I agree with you that they should have had at least some practical experience of what they choose for their technical teams (i.e. they should eat their own dogfood from time to time).

I've been both in the military and software dev. Not a great correlation. An architect is not a commanding officer.

It has to do with more doing than willing to do. As soon as someone stops doing, they begin to lose touch. Do they need to be doing as much? No. But it takes the combination of time (10 hours a day not 10 years), thirst, foresight (couldn't find a 'T' word), thaumaturgy and talent to be a good architect. Supervising, in a managerial capacity, the team shouldn't be his job.

I had more than 4 people under me and I was able to do it.

As for those who make technical decisions, well, I agree with you that they should have had at least some practical experience of what they choose for their technical teams (i.e. they should eat their own dogfood from time to time).

They should have more than some or they shouldn't be making the decision at all. Those actively (thinking and doing) involved know best what is best.

A Technical Architect needs to get his/hers hands dirty from time to time, if not, what they end up doing is Marketecture, block diagrams full of aged concepts sprinkled with obvious business rationale and the latest buzzwords and when that diagram (or 'architecture') gets out of the executive board it doesn't make sense at all!

Hypothetical example: imagine that the US military hire you as technical architect of their new command & control software system. How many of the estimated 50 million lines of ADA code are you going to write yourself ? Most probably none - although your experience with the realities of development will be very handy!

In small-scale projects, obviously the same person typically has to wear multiple hats during the project lifecycle: architect, lead developer, possibly build manager / integration tester / analyst / data modeler / DBA etc.

Hypothetical example: imagine that the US military hire you as technical architect of their new command & control software system. How many of the estimated 50 million lines of ADA code are you going to write yourself ? Most probably none - although your experience with the realities of development will be very handy!

How much has ADA changed in the last 10 years? 5 years? 1 year? With things like COBOL/ADA/... how much architecting is there beyond the initial design?

Well, if someday you had to be the architect for a command & control system, the fact that the target programming language is stable would make the project possible as opposed to doomed from the start. Imagine a 50 million LOC project where you'd have to switch constantly to the new new thing, between EJB 1.x, 2.x, 3.x, JDO, Spring, Hibernate etc ad infinitum :-) The project would be cancelled after 5 years and $50 million gone to waste.

Use to maintain command & control system systems in the AF (google Milstar)

BTW, I wasn't poo-pooing ADA. I almost took a job with a DOD contractor when I got out of the AF. I would have been doing ADA.

Developers almost always deploy on at least the local level - and I'd say that a lot of bad ideas have been propagated around the idea of making deployment developer-friendly instead of deployment-friendly.

So developers have the opportunity to think about deployment - they just don't, because they don't see it as part of the development process or as having an effect on their architecture.

Developers almost always deploy on at least the local level - and I'd say that a lot of bad ideas have been propagated around the idea of making deployment developer-friendly instead of deployment-friendly.

Developers need an environment to develop and test in the mimics production and they need to have full access to it. Usually they don't and the result is what you are describing.

 So developers have the opportunity to think about deployment - they just don't, because they don't see it as part of the development process or as having an effect on their architecture.

They should. So sticking deployers/operators in the middle solves the problem - but is the wrong solution. With large deployments you might/probably need deployers, but the developers shouldn't be locked out and it shouldn't be a throw it over the wall thing.

I've suggested Cameron's product to a couple of companies I contracted at but it never got anywhere because I, and the people I worked for, were not part of the deployment/app server group. They were not developers/architects and so could only do "Have problem? Call Vendor."

What's sad about it? Developers tend to not think about deployment roles and responsibilities - they're focused on development, after all.I've been at a lot of fortune 500 companies, and I would have to agree with the original assertion: developers don't deploy, not in the larger enterprises, and they shouldn't. In fact, I'd say that they shouldn't do so - as developers - in the smaller enterprises either.

Perhaps not, but I think this is one of the main reasons why app developers don't get why SAML,WSRP,XACML and LDAP is important. They don't generally understand the consequences of not thinking about deployment. And as long as that is the case, application integration is going to be messy.So if developers never deploy stuff, how do you suggest that they learn about the hard reality of deployment issues that they, realtively unknowingly, cause?

I agree. Most problems I have seen are because the developer can't (isn't allowed to) be involved with deployment and the deployers (etc) don't get the bigger picture.

I have yet to see one of our customers have a developer deploy a relatively large J2EE application into a pre-production or production environment. I cannot even recall a deployment done by a developer into a test environment.

Sad, isn't it.

no, it's not. The whole point of J2EE deployment systems is to divide the responsibilities between developers and others where developers do development and deployment is handled by sysadmins.

The whole point of J2EE deployment systems is to divide the responsibilities between developers and others

Riiight. Correct separation of responsibilities is key. Having one group do development and another group doing deployment etc. is just asking for problems - and I have only seen it go badly.

I used to work for a hosting company that hosted about 600 J2EE servers for General Electric. I used to work with there staff doing deployments on about 40 of those servers. In ever case it was never a developer that I was working with for application deployment. They had specific people assigned to deployment, roles, permissions, etc... If a deployment failed it was rolled back, and sent back to the developers. Usually didn't happen thought because they were very careful about their testing.

I used to work for a hosting company that hosted about 600 J2EE servers for General Electric.

Yes, GE is an interesting company...

I used to work with there staff doing deployments on about 40 of those servers. In ever case it was never a developer that I was working with for application deployment. They had specific people assigned to deployment, roles, permissions, etc... If a deployment failed it was rolled back, and sent back to the developers. Usually didn't happen thought because they were very careful about their testing.

Yes, my experience with companies like GE are there is either a developer or consultant involved that helps set up these processes with an Operations guy. When a consultant is involved they usually set up the deployment process for JBoss and the organization deploys in a cookie-cutter fashion.

For deployment, JBoss is quite flexible and easily scripted because all configuration is file-based. Installation can be as easy as gunzip, untar. There's also a bunch of ways to override configurations: System properties, command-line specified bind-address, central config files. In a cluster, you can manage deployments centrally on any HTTPD server and have JBoss boot up from a URL. Or, you can use our Cluster Farm service for decentralized deployments. This basically defines a directory of deployments that our clustering layer synchronizes via JGroups.

Bill

We use JBoss and it has never been an obstacle to our success. Obviously Novell felt they could make money with JBoss, which sounds commercially friendly to me.

Steve

After Novell bought Suse and Ximian they sort of have become a Linux company more than anything else - at least for me. When they bought Ximian they also got many of the central Mono people.

Is this a move towards dropping the J2EE products and focusing more on Mono/.Net? So instead of just killing the legacy from Silverstream they are dumping it on JBoss and asking the customer to go the JBoss way?

If you look at

http://forge.novell.com

Mono projects are the most active. Some which seems pretty cool:

http://www.ifolder.com

What do you think? Where are Novell headed?

Is this a move towards dropping the J2EE products and focusing more on Mono/.Net? So instead of just killing the legacy from Silverstream they are dumping it on JBoss and asking the customer to go the JBoss way?

I'll hazard a guess that since Mono currently has a such a small footprint (if any) in enterprise level development and deployment when compared to J2EE that it is simply a smart marketing move for Novell to align themselves with Java/J2EE as well.

If Mono were to reach critical mass, then they would also have the ability to provide their customers with migration paths away from Java/J2EE to Mono or even hybrid solutions.

Robert Love (the Kernel guy in the GNOME/Freedesktop community) have written a blog entry stating news about Suse 9.3:

<quote>
We are shipping SUSE 9.3 soon and I am pretty pleased. Aside from the latest goodies--gcc 3.3.5, glibc 2.3.4, kernel 2.6.11.4--the new SUSE boasts a polished GNOME 2.10, Mono 1.1.4, rcd and rug, Xen, and a sweet collection of in-house-developed applications, including Beagle, F-Spot, and netapplet.

But the real gem is the Project Utopia stack: We have udev, D-BUS, and HAL all kicking ass, right out of the box.
</quote>

Two interesting things. 9.3 gets real GNOME support and a lot of the Mono based software is added - some of them which I thought were extremely bleeding edge stuff.

So I really think Novell is serious about this Mono stuff and I don't think Java is one of Novell's strategic platforms for the future.

Robert Love (the Kernel guy in the GNOME/Freedesktop community) have written a blog entry stating news about Suse 9.3:<quote>We are shipping SUSE 9.3 soon and I am pretty pleased. Aside from the latest goodies--gcc 3.3.5, glibc 2.3.4, kernel 2.6.11.4--the new SUSE boasts a polished GNOME 2.10, Mono 1.1.4, rcd and rug, Xen, and a sweet collection of in-house-developed applications, including Beagle, F-Spot, and netapplet.But the real gem is the Project Utopia stack: We have udev, D-BUS, and HAL all kicking ass, right out of the box.</quote>Two interesting things. 9.3 gets real GNOME support and a lot of the Mono based software is added - some of them which I thought were extremely bleeding edge stuff.So I really think Novell is serious about this Mono stuff and I don't think Java is one of Novell's strategic platforms for the future.

Well it's hardly as though Sun have encourage linux
adoption of java. For an env to be shipped with a distro
it should be open source . java isn't so java looses out.
incidentally i've been checking out the mono project and
i'm going to certainly be keeping one eye on it in the future.

--b

Well it's hardly as though Sun have encourage linux adoption of java. For an env to be shipped with a distroit should be open source . java isn't so java looses out.incidentally i've been checking out the mono project andi'm going to certainly be keeping one eye on it in the future.--b

Sun hasn't discouraged it, either. Note that a Linux JVM is one of their primary offerings: that's not a lack of support for Linux.

What exactly in the JVM license prevents it from being distributed as part of linux? Or is this simply hardheadedness on the part of Linux distributions?

What exactly in the JVM license prevents it from being distributed as part of linux? Or is this simply hardheadedness on the part of Linux distributions?

Basically, the only problem with including the JRE in a Linux distro is that it will upset the FOSS advocates.

Several Linux distros do include the JRE without any problem.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

the JRE?

It is the SDK that is important and it is not distributed because you need permission (signed agreement) from Sun, you need to pay. Remember that Linux is the cause to that Sun soon is out of business. Also the Linux Java version is not made by Sun.

Regards
Rolf Tollerud

the JRE?It is the SDK that is important and it is not distributed because you need permission (signed agreement) from Sun, you need to pay. Remember that Linux is the cause to that Sun soon is out of business. Also the Linux Java version is not made by Sun.

I don't mean to be picky, but since you are partially correct, I guess I should point out which parts are correct and which are not.

the JRE?It is the SDK that is important

Yes, to developers it is the SDK that is important.

However, to Joe User, the JRE is the JVM that Joe was asking about.

it is not distributed because you need permission (signed agreement) from Sun

I checked the Java SDK license agreement, and it would not allow a distro to include the Java SDK.

Any developer, on the other hand, that develops a Java application can ship the Java SDK with that Java application (for free) for the purpose of running said application.

you need permission (signed agreement) from Sun, you need to pay

I do not know if you need to pay or not. You'd have to ask Sun. The Java SDKs are free to download; I highly doubt that Sun charges for them to be included in distros, but obviously I could be wrong.

Remember that Linux is the cause to that Sun soon is out of business.

Sun is doing fine for a server hardware vendor. Their main problem is that IBM has been spanking them pretty severely on the high end and Dell has been spanking them pretty severely on the low end.

On the other hand, Sun is doing much better now on the low end, due to AMD Opteron-based servers (Sun sells more Opterons than any other company) and a combination of Solaris for x86 and Linux.

On the high end, I doubt that Sun will ever be a performance leader, although they've always done OK when it comes to price/performance (only because IBM is ridiculously expensive on the high end).

Also the Linux Java version is not made by Sun.

That's new news to me. For years, the Java SDK for Linux has been made by Sun.

FWIW - My guess is that you are referring to Blackdown, which is now based on Sun's Java SDK and not vice versa.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

But portions of the SDK actually get used at runtime. Case in point, JSPs. If you don't precompile your JSPs, you land up needing the compiler which is not part of the JRE. So sometimes the seperation between SDK and JRE becomes blurred. In these cases atleast, Sun should probably include the component as part of the JRE IMHO.

I checked the Java SDK license agreement, and it would not allow a distro to include the Java SDK.

The SuSE Linux distribution comes with the Java SDK and has for a while now.

The SuSE Linux distribution comes with the Java SDK and has for a while now.

Does anyone know if SuSE had to pay Sun? Or sign some sort of license agreement?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

Also the Linux Java version is not made by Sun.

That's new news to me. For years, the Java SDK for Linux has been made by Sun.FWIW - My guess is that you are referring to Blackdown, which is now based on Sun's Java SDK and not vice versa.Peace,Cameron PurdyTangosol, Inc.Coherence: Cluster your POJOs!

Sun's Linux JDK is (or was at least) created by Borland. I don't know who currently maintains it, possibly Sun.
Blackdown was never the basis for the Sun product, it's a separate project with (maybe) some Sun sponsorship.

Sun's Linux JDK is (or was at least) created by Borland.

What do you mean when you say "created by Borland"? I'm curious, as my understanding was that 99% of the code (even Hotspot) was shared between Windows, Solaris and Linux.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

What exactly in the JVM license prevents it from being distributed as part of linux? Or is this simply hardheadedness on the part of Linux distributions?

Basically, the only problem with including the JRE in a Linux distro is that it will upset the FOSS advocates.Several Linux distros do include the JRE without any problem.Peace,Cameron PurdyTangosol, Inc.Coherence: Cluster your POJOs!

<troll
>
yeah, well when sun goes bust/gets bought by IBM I'm going to port to mono/ikvm rather than pay a couple hundred dollars a JRE for each of my servers.

--b
</troll>

Bryan,

<troll>"yeah, well when sun goes bust/gets bought by IBM I'm going to port to mono/ikvm rather than pay a couple hundred dollars a JRE for each of my servers."</troll>

Well you may laugh but the Open SOurce people are not to be played with! They rather rewrite a whole OS then change a comma in the license (Hurd). Also they are petty prickly and have a loong memory. Why don't you ask the BSD people what they think about Sun? ;)

Regards
Rolf Tollerud
(been socializing a lot with BSD people lately)

What exactly in the JVM license prevents it from being distributed as part of linux? Or is this simply hardheadedness on the part of Linux distributions?

Basically, the only problem with including the JRE in a Linux distro is that it will upset the FOSS advocates.Several Linux distros do include the JRE without any problem.Peace,Cameron PurdyTangosol, Inc.Coherence: Cluster your POJOs!

replace "advocates" with "zealots" and you're right on the mark.

There's every option to create an open source JVM, and there is at least one out there.
What the zealots object to is not having control over the language specification and not being able to call it Java unless it passes the certification process which they don't control.
It's politics, not realism.

Well it's hardly as though Sun have encourage linux adoption of java. For an env to be shipped with a distroit should be open source . java isn't so java looses out.incidentally i've been checking out the mono project andi'm going to certainly be keeping one eye on it in the future.--b

Sun hasn't discouraged it, either. Note that a Linux JVM is one of their primary offerings: that's not a lack of support for Linux.

Also, if you run a Swing based application on Linux, versus an SWT based one (e.g. Eclipse), it is easy to see that Sun is serious about supporting Linux.

I address in my blog how the Novell team is helping in Portal dev and what they're specifically bringing to the table.

http://jboss.org/jbossBlog/blog/rrusso/

I worked with SilverStream before and after Novell bought them and I never could figure out why Novell wanted it.

It was always a terrible peice of junk. I doesn't suprise me that they have dumped it.

I worked with James Watson before and after Novell bought SilverStream, and I could never figure out why anyone would want to work with such a slack, and hack developer.

He was always a terrible pieve of junk. It doesn't surprise me that he spends his days posting forums.