Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] A Composable Platform Over Profiles

On Wed, May 2, 2018 at 11:39 AM, Jason Greene <jason.greene@xxxxxxxxxx> wrote:

On May 1, 2018, at 4:54 PM, Mrinal Kanti <mrinal.kanti@xxxxxxxxx> wrote:

I think the proposed strategy should work well in most simple cases that involves deploying only an app or two. I see several challenges based on different scenarios:

Multiple app deployments: A typical application server instance in any large organization deploys multiple packages in its run-time. Different packages that are developed in-house by different teams may have different development life-cycles and without any strict version control regarding usage of underlying JEE specs they would definitely end up with conflicting dependencies sooner or later. At least in case of conflicting application libraries you have the option of loading them separately in distinct classloaders.

The platform and the vendor implementation define a logically cohesive set (it’s still defined by a platform version).  If multiple teams share the same instance then they of course must agree on the definition of that instance (e.g. whether or not all of full profile or some subset). If they have different definitions then they of course need different instances. 

A major motivation of having unified deployment is server licensing cost. The last I checked there is no distinction between full-profile or any subset profile of it when it comes to pricing. Its hard to justify business value proposition from having multiple JEE runtimes based on cohesiveness alone when the same value can be demonstrated in unified deployment on a single instance.

I am only talking about stand-alone server deployments not for cloud based deployments. I have provided a more detailed explanation on this in Heiko's comments here :

Third-party closed source packages: Several third-party vendors provide closed-source products which are packaged as deployable artifacts for their customers JEE runtime. A typical example is a rules engine packaged as WAR file. These products are typically certified on specific versions of app servers. And since they are closed source products they are not required to disclose the specific JEE technologies they require for functioning. They just specify the app server version they support. It is implicit that the app server supports full profile. How would you recommend composing the JEE runtime in such scenarios when these products are deployed alongside in-house developed packages? (Deploying those packages on separate app server instances can be ruled out due to server licensing cost constraints)

Nothing today requires all EE venders to implement the full platform (they are free to provide just web). It’s standard practice to specify requirements for software like this (e.g. db version blah, OS version blah), they just need some extra info on the specs they require. If thats a problem, they could always say “full”, or ship a blackbox themselves.  

Shipping a war file is one of the simplest and cost-effective means of distribution in JEE as it leverages customer's existing app server infrastructure. Its the vendors prerogative whether they want to disclose the underlying JEE specs (and their corresponding versions) they use and this information is kind of redundant when they have already specified the exact App server vendors and their exact versions on which their product is certified. Providing that information could also imply that they are now liable to support their product on any runtime that provide those  libraries and their exact versions. This increases their accountability beyond the environments on which the product has been tested and certified. Also, that information can vary when they add additional features to their product.

Usually, blackbox is exercised as an option only when none of the runtime options the product is certified on are available at the customers infrastructure. But then that has additional overheads in terms of cost and operational complexity. So, using full profile remains as the most convenient and viable solution when dealing with third-party closed source packages.

Product support environments: For argument's sake, lets assume that I am a product vendor and at any given time my product is supported on 3 different JEE versions based on implementations provided by 3 popular app servers. So I have a total of 9 different environments (combination of app server and their versions) to certify and support my product. Also assume that my product relies on 6 different JEE specs. A similar setup in a composable JEE runtime would result in 3^6=729 possible combinations of environments. Of course, this is based on the assumption that all 6 JEE specs would have been revised in each of the 3 JEE versions. Even if we depreciate that probability, the number of possible combination of environments is really impractical to certify and support. And I have only spoken about a single version of my product so far.

If an operating system has 2216 packages that doesn’t mean you have 2^2216 environments to support. You specify the minimum required environment, and ignore the unrelated aspects.  The only thing to be concerned with are material differences. If you require 6 specs, then you only have to worry about multiple differing implementations of those 6 specs.

If you re-read my statement you shall find that I am only concerned about the 6 packages that I am using (instead of the all the packages included in JEE) and my math is based on that only.
Since the standards are backwards compatible, it's typically implementation concerns and not spec version compliance that leads to multiple implementations in the same product (e.g. a product decides to support myfaces and mojarra). 

Implementations matter here as they drag-in other third-party jars that may not always be backward compatible and can create version conflict. When you are suggesting to keep the version range open, I think it would also increase the probability of conflicts among third-party jars.


_______________________________________________ mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top