Oracle purchased BEA and their WebLogic suite of tools. They still have a competing product in their own 10gAS Application Server. Both are Java EE, enterprise grade, servers. While it make take some time due to maintenance agreements, it would be unusual for them to continue to produce two products within the same architectural space. So...
Will they retire their previous application server in favor of WebLogic?
Is WebLogic the one that will be retired?
How long of a process is this likely to be? Years?
What have they done with PeopleSoft vs. Oracle Applications? Likely the same pattern will be followed.
You can go through a (rather long) PDF strategy briefing from Oracle. The key slide, though, is probably #48. Oracle has put BEA Weblogic on the "Strategic Products" list and the Oracle Application Server on the "Continue and Converge" list. So Oracle has indicated that the Oracle App Server will be going away (in marketing-ese that it will be converged with the BEA products) and that BEA Weblogic is the strategic direction going forward.
As to question 3, I'm sure it'll be at least a few years depending on your definition of "retired".
Yes. They have already announced their position. OC4J/Orion will continue to be supported however the weblogic release is the future of the platform.
In Oracle terms, the product "Oracle Application Server" contains much more than just the J2EE server. One component is the J2EE server, which used to be OC4J. Oracle has announced that their new strategic J2EE server is WebLogic.
There will therefore still be a product called "Oracle Application Server", but from version 11g onwards, the J2EE server will be WebLogic.
Oracle will release a 11g version oc4j, but after that Oracle WebLogic Server (WLS) will be the preferred Java EE server. WLS is much better with clustering and has a lot of JMS / JDBC options.
Yes, that is a fact. Oracle explained it in the product road map earlier in this year. The "new" product is called Oracle Weblogic Server, and that's what all sales men should offer to new customers from now on. The PDF file posted by Justin shows that.
Take a look to Oracle Weblogic 10g :S :S
alt text http://img266.imageshack.us/img266/2200/oracleweblogic10guk4.png
As you say, it would be unusual for them to maintain two products within the same architectural space. I don't know Java application servers, but given the climate of financial markets, and that it would probably take lots of money to maintain two such application servers, I would say it's a foregone conclusion that one of the products will be cut, and sooner rather than later at that (as soon as the cost of settling breach of maintenance contracts falls below what it costs to maintain the outgoing product). As for which one will go, my bet will be on WebLogic because it "wasn't invented here"...
Related
I'm junior backend developer and now I'm working on a project about bank, which is a distributed system. What I knew before was that there were some message library such as ZeroMQ to realize the communication between components in a distributed system. But now, in the project, they used oracle queuing.
My colleague told me that this was better because we had no risk to lose any message to send even if processes die accidently.
My questions:Q1: If Oracle queuing is better, when should we use things like ZeroMQ?
andQ2: What is the disadvantage of Oracle queuing, comparing with ZeroMQ?
Your colleague is right here, because Oracle AQ comes with persistence and zeroMQ is in-memory. You'd use zeroMQ if you need max messages per second (millions). Price isn't a thing, because Oracle doesn't charge extra for AQ, it's even free with Oracle XE.
If your application relies on Oracle already, there are no disadvantages putting the messaging into Oracle.
Does PreparedStatement.setFetchDirection(ResultSet.FETCH_FORWARD) make a difference for an Oracle DB?
I'm on project to upgrade the database and application server for the power facilities and line maintenance system of a large electrical utility company. We are testing the new set up now (Oracle 12c and JBoss 7).
Sometimes the queries to the db are taking minutes to get an answer. I've suggested doing PreparedStatement.setFetchSize(int rows), where rows being the number of rows of information the user wants to see on his screen. Many posters here in Stackoverflow and elsewhere have said setFetchSize() is important to getting the network connection optimized.
But I noticed the PreparedStatement also has setFetchDirection(). There's FETCH_FORWARD, FETCH_REVERSE and FETCH_UNKNOWN. I've seen this mentioned many times, but I've not seen anyone saying how much of a benefit it is.
If it helps to understand the situation - the power company services 30 million customers, with decades of records (from nuclear power plants down to utility poles). The users of the service will be maintenance crews, office staff, both from with the company and from subcontractors. So, the computer skills and patience of the users may not tolerate a 3 minute wait to find the locations of the transformers they need to repair.
Oracle says
"The JDBC 2.0 standard allows the ability to pre-specify the
direction, known as the fetch direction, for use in processing a
result set. This allows the JDBC driver to optimize its processing."
However Oracle also says "the Oracle JDBC drivers support only the forward preset value" ResultSet.FETCH_FORWARD
"The values ResultSet.FETCH_REVERSE and ResultSet.FETCH_UNKNOWN are
not supported."
So, my guess is that if you are using JDBC 2.0 standard drivers, then you can optimize fetch by saying setFetchDirection(ResultSet.FETCH_REVERSE) when wanting to find overdue maintenance work. But if you are using Oracle JDBC drivers you are out of luck.
(Downvote me if I'm wrong - I know that improves your geek creed.)
AppHarbor looks very appealing for our .NET solution. But I have some questions I could not find on internet.
Our major concern is reliability of dedicated SQL Server:
Is it clustered / mirrored / replicated?
What happens when they upgrade / patch / maintain server or. hosted server and when hardware fails?
Are upgrades scheduled?
Can we set time interval when they do upgrades?
Which version and edition of Sql Server is used?
Can I use full text search?
Can I use Reporting service?
Is communication with SQL database reliable? For example in Azure SQL it is recommended to build in retry logic - if command does not succeed, retry.
Is AppHarbor reliable? Every cloud provider has occasionally some blackouts (Amazon, MS Azure ...). Is AppHarbor any less reliable compare to them? I know AppHarbor runs on top of Amazon.
Are there a lot of hidden issues you run into? What are the most common?
Did anybody decide to leave appHarbor for a good reason?
As far I can see Azure is a real cloud system with all the downside and upside - more scalable, but with modified infrastructure like customized SQL server .... AppHarbor mimics more on-premises solution. Is my understanding correct?
How is documentation?
How is support?
Thank you for your help.
Yes AppHarbor offers redundant/replicated dedicated SQL Server databases. These plans are available upon request.
This depends on the type of maintenance/update and your SQL Server database plan. If the database server is replicated, downtime can be minimized by failing over to the replica while performing maintenance. In the event of a server failure the database will be attached to a new instance and the application's configuration will be automatically updated. Should a hard drive fail leading to corrupted/lost data AppHarbor make daily backups that will be used to restore your database. It should be noted that hard drive failures are very rare.
We generally coordinate planned maintenance that requires downtime with customers whenever possible. Dedicated SQL Server customers can also select their own maintenance window.
Not really, but AppHarbor will reach out and coordinate with you when it is necessary.
Different SQL Server versions and editions are used depending on the plan. For single-instance dedicated SQL Servers we generally use SQL Server 2008 R2 Web Edition. Dedicated SQL Server 2012 instances are available upon request. Replicated setups require other and more expensive SQL Server editions. You may also want to consider our dedicated MySQL service if you'd like to reduce costs and don't rely on SQL Server specific features - since AppHarbor doesn't have to pay license costs these are less expensive, particularly for a replicated setup.
Yes.
Not by default, but we can work with you to support reporting services on your dedicated SQL Server instance.
Yes. In fact the primary reason customers upgrade from shared to dedicated SQL Server is for consistent, reliable performance.
I'd say so. The last major outage occurred on July 29th, 2012 due to an electrical storm that affecting multiple availability zones in AWS's North Virginia region. As an example, our blog has been available 99.997% of the time since then. In the event of an application instance failure applications are rapidly moved to healthy instances. We recommend running with at least two workers to ensure redundancy in those cases.
I'm admittedly not the best person to answer this question. The most common request/limitation we hear about is that you can't currently trigger a backup yourself. This will be available at a later time, but we do keep daily backups of your databases.
-
AppHarbor's cloud application platform is relatively similar to Azure in terms of scalability. We support rapid "elastic scaling" of application workers both vertically and horizontally. With regards to the dedicated SQL Server service your understanding is correct: It is very similar to an on-premise solution. While the scaling story is different compared to SQL Azure this allows for much greater flexibility. We can tailor a database plan and server that suits your requirements whether you need high CPU, RAM and/or I/O performance. Similarly we can offer database sizes that are 10x larger than SQL Azure's current 150GB database size limitation.
Most documentation is available in the knowledge base. We try and keep this as up-to-date and comprehensive as possible, but if you find yourself missing some information you're of course more than welcome to let us know and we'll add it. Third party add-on providers typically maintain their own AppHarbor-specific documentation.
This is another question where I may be a little biased, but I can tell a little about our goals: Our goal is to always answer non-critical support requests related to apps on both free and paid plans within the day. Critical support requests and supports requests related to applications or databases on paid plans take priority. Support is included in the plans, but we're working on offering premium support options as well. We generally try to exceed your expectations and are always happy to help out and give advice on issues you experience - whether they're related to the AppHarbor platform or not.
Disclaimer: I'm a co-founder of AppHarbor.
In a large corporation I worked in previously a manager purchased a $50,000+ Websphere production license despite the fact that he only needed a container to run a couple of servlets on a small intranet system.
Assuming we agree that this was overkill, to say the least, and that a free servlet runner like Tomcat would probably have sufficed, what type of business/technology use might justify the high cost of an application server such as Websphere? I'm thinking that integration projects are the most likely candidate - i.e. in environments in which multiple legacy systems need to be glued together using Java/Websphere as a bridge or wrapper. Any other good cases?
I don't necessarily agree with the following, but there is a fairly strong argument there...
<devil's advocate>
The key thing to remember when looking at licensing isn't necessarily the cost of the technology, but rather the cost of having someone point their finger at you at 2am when it's all gone belly up that you want money for.
There are a bunch of companies who have built their business model on this approach (eg Sun - leaving the obvious debate aside on whether that actually worked or not, RedHat, et al).
The benefits that IBM can provide for their products don't really come down to technology per se (as you said, you can get something that'll do the same job for a much better price), it's more about the business process around their products. If you're in an environment where you need predictable uptime, scalability, etc etc. (Banking for example)
IBM's products are reasonably well tested (one of the reasons they're usually a couple of releases behind the bleading edge elsewhere). You know that the things you're getting will be pretty robust, integrate well with other big-business systems (both legacy systems as you said, and other business systems like Siebel, Oracle, SAP, etc) not to mention the one-stop-shop support for integration with other IBM products (if you've drunk the full IBM cool aid).
You also know that where there are issues with what's being delivered, it's relatively transparent and there will be documented workarounds available for things you're likely to bump into.
</devil's advocate>
If you have smart enough people, you don't necessarily need the support that folk like IBM can offer (take the RedHat example - people can still go and download Linux for free and run their business on it). But at 2:00 you're on your own - you can't ring up Linux (or one of the Tomcat committers) and get them to tell you what you're doing wrong and help you fix it.
If you continue to look around, you'll find that many decisions like this aren't as based on technical considerations as you'd think they should be. I, like most other experienced practicioners, would choose one of the other stacks like Tomcat or JBoss. This isn't because they don't have licensing costs; it's because developers can build the best product in the shortest amount of time with them compared to the other J2EE products.
As to why IBM and other J2EE vendors still have as big a market share as they do, it's because of thought patterns like "Having a throat to choke", and "Can't get fired for buying IBM". Neither of which contain much technical merit, but that's because most of the time the people making these decisions aren't technically curent enough to understand the real factors, and don't have or don't trust the people that are qualified to make the decision.
This question is a little too fine-grained to give a short technical answer, since there are so many complicated aspects to building a successful product in the context of your situation. A couple general "Containers For Dummies" guidelines though:
Use either Tomcat or JBoss, move on, and focus on writing a good application. I see a strong up-vote for Glassfish, but I'd caution that it might not have the critical mass you'd be comfortable with. You can use one of the other vendor products and still succeed; They'll just weigh you down more.
When in doubt, listen to Rod Johnson. He and his company Spring Source are paving the way for the evolution of Java today. He's doing for Java containers today what Josh Block did for Java 1.2 (anyone use the Collections framework???)
Remember that Websphere is not just an overengineered Servlet container - it's an overengineered J2EE container. Hence, things like EJBs that are also supported in J2EE are present within WebSphere - so if an application does need them, they are available. Of course, why one would need WebSphere instead of a generic J2EE container is beyond me - unless they need overengineered feature Y that is due to be released in Milestone X of competing freely available product Z.
To be precise, Websphere is not a product. It's a product line. As stated by Martin, service is a crucial part of why people purchase IBM Websphere products (and btw. a big chunk of IBMs revenue).
Websphere consists not only of the J2EE stack (aka Websphere Application Server). It has many components/products built on top of it such as the Websphere Process Choreographer (workflow engine), Websphere Portal, Websphere Business Monitor and other useful components to run a business.
Websphere is a terrible product. Unless you need all the other IBM products that integrate with it and nothing else, theres no sensible reason to buy it. If all you want is a servlet container, grab Tomcat or Jetty.
They are infinitely faster and wont give your developers headaches. Websphere is a royal pain in the arse. Things that take seconds in tomcat eg deploying a small WAR, literally require minutes and a thousand clicks in Websphere.
In the end Websphere only gets sold to big corporate types where the manager, knows little technology, doesnt care about wasting^h^h^h^h investing the companies money, and becasuse of the old addage - nobody got fired buying IBM.
Many people dont use EJBs and stick to Hibernate and Servlets. If you do that in the beginning theres no reason why your WARs wont work in the future when you decide to move to Websphere because it - integrates with something. Then again you really should also be sure that you are aware of what other products you might need in the future and use that in your decision making process.
Im sure many other java types when forced to work with Websphere with just servlets often develop in Tomcat and then deploy at the very end in WS.
Which of the two databases is most popular in business/industry? I ask this because in terms of straight revenue or market share, I suspect they're about 50-50, because US government is big on DB2. So, discounting government, military, and academia, which database vendor has the greatest share of the business segment?
"Lies, damned lies, and statistics". Being a DB2 guy I am baised. But if you believe statistics from Gartner and other consultants Oracle has a lead over DB2 in terms of revenue. I don't think anyone really estimates number of server installs and I am not going to attempt to do this either but I can tell you that we had tremendous success with our DB2 Express-C offering. This is a real DB2 but it is offered free of license charges i.e. you don't have to pay IBM to use it for development, production or even redistribution. You can get optional support and extra features for a very low ($2,995/server) yearly charge. This is the same as MySQL Enterprise. Actually, it is $4 cheaper :-)
Since you are comparing DB2 and Oracle I figured I'd direct you to a comparison of DB2 Express-C and Oracle XE on my http://FreeDB2.com blog.
For a more recent press release originating from Gartner, see here