Java™ 2 Enterprise Edition (J2EE) is an environment for developing and deploying enterprise applications. The J2EE platform consists of services, application programming interfaces (APIs), and protocols that provide functions for developing multi-tiered, Web-based applications.For product information, see WebSphere Application Server zone and WebSphere Studio zone.
Question: BEA's controls and annotations for EJBs/Web services seem to be powerful and easy to use technologies. Your thoughts and how easy to use these within WebSphere®.
Answer: It sounds like you are looking for a comparison of BEA® WebLogic Workshop with IBM WebSphere Studio Application Developer (hereafter called WebSphere Studio). I have not used Workshop, so I cannot comment on its features directly. WebSphere Studio does include numerous editors for meta information like deployment descriptors. These editors are much easier to use than editing raw XML (although the Source notebook page allows you to do that, too). Also, these editors have been redesigned in WebSphere Studio V5 to more clearly distinguish between configuration settings that are J2EE specific compliant and those that are WebSphere specific.
Question: Do you happen to know if by enabling WebSphere Application Server V5.1 Global Security, the transport between Web service and WebSphere Application Server will automatically be turned to https? For example, the defaultSSLsettings and jmserver cert will be used. I do not have to create new certs between Web and Application servers. By the way, I already have https between Web and browser clients. Now, it is just lacking Web<>WAS https. Global security is not enabled yet.
Answer: Will enabling global security in WebSphere Application Server 5.1 automatically make the transport for Web services HTTPS? Not that I know of. You need to enable this yourself. See "Invoking web services over HTTPS" and "Securing Simple Object Access Protocol services on Secured Socket Layer with HTTP basic authentication" in the WebSphere Application Server Information Center.
Question: We have a set of EJBs in our project. Basically, we have EAR files installed in WebSphere Studio V5.1.2. The code changes made to the EJB project and client projects are not getting reflected when the test environment server is running. I need to restart the test environment server every time to make the changes effective. Is there any solution or configuration setting to resolve this?
Answer: If you enable hot-method replace, when you use the debugger to edit code (such as in an EJBs implementation class, without changing the EJB's interface), the code changes will be made immediately to the running application. See "Hot-method replace" in WebSphere Studio's online help. You can also restart an individual project, which is much faster than restarting the entire server. Many changes, though, require restarting the test server; see "When the test server requires restarting" in WebSphere Studio's online help. Also see "Debugging an enterprise bean on a server" and "Debugging a servlet on a server".
Question: In our Web application, we want to pass the uid and pwd to the EJB layer so that the session EJB can connect to backend system using the uid and pwd. We do not like to pass the uid and pwd as parameters or store in some objects to pass from the Web tier to the EJB tier. Also, there is a different process which needs the uid and pwd to connect to the backend. What is the recommended solution to achieve this?
Answer: With a J2EE application, all users of the application use the same login to access backend systems. J2EE does not enable each application user to use a separate login. Your EJB layer should be a stateless service fronted by a stateless session bean, so it cannot store user data such as a username or password. You could store these items in the user's HTTPSession, but that would be a huge potential security hole, and the login information would not be very useful You need to use the J2EE services for accessing back-end systems, which use one login for all users.
If your backend system is a JDBC database, you should associate the login with the Data Source. For example, in WebSphere Studio, in the server configuration editor, add the login as a
JAAS Authentication Entry on the Security page, and then specify it as the Data Source's container-managed authentication alias (on the Data Source page). For other backend systems, you should obtain or develop an adapter that complies with the J2EE Connector Architecture, which also provides for logins.
If you have two types of users who should use two different logins, my article Eliminate caching in service locator implementations in J2EE 1.3 discusses how to do this using two different EJB classes. Obviously, this technique will not scale for enabling thousands of users to each have their own login.
Question: I am by no means an EJB expert, but I have worked through a number of tutorials and Redbooks that IBM offers on the subject matter. I personally feel that the ability of WebSphere Studio to generate "administrative code" that is optimized to harness the power of the container allows the developer to be significantly more productive than developing without EJBs. This even applies to situations where EJBs are overkill. My question is this: Do I have it correct? I have been trying to get our company to look at EJB development with WebSphere Studio/WebSphere Application Server from a pure productivity standpoint, but outside consultants have dredged up all the EJB horror stories.
It would help if IBM had a white paper targeted for small to mid-sized shops that showed a moderately more complex web-based EJB application than the "Banking" application, developed using the power of WebSphere Studio and WebSphere Application Server compared to a Spring/Hibernate/JDO/"whatever" solution. My contention is that the speed gained designing and developing the application along with the reduction in the amount of code that is actually written is far more productive using WebSphere Studio. This assumes that your wizard generated code is in effect supported by the tool.
Details of the time spent, the code created not generated, performance of the applications, and the costs associated with each aspect would go along way to prove that J2EE/EJB development is more productive and maintainable using WebSphere Studio/WebSphere Application Server than hammering out line after line of business and administrative code. Once again, I am assuming that hardware costs associated with improving overall performance are negligible when balanced against the cost of an increased development time and maintenance of a larger code base.
Answer: I agree with your suggestion for more marketing and technical materials targeted towards the SMB market, but that's not actually my department. What I can do is try to answer technical questions.
You are on the right track, that you should maximize your use of the tools to make your job simpler and develop code that maximizes the use of the container to make the code's job simpler. Simpler and shorter code is easier to write, test, debug, maintain, and port. Your code should focus on your unique business value, not the plumbing every typical application needs, which can be handled by the container.
I am not a big fan of the EJB horror stories. Many of them are from the EJB 1.0 timeframe and ignore improvements like local interfaces and container-managed relationships (CMR). Most horror stories involve entity beans and ignore how terrific session and message-driven EJBs can be.
Even with entity beans, O/R mapping is very difficult, so what are you going to use that is so much better? I encourage developers to start out using CMP entity beans to model their domain and handle the O/R mapping to their database. "But CMP is slow!" Well, perhaps, but so is O/R mapping in general, and at least with CMP, you give the container the opportunity to optimize the process. IBM has a ton of developers dedicated to making O/R mapping work as well as possible. I would tend to ask any customer: Do you really think your team can develop code that isN better? (Especially if they already think EJB is too difficult?) I say, try CMP first. If it proves to be too slow (or otherwise horrible), identify the specific beans that are a problem and surgically replace them. Then to be intellectually honest, you need to run your load tests again and prove that your new code really is better than the CMP code it replaces. If developers were really this rigorous about examining their own results, and not just believing rumors, I think they would find that the standard J2EE features and the WebSphere support for them actually work pretty well. See Persisting Domain Objects.
Question: We developed one J2EE application using WebSphere Studio 5.0 as the development environment. But, we want to deploy it on WebSphere Application Server 4.0. As WebSphere Studio 5.0 is generated, the EAR file which is compatible to WebSphere Application Server 5.0. It was giving errors regarding the DTD. As far as EJBs are concerned, we have used stateless session beans only. What are the changes required and where are they required to deploy the application in WebSphere Application Server 4.0?
Answer: If I understand your question correctly, you are trying to use WebSphere Studio 5.0 (the latest version is now 5.1.2, so you may want to upgrade to that) to develop an application that you will deploy in WebSphere Application Server 4.0. It sounds like you developed your application for WebSphere Application Server 5.0, which is the default mode in WebSphere Studio 5.0, and now it will not deploy and in WebSphere Application Server 4.0, so you want to know why and what to do about it. I hope I am understanding your problem correctly.
Good news! You can definitely use WebSphere Studio 5.0 to develop WebSphere Application Server 4.0 applications. This is a specific feature of WebSphere Studio 5.0, so that developers can upgrade to our latest tools even if production is not ready to upgrade to the latest version of WebSphere Application Server. You just need to know how.
What you need to do is develop an application for WebSphere Application Server 4.0, not the WebSphere Studio 5.0 default of WebSphere Application Server 5.0. Here are a couple of examples of where and how you do this:
- In the J2EE perspective, when you choose New -> Enterprise Application Project, choose to create a J2EE 1.2 project. Do this because WebSphere Application Server 4.0 supports J2EE 1.2, not the WebSphere Studio 5.0 default of J2EE 1.3.
- Also in the J2EE perspective, when you choose New -> EJB Project, choose to create an EJB 1.1 project. Do this because WebSphere Application Server 4.0 and J2EE 1.2 support EJB 1.1, not the WebSphere Studio 5.0 default of EJB 2.0. (Of course, you will not get the latest EJB 2.0 features, but for that you will need to upgrade to WebSphere Application Server 5.0.2 or later.)
- In the Server perspective, when you choose New -> Server and Server Configuration, choose to create a server whose Server Configuration Type is WebSphere v4.0 Server Configuration. You can find this in the WebSphere version 4.0 folder in the Server Type list. This creates a test server that is a WebSphere Application Server 4.0 standalone server, so that you can test your J2EE 1.2 application that you intend to deploy in full WebSphere Application Server 4.0.
- In Window -> Preferences, under J2EE, for Highest J2EE Version Used for Development, you can choose J2EE 1.2. Then WebSphere Studio will assume you are developing for WebSphere Application Server 4.0 (or another J2EE 1.2 container).
Question: Here is a design issue about transaction management and rollback writing on a single DB2® instance (non-distributed transaction). An application is using the DAO pattern to save data into multiple tables, each DAO used one save on one table. A session facade EJB business methods call more than one DAO to save on more than one table. Container managed transactions is enabled. I read some articles on declarative transaction management and you need to do one of two things:
- Use setRollBackOnly() in the business method
- Make the business method to throw a runtime exception
For now, the second choice has been selected; a DAOException is made to extend RuntimeException and all DAO classes throw a DAOException instance in case an error occurred. Could you please advise on what is the best choice, what makes our code more reusable? For the first choice, I see that you need to add extra code lines setRollBackOnly() to each business method, which I see as inconvenient.
Using the WebSphere Studio V4 IDE test environment, transaction management and roll back go fine, but whenever the application is deployed on WebSphere Application Server V4, no rollback occurs at all. Is there any specific configuration or setting to enable declarative transaction management on WebSphere Application Server V4?
Answer: Good use of patterns. Data Access Object (DAO) and Session Facade are both good ones to use. Because you are using EJBs, you have run into a common dilemma: How should your EJB code implement and use application exceptions, when should it use setRollbackOnly(), and how does this all go together?
An application exception represents the occurrence of a business logic error: withdrawing more than an account balance, reserving a seat which is already reserved, getting a credit card charge denied, etc. This is different from a system exception, which represents a system level error like running out of memory or running past the end of an array. According to the EJB specification (Chapter 18), an application exception must be a subclass of Exception and must not be a subclass of RuntimeException nor RemoteException, which is very good advice. Meanwhile, according to the spec, the container must catch system exceptions, mark the transaction for rollback, and throw RemoteException or EJBException to the EJB client. The container must pass application exceptions through to the EJB client without changing the exception nor changing the transaction.
I think this is rather inconsistent, that system exceptions cause automatic rollback while application exceptions specifically do not. An exception has been thrown so should you really commit the transaction (which is the automatic behavior)? I don't think so. Nevertheless, this is the way EJB works.
So, in your situation: Your application exception classes are subclasses of RuntimeException. This is bad. While it performs the rollback automatically, it also converts your hopefully meaningful and descriptive application exception to a generic one. The spec says not to do this.
You are going to have to handle rollbacks yourself. This means you need to get in the habit of writing code in your session facades (your topmost layer of code in your EJB container) that catches application exceptions, calls setRollbackOnly(), and rethrows the same exception so that the EJB client knows what happened. This is the way to write good EJB code: Don't subclass RuntimeException, and use setRollbackOnly() before throwing an exception out of the EJB container.
Question: My application is developed previously on J2EE 1.2 standards with WebSphere 4.0. Presently, I am trying to convert the application using WebSphere Studio 5.0 (WebSphere 5.0) J2EE 1.3 standards. I migrate the application at the j2ee1.2 -j2ee1.3 level.
I have two modules, one is an EJB module (it has all EJBs, etc), the other one is a Web module. The Web module converted successfully as per J2EE 1.3 standard. The EJB module shows some errors at the time of conversion. The log files show:
Info: Project structure did not need migration: SCLS-ejb. Info: J2EE version level did not need migration: SCLS-ejb. Info: Migration was not required for META-INF/ejb-jar.xml. Error: java.lang.NullPointerException Error: Unable to migrate the Map and Schema file structure in project SCLS-ejb
Due to the error, I am unable to run the application properly. All entity beans are not working. I am unable to insert a record by using entity beans.
Answer: You have used the J2EE Migration Wizard in WebSphere Studio 5.0 to attempt to migrate your J2EE 1.2 application to J2EE 1.3, but it failed with NullPointerException. It is difficult for me to diagnose what went wrong with the tool without knowing more about your code. You will probably need to get help from IBM Support. As for why your EJB code does not run properly, this may be because of the problem you had with the migration tool, but it may also be because you need to migrate your code. The migration wizard only updates your deployment descriptors, not the code in your EJB implementations. See "Migrating J2EE applications" and "Migrating from J2EE 1.2 to 1.3" in the WebSphere Studio online help.
Question: Do I really need to learn EJB?
Answer: Here's a story I like to tell from when I presented at the WebSphere Technical Exchange conference. I presented a session and a lab on distributed (XA) transactions: how to code them, how they work, and how they work. The lab consisted of some simple example code, mainly a stateless session bean (EJB) that updated both a JDBC database and a JMS messaging system, therefore requiring a distributed transaction. The example also contained a servlet that simply invoked the SSB. The lab went great, the transactions rolled back when they were supposed to, everything was terrific. After the lab, a customer asked me, "That's great! How do I do that just using servlets?" The answer is: you don't. I asked why not use an EJB. He and his co-workers felt EJBs are too complicated. Even though EJBs and container-managed-whatever make difficult programming much easier, people think they are still not easy enough.
The moral of the story is: If you have tools for performing difficult tasks, and you want to perform those tasks, you need to learn the tools. I do not want to defend EJBs as easy, but I do think they make it a lot easier to do very sophisticated tasks: transactions, security, pooling, remoteness--and yes, thanks to entity beans with container-managed persistence, even persistence. What other technology enables you to use objects for a few hundred users to support many thousand users? What other technology allows you do declare your transaction model, security model, persistence model, and so on in XML, and runs those models for you at runtime?
Java (J2SE) includes an extensive class library so that you are never developing an application from scratch. J2EE includes services and frameworks that do much of what your application already needs. Get the container to do as much work as possible so that your application does not have to. Write your application in as little code as possible and get the container to do the work. Less code is faster to develop, easier to maintain, and quicker to port to the next versions of J2EE and WebSphere Application Server. So my suggestion is, as much as possible, learn what the container gives you and what development tools like WebSphere Studio Application Developer enable you to do, and make the best use of those as you can.
Question: Should I use synchronous or asynchronous communication?
Answer: This comes up all the time. We're using RPC (for example, RMI, CORBA, EJBs with remote interfaces, and so on; why should we use JMS/messaging? In general, when a user's waiting on the answer, since the user is synchronous, make calls synchronously. When one application is calling another, make that call asynchronously. When one application wants to inform several others of an event, do so asynchronously. Synchronous calls are much more fragile, so to make a remote call more robust, make it asynchronous.
There is a perception that messaging is somehow slower and less efficient than RPC. While messaging does have more overhead than RPC, that makes only a small performance difference, unless you add much greater quality of service like persistent messaging. Bottom line, if messaging is slow, it is because your network is slow, in which case RPC would also be slow or would not work at all.
Often the user interface does not seem to support making calls asynchronously, since the UI is blocking on a call that may take a while. One technique is to reload the page until the result is available. See Asynchronous queries in J2EE by Kyle Brown. Even better, redesign the UI to not be so synchronous. For example, an e-commerce site doesn't make the browser block while it packs and ships an order. It tells the user "thanks for your order" and sends e-mail with the package tracking number when the order ships. This requires that the UI kick off a workflow that will run asynchronously, so you need a workflow engine like Process Choreographer. Then the processing can be done asynchronously, the activities can be performed asynchronously, the user can be informed when milestones are reached, and the user can check progress whenever the user likes.
It is also worth noting that this is a shortcoming of Web services. Currently, Web services (WS-I Basic Profile 1.1) are synchronous. The caller sends an HTTP request and blocks waiting for the HTTP response. Because Web services are for application-to-application communication, they are more useful when they can support asynchronous communication.
Question: What is the difference between SOA and ESB?
Answer: A Service Oriented Architecture (SOA) is a way or architecting an application such that its functionality is composed of autonomous services, which the application then aggregates into user functionality through a user interface (UI) or via a workflow. More than just a component of reusable code, a service is part of a running program that can be invoked by a client without having to incorporate the code itself. In fact, the boundaries of an application become much more vague as it comes to include all of the services it can invoke to perform its functionality.
An Enterprise Service Bus (ESB) is a mechanism for coordinating the callers and service providers in an SOA. It enables a caller to invoke a service without knowing who provides it or what address the provider uses. The ESB can choose amongst multiple providers, load balance across providers and stop using a provider while it is unavailable, and select amongst providers with varying levels of qualities of service based on the caller's requirements. An ESB can coordinate synchronous or asynchronous services, and in fact can provide both synchronous and asynchronous access to the same service.
So SOA and ESB are counterparts. An application with an SOA should use an ESB to invoke its services. SOA and ESB do not necessarily have to be implemented with Web services. However, it is often desirable for an ESB to make the services it provides access to self-describing and discoverable, which Web services help to do. And it is often desirable in an SOA for callers implemented in one technology to be able to invoke services that may be implemented in many other technologies, which Web services help to do. So SOA, ESB, and Web services all help converge to create the world where functionality in any application is available to any other application, the ultimate in reuse.
- Eliminate caching in service locator implementations in J2EE 1.3
- Configuring and using XA distributed transactions in WebSphere Studio
- Asynchronous queries in J2EE
- WS-I Basic Profile 1.1
- WebSphere Application Server Information Center
- WebSphere Application Server Support
- WebSphere Studio Application Developer 5.1 Information Center
- WebSphere Studio Support
- J2EE in Practice (blog)
- WebSphere Application Server zone
- WebSphere Studio zone
- Enterprise Integration Patterns
- The Design Patterns Smalltalk Companion
About Meet the experts
Meet the experts is a monthly feature on the developerWorks WebSphere Web site. We give you access to the best minds in IBM WebSphere, product experts and executives, who are waiting to answer your questions. You submit the questions, and we post answers to the most popular questions.
Dig deeper into WebSphere on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.