Hogy a múlt héten már írtam, a a Jigsaw átcsúszott a Java9 kiadásba, ennek örömére
- a java.net indított egy szavazást: http://www.java.net/poll/whats-your-view-proposed-removal-project-jigsaw-java-8
- illetve ezen szavazás örömére a DevZone is indított egy szavazást: http://java.dzone.com/polls/poll-no-jigsaw-java-8-0
Ha úgy érzitek, hogy szavaznotok kell, tegyétek azt... 
Az elmúlt másfél év során sok információ került ki a Project Jigsaw kapcsán, mint a Java7, majd a Java8 egyik nagy erőssége, s a jelen állás szerint csak a Java9 nagy dobása lesz, mivel a Mark Reinhold úgy ítélte a projekt állását, hogy az elkövetkező bő egy évben (a Java8 majd csak 2013 őszén fog kiadódni) nem lehet tisztességesen befejezni, legalábbis ez olvasható a blogbejegyzésében. , így továbbra se lesz semmi a JSR 337 kódnéven emlegetett modularitási és profilozási lehetőségekből a következő nagyobb Java kiadásban. Mark megemlítette a főbb dilemmáját is: fejezzék be a modularitást és adják ki később a Java8-at vagy adják ki időben, és a következő kiadásba kerüljön bele egy letisztult és korszerű modularitást támogató megoldás.
A bejelentés viszonylag nagyobb port vert fel a Java közeli blogokon és portálokon, s a vélemények között akad mindkét opcióhoz támogató, a dzone.com oldalon idéztek kettő ilyen véleményt:
We didn't go too far with modularity in Groovy 2... because we didn't want to duplicate what was supposed to be coming in Java 8.
But now, it means it won't be in the hands of developers before 2 years, and in production before 3 years :-(
It means that Jigsaw, if it ever ships, will have been 5+ years in the making. That sounds a lot, even for such a big feature and task.Guillaume Laforge (major Groovy contributor)
Illetve:
DON'T HOLD THE TRAIN. The five years from Java 6 (which itself was disappointing) to Java 7 nearly killed the language.
Johannes Brodwall
A nagy kérdés az, hogy a platform kibír-e még 2-3 évet, amíg a Java9 megjelenik, és nem jelenik-e meg a jelenlegi JCP támogatással bíró de jure szabvány Jigsaw helyett egy alternatív megoldás, amely de facto szabvány lesz. Sokan az OSGi-t emlegetik, illetve a Maven mintáját gondolják átvehetőnek...
Saját vélemény
A Jigsaw – mint modularizációs ötlet – alapvetően a JavaFX miatt született 2009-2010 környékén, mivel a kliens oldalon (asztali, hordozható vagy hordható eszközökön) futó beépülő programok csak akkor képesek hatékonyan futni, ha nem kell maguk alá telepíteni egy 50-150MBájt méretű futtató környezetet, hanem csak a futásukhoz szükséges modulokat töltik le és indítják el. Ezen modularizáció nélkül a JavaFX programocskák indulása akár másodpercekig is eltarthat, ha a felhasználó sikeresen feltelepítette a JRE-t, amelyhez rendszergazdai jog kell... nyilvánvaló, hogy ezen okból fel kell darabolni a Java platformot jelentő API-t.
Azonban az elmúlt két-három évben a JavaFX egy fikarcnyit se mozdult el a nullával jellemezhető piaci részesedéséről, az elterjedőben lévő platformok közül az iOS biztos nem fogja támogatni se a Java, se a JavaFX környezetet; az Android esetén kevéssé számít az, hogy modulárisan induljon el a VM, mert alapjaiban más megoldást alkalmaz erre a problémára; s végül a Windows Phone se fog Java/JavaFX programokat futtatni. A meglévő platformok közül az asztali és laptop/notebook vonal nem igényli a modularitást, a szerver oldali Java esetén pedig ott van az OSGi a futás idejű modularitásra (Eclipse, Glassfish és még néhány szerver oldali megoldás használja az OSGi-t), a fordítás idejű modularitásra pedig ott a Maven és a többi függőséget jól kezelő rendszer.
Felmerül a kérdés, hogy kell-e a JDK modularizációja, vagy már elhaladt felette a kor?
A Fortress programozás platformot is elérte a végzet: az Oracle megszüntette, pedig közel tíz éven át gondozták ezt a programozási nyelvet, amely JVM alapokon lehetővé tette a matematikai számolások hatékony leprogramozását, olvasható a Project Fortress blog friss bejegyzésében. Az Oracle döntése mögött valószínűleg a rövid és középtávú bevételi lehetőségek kaptak nagyobb súlyt, mint a tudományos jelentőség, mivel a továbbiakban is meg lehet keresni a hosszú nevű Oracle Labs Programming Language Research Group részleget a Fortress hibáival és támogatást is lehető tőlük kérni – de új fejlesztések már nem kerülnek bele a nyílt forrású platformba, és a platform problémáival kapcsolatos K+F is befejeződik.
Az Oracle kiszállása után a nyílt forrás okán ugyan folytatódhat a projekt, de kérdéses, hogy van-e akkora aktív felhasználói bázisa a matematikusok és fizikusok között, akik tovább tudják fejleszteni a platformot az igényeiknek megfelelően, mivel a projekt eléggé proof-of-concept állapotban van, és ezt a Guy Steele is elismeri, amikor nosztalgiával emlegeti a problémáikat a JVM és a Fortress különbözőségeit taglalva, majd a köszönetnyilvánítás után röviden összefoglalja az elért eredményeket.
Bár van esély a feltámadásra, de egyelőre: R.I.P. Fortress.
Megjelent a NetBeans IDE második ráncfelvarrása, amely ugyan nem tartalmaz nagy változásokat, ám annál több kisebb javítás és fejlesztés láthatunk az újdonságok listáján, erről fogunk csemegézni.
Refactoring
Az szerkesztő felület és a fa struktúrát érintő módosításokat átpörgetve egy lényeges blokk kerül a szemünk elé: a kód újrastrukturálása (vagyis a refactoring):
- A módosítások visszavonhatóak a normál Undo menüpontban
- A konstruktor kicserélhető egy factory vagy builder metódussal
- Egy boolean típusú metódus invertálható (például isCorrect -> isWrong)
- Mezők osztályok közötti mozgatása (amountFor(rental) -> rental.amountFor())
- A használati helyek háttérben kereshetőek
- A kijelölt kód körüli kódrész eltávolítható egy lépésben
- Forráskód elemek blokkban mozgatása fel-le
- Statikus kódelemzés során kibukó problémák javítása fejlődött
- Fejlődött a kódgenerálás, illetve a kódformázás
JavaEE fejlesztések
- JPA kódkiegészítés és pontosabb hibajelzés
- CDI figyelmeztetések
- Amazon integráció
- Javított EJB és Spring támogatás
Projekt kezelés
- Megszűnt a Main project beállítási lehetőség, jobban mondva a megszokott helyéről átkerült a Run menübe
- Lehetőség van a projektetzip fájlba exportálni, illetve onnan importálni
Build eszközök
- Maven projekt esetén is lehetőség van a Compile to save bekapcsolására
- Repository browsera Maven projektek egyszerűbb függőségkezelésére
- Függőségi grafikon
- Archetype varázsló
- Hudson/Jenkins integráció
Verziókezelés
- Újraírt verziótörténet
- A beépített VCS kliensek frissültek
Debug és profiler
- Kódkiegészítés a debug ablakok beviteli mezőiben
- Teljesítmény és deadlock javítások
- GUI módosítások: heap dump gomb, szűrések
Egyéb érdekességek
- Újratervezett beállítási lehetősége
- TestNG integráció
- Javított JavaFX, C++, Groovy és PHP támogatás
A JavaForum2.0 portál egyik nagy hiányossága a privát üzenetek kezelése terén jelentkezett: nem volt lehetőség arra, hogy egy felhasználó üzenni tudjon egy másik felhasználónak. A Confluence – mint wiki rendszer – szintén rendelkezik ezzel a hiátussal, bár a belépett felhasználók láthatják egymás email címét, így annyira nem égető ezen tulajdonság hiánya... mivel egyszerű feladatról van szó, körülnéztem a Confluence háza táján, hogy ezt az igényt miképp lehetne legegyszerűbben kielégíteni, így írtam egy plugin-t, amely a Private Messaging for Confluence nevet kapta.
Lehet próbálgatni (esetleg forráskódot nézni)... ha nem találtok szarvashibát, akkor feltolom a marketplace portálra is.
Idén október 20-án már hatodik alkalommal új helyszínen az Óbudai Egyetemen (1034 Budapest, Bécsi út 96/B.) ismételten megrendezésre kerül a hazai webes közösség legnagyobb szakmai eseménye a Magyarországi Web Konferencia.
A rendezők az új helyszínen kívül más érdekességekkel is készülnek az idei konferenciára, melyekről folyamatosan tájékozódhatsz.
A konferencia célja, hogy kezdőknek és profiknak egyaránt útmutatást nyújtson a legújabb webes trendek és technológiák útvesztőjében, legyenek bár fejlesztők, grafikusok vagy azok, akik kettejüket összehozzák.
Jelenleg a rendezvény szakmai programjának összeállítása zajlik, ha van olyan téma amiről úgy gondolod másoknak is hasznos lehet és szeretnél előadni a konferencián, vagy nagyon érdekel és egy szakmailag kompetens előadótól szeretnél a témában egy előadást hallani, akkor vedd fel a kapcsolatot a szervezőkkel.
Úgy tűnik, hogy a Red Hat elérkezettnek látja az időt, hogy pénzt kérjen az eddig ingyenes OpenShift szolgáltatásáért (egy gyors bemutató), mivel a jelenlegi szolgáltatás mellé behozott két új nevet:
- FreeShift
- MegaShift
Ahogy a másfél hete megírt blogbejegyzés táblázatában is olvashatjuk, a két szolgáltatási csomag közül az első ingyenes lesz, a második viszont fizetős (bár a havonta elkért 42 dollár nem mondhatni olyan sok költségnek):
A fórumok tanúsága szerint a felhasználókat kicsit összezavarta az, hogy az OpenShift a brand neve lesz, és az eddigi szolgáltatás korlátot kap és FreeShift néven fut tovább, amelyről tovább lehet lépni a MegaShift felé, amellyel a Red Hat célja egyértelműen az Amazon AWS piacára való betörés:
Now let's configure a hypothetical IaaS: We'll use Amazon Web Services EC2 since it's a popular IaaS. We can use small EC2 instances for the databases and web frameworks, Elastic Load Balancer (ELB) for load balancing, and Relational Database Service (RDS) small instance for MySQL. In that configuration, we need 3 small instances, one RDS small instance, and ELB. At $.08/hour for small EC2 instances ($57/mo), $.10/hour for small RDS running MySQL ($72/mo), and $.025 for the load balancer ($18/mo), that comes out to $261/mo. (Pricing from here, here and here - For this example I used On-Demand instances from the US East Virginia region which was the least expensive region at the time of writing.)
Nos, az egészséges verseny mindig jól jön, talán egymás árait is sikerül letörni.
Egy ideje elérhető az OpenShift PaaS lehetőség a RedHat oldalain, amelyet ingyen ki lehet próbálni: https://openshift.redhat.com
A regisztráció után egy pár lépésből álló varázslóval ki tudjuk választani a nekünk szükséges szolgáltatásokat:
Hozzuk létre a szolgáltatásunk domain nevét:
A Create Application gombra kattintva kisvártatva (esetleg néhány perc múlva) megjelenik a konzol, illetve megnézhetjük a hivatkozott link alatt az elindított platformot: http://cloudtest-javaforum.rhcloud.com/
Ezzel a cloud létrehozásának hosszadalmas folyamata véget is ért, töltsük le és telepítsük a RedHatCloud (rhc) alkalmazását, amelyhez a Getting Started oldalon találunk útmutatást, majd nézzük meg, hogy jól működik-e a telepített kliens alkalmazás, ezért válaszoljunk a feltett kérdésekre:
$ rhc help
Starting Interactive Setup for OpenShift's command line interface
It looks like you have not configured or used OpenShift client tools on this computer. We'll help you configure the client tools with a few quick questions. You can skip this in the future by copying your configuration files to other machines you use to manage your OpenShift account:
/home/auth.gabor/.openshift/express.conf
/home/auth.gabor/.ssh/
To connect to openshift.redhat.com enter your OpenShift login (email or Red Hat login id): auth.gabor@javaforum.hu
Password: ************
Created local config file: /home/auth.gabor/.openshift/express.conf
The express.conf file contains user configuration, and can be transferred to different computers.
No SSH keys were found. We will generate a pair of keys for you.
Created: /home/auth.gabor/.ssh/id_rsa.pub
Your public ssh key must be uploaded to the OpenShift server. Would you like us to upload it for you? (yes/no) yes
You can enter a name for your key, or leave it blank to use the default name. Using the same name as an existing key will overwrite the old key.
Current Keys:
None
Since you do not have any keys associated with your OpenShift account, your new key will be uploaded as the default key
Sending new key default .. Success
We will now check to see if you have the necessary client tools installed.
Checking for git ... found
Checking for your namespace ... found namespace:
javaforum
Checking for applications ... found
* cloudtest - http://cloudtest-javaforum.rhcloud.com/
The OpenShift client tools have been configured on your computer. You can run this setup wizard at any time by using the command 'rhc setup' We will now execute your original command (rhc help)
Usage: rhc (<resource> | --help) [<command>] [<args>]
Command line tool for performing operations related to your rhcloud account.
List of resources
domain Manage the namespace for the registered rhcloud user.
app Manage applications within the rhcloud account.
sshkey Manage multiple keys for the registered rhcloud user.
port-forward Forward remote ports to the workstation
server Display information about the status of the service.
setup Run the setup wizard to configure your account.
See 'rhc <resource> --help' for more applicable commands and argumments on a specific resource.
Ne hezitáljunk sokat, kérdezzük le a platform jellemzőit:
$ rhc domain show
Password: ************
User Info
=========
Namespace: javaforum
RHLogin: auth.gabor@javaforum.hu
Application Info
================
cloudtest
Framework: jbossas-7
Creation: 2012-07-05T15:15:32-04:00
UUID: 03ab18978225420f881671b5b9e31e52
Git URL: ssh://03ab18978225420f881671b5b9e31e52@cloudtest-javaforum.rhcloud.com/~/git/cloudtest.git/
Public URL: http://cloudtest-javaforum.rhcloud.com/
Embedded:
None
A megadott Git URL alatt megtaláljuk a demó alkalmazásunk forráskódját:
$ git clone ssh://03ab18978225420f881671b5b9e31e52@cloudtest-javaforum.rhcloud.com/~/git/cloudtest.git/ Initialized empty Git repository in /home/auth.gabor/cloudtest/.git/ The authenticity of host 'cloudtest-javaforum.rhcloud.com (184.72.83.237)' can't be established. RSA key fingerprint is cf:ee:77:cb:0e:fc:02:d7:72:7e:ae:80:c0:90:88:a7. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'cloudtest-javaforum.rhcloud.com,184.72.83.237' (RSA) to the list of known hosts. remote: Counting objects: 39, done. remote: Compressing objects: 100% (29/29), done. remote: Total 39 (delta 1), reused 0 (delta 0) Receiving objects: 100% (39/39), 19.52 KiB, done. Resolving deltas: 100% (1/1), done. $ cd cloudtest/ [auth.gabor@javaforum cloudtest]$ ls -l total 20 drwxr-xr-x. 2 auth.gabor users 4096 Jul 5 21:51 deployments -rw-r--r--. 1 auth.gabor users 1707 Jul 5 21:51 pom.xml -rw-r--r--. 1 auth.gabor users 7629 Jul 5 21:51 README drwxr-xr-x. 3 auth.gabor users 4096 Jul 5 21:51 src
Nézzünk bele a pom.xml állományba:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>cloudtest</groupId>
<artifactId>cloudtest</artifactId>
<packaging>war</packaging>
<version>1.0</version>
<name>cloudtest</name>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>
</properties>
<dependencies>
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>1.0.0.Final</version>
<type>pom</type>
<scope>provided</scope>
</dependency>
</dependencies>
<profiles>
<profile>
<!-- When built in OpenShift the 'openshift' profile will be used when invoking mvn. -->
<!-- Use this profile for any OpenShift specific customization your app will need. -->
<!-- By default that is to put the resulting archive into the 'deployments' folder. -->
<!-- http://maven.apache.org/guides/mini/guide-building-for-different-environments.html -->
<id>openshift</id>
<build>
<finalName>cloudtest</finalName>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<outputDirectory>deployments</outputDirectory>
<warName>ROOT</warName>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
Szimpla webalkalmazásnak néz ki, hozzunk létre egy helloworld.jsp állományt, és írjuk bele a klasszikus szavakat:
Hello World! :)
A létrehozott fájlt adjuk hozzá a feltöltendő módosításokhoz:
$ git add src/main/webapp/helloworld.jsp $ git commit -m "Hello World message" [master cb9e8ff] Hello World message [...] 1 files changed, 2 insertions(+), 0 deletions(-) create mode 100644 src/main/webapp/helloworld.jsp
Majd toljuk fel a változást és lepődjünk meg, ugyanis a push során néhány action_hook hatására a távoli oldalon megtörténik a build folyamat, illetve sikeres build után a deploy:
$ git push Counting objects: 10, done. Compressing objects: 100% (4/4), done. Writing objects: 100% (6/6), 480 bytes, done. Total 6 (delta 3), reused 0 (delta 0) remote: Stopping application... remote: Done remote: ~/git/cloudtest.git ~/git/cloudtest.git remote: ~/git/cloudtest.git remote: Running .openshift/action_hooks/pre_build remote: Found pom.xml... attempting to build with 'mvn -e clean package -Popenshift -DskipTests' remote: Apache Maven 3.0.3 (r1075437; 2011-06-20 13:22:37-0400) remote: Maven home: /etc/alternatives/maven-3.0 remote: Java version: 1.6.0_24, vendor: Sun Microsystems Inc. remote: Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre remote: Default locale: en_US, platform encoding: UTF-8 remote: OS name: "linux", version: "2.6.32-279.el6.x86_64", arch: "i386", family: "unix" remote: [INFO] Scanning for projects... remote: [INFO] remote: [INFO] ------------------------------------------------------------------------ remote: [INFO] Building cloudtest 1.0 remote: [INFO] ------------------------------------------------------------------------ remote: [INFO] remote: [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ cloudtest --- remote: [INFO] remote: [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ cloudtest --- remote: [INFO] Using 'UTF-8' encoding to copy filtered resources. remote: [INFO] Copying 1 resource remote: [INFO] remote: [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ cloudtest --- remote: [INFO] Nothing to compile - all classes are up to date remote: [INFO] remote: [INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ cloudtest --- remote: [INFO] Using 'UTF-8' encoding to copy filtered resources. remote: [INFO] skip non existing resourceDirectory /var/lib/stickshift/03ab18978225420f881671b5b9e31e52/app-root/runtime/repo/src/test/resources remote: [INFO] remote: [INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ cloudtest --- remote: [INFO] No sources to compile remote: [INFO] remote: [INFO] --- maven-surefire-plugin:2.7.2:test (default-test) @ cloudtest --- remote: [INFO] Tests are skipped. remote: [INFO] remote: [INFO] --- maven-war-plugin:2.1.1:war (default-war) @ cloudtest --- remote: [INFO] Packaging webapp remote: [INFO] Assembling webapp [cloudtest] in [/var/lib/stickshift/03ab18978225420f881671b5b9e31e52/app-root/runtime/repo/target/cloudtest] remote: [INFO] Processing war project remote: [INFO] Copying webapp resources [/var/lib/stickshift/03ab18978225420f881671b5b9e31e52/app-root/runtime/repo/src/main/webapp] remote: [INFO] Webapp assembled in [214 msecs] remote: [INFO] Building war: /var/lib/stickshift/03ab18978225420f881671b5b9e31e52/app-root/runtime/repo/deployments/ROOT.war remote: [INFO] WEB-INF/web.xml already added, skipping remote: [INFO] ------------------------------------------------------------------------ remote: [INFO] BUILD SUCCESS remote: [INFO] ------------------------------------------------------------------------ remote: [INFO] Total time: 30.692s remote: [INFO] Finished at: Thu Jul 05 15:59:43 EDT 2012 remote: [INFO] Final Memory: 6M/163M remote: [INFO] ------------------------------------------------------------------------ remote: Running .openshift/action_hooks/build remote: Emptying tmp dir: /var/lib/stickshift/03ab18978225420f881671b5b9e31e52/cloudtest/jbossas-7/standalone/tmp/auth remote: Emptying tmp dir: /var/lib/stickshift/03ab18978225420f881671b5b9e31e52/cloudtest/jbossas-7/standalone/tmp/vfs remote: Emptying tmp dir: /var/lib/stickshift/03ab18978225420f881671b5b9e31e52/cloudtest/jbossas-7/standalone/tmp/work remote: Syncing Git deployments directory [/var/lib/stickshift/03ab18978225420f881671b5b9e31e52/app-root/runtime/repo//deployments/] with JBoss deployments directory [/var/lib/stickshift/03ab18978225420f881671b5b9e31e52/cloudtest/jbossas-7/standalone/deployments/] remote: sending incremental file list remote: deleting ROOT.war.deployed remote: .gitkeep remote: ROOT.war remote: remote: sent 9968 bytes received 50 bytes 20036.00 bytes/sec remote: total size is 9824 speedup is 0.98 remote: Running .openshift/action_hooks/deploy remote: Starting application... remote: Done remote: Running .openshift/action_hooks/post_deploy To ssh://03ab18978225420f881671b5b9e31e52@cloudtest-javaforum.rhcloud.com/~/git/cloudtest.git/ 9977015..ce88d1e master -> master
Az eredmény nem marad el: http://cloudtest-javaforum.rhcloud.com/helloworld.jsp
Kellemes próbálgatást...
Június 15-én jelent meg a JRebel 5.0, amely a már megszokott deploy nélküli fejlesztés támogatásának javításain túl három nagyobb újdonságot tartalmaz:
- JRebel Remoting, amely lehetővé teszi, hogy a három nagyobb cloud szolgáltató (AWS, Rackspace és Jelastic) szerverein futó szolgáltatásaink fejlesztése során is úgy dolgozhassunk, mintha helyben futna az alkalmazás szerver.
- Config Center, amely a kézzel szerkesztett rebel.xml fájlhoz ad egy IDE felületet.
- myJRebel, ahol a JRebel licenceinket tudjuk felügyelni, főképp pedig lehetővé teszi a JRebel használatát SaaS (Software-as-a-Service) modellben.
A Zeroturnaround – a JRebel fejlesztője – létrehozott egy videót, amely a JRebel használatát mutatja be a Vaadin keretrendszerben való fejlesztéssel:
További információ: http://zeroturnaround.com/software/jrebel/
Érdekes lépésnek tűnik az a felvásárolás, mivel a FuseSource két fő terméke az integrációra és az üzenet alapú kommunikációra szolgáló Fuse ESB Enterprise, illetve a Fuse MQ Enterprise, ám ezeken a területeken a Red Hat már rendelkezik egy 2006-ban felvásárolt megoldással: a Rosetta alapú JBossESB nevű termékük célja szintén az integráció és a MoM (Message oriented Middleware).
“Application integration software is one of the fastest growing segments of the enterprise software market,” said Craig Muzilla, vice president and general manager of middleware at Red Hat. “As cloud computing becomes more prevalent, enterprise customers are demanding greater application integration to enable seamless use of cloud computing. With the addition of FuseSource to our middleware portfolio, we will enable customers to experience greater integration capabilities and flexibility. FuseSource’s technologies, expertise, and commitment to open source make them a great fit.”
(forrás: http://fusesource.com/redhat/)
Köztudott, hogy a Red Hat alapvetően az Enterprise megoldásaiból él meg, így elgondolkodtató, hogy milyen tervei vannak a JBossESB termékükkel, amely egy élő és létező termék a fizetős szekcióban is JBoss Enterprise Middleware, illetve JBoss SOA-P néven. Belátható, hogy hosszú távon ezen a piacon egy termékre célszerű építeni, a JBossESB mellé bevásárolt újabb ESB megoldás okán három eset képzelhető el:
- A JBossESB által kitaposott piaci szegmensbe idővel a FuseESB kerül
- A FuseESB által kitaposott piaci szegmensbe idővel a JBossESB kerül
- A két termék előnyös megoldásait egyesíti a Red Hat egy termékben
A JBossESB tudását és elterjedtségét illetően az első opció a valószínű, érdemes összevetni a FuseESB és a JBossESB Community kiadásainak a fórumát. Ahogy a mellékelt képen is látszik, a JBossESB fóruma sokkal kevésbé pörög, amelynek alapvetően nem az az oka, hogy kevesebb a problémával találkoznak az ESB felhasználói:
Közelebbről megnézve kiderülhet, hogy a JBossESB ugyan egy jól megtervezett alapokkal rendelkező keretrendszer, ám a 2006-os felvásárlása óta alapvetően nem változott a felépítése, az eltelt hat év nem hagyott nyomot az architektúrán. Bár a Red Hat stratégiai termékként pozicionálta, látszólag nem tett erőforrásokat a projekt mögé, a JBossESB 4.x fejlődése pont olyan görbét jár be, mint a JBoss AS 4.x, amelynél évekig ígérgették a következő félévre a JBoss AS 5.x megérkezését, de csak nem sikerült kiadni – aztán észbe kaptak és a négy évvel ezelőtt kiadott JBoss AS 5 után már egy éve már egy alapoktól újraírt és újragondolt a JBoss AS 7 tölthető le.
A JBossESB fejlődését tekintve ugyanezen három év alatt sikerült eljutni a 4.3 verziótól a 4.10 verzióig, amelyek között – némi szolgáltatásbővítést leszámítva – nem sok architekturális változás történt, az utolsó két verzió közötti változásokat taglaló release notes nincs fél oldal és 9 hónap telt el a két kiadás között... pedig igény bőven lenne arra, hogy ebbe a termékben hatalmas fejlesztéseket toljanak. A nagy kérdés az, hogy mi lesz a jövő? A felvásárlást követően aligha fog a JBossESB 2,5 issue/hónapot is elérő fejlesztési sebessége megtáltosodni, az eltérő architekturális felépítés okán donorként se lehet tekinteni erre a projektre. Ha a nagy reményű JBoss Portal sorsára jut – amely helyett a Red Hat az Exo platformjára nyergelt át GateIn néven kiadott portál révén, akkor ideje lenne ezt közölni a JBossESB közösséggel...