J2EE 1.4 Specification First Public Draft Available for Review


News: J2EE 1.4 Specification First Public Draft Available for Review

  1. The first public draft of the J2EE 1.4 specification is avialable for review. This new release of the platform is primarily aimed at Web Services integration. It defines the component model, deployment, packaging, and container requirements for J2EE components to be exposed as or to use Web Services. It also includes EJB 2.1, JMS 1.1, Servlets 2.4, and JSP 1.3.

    Read the J2EE 1.4 Specification First Public Draft.

    Check out JSR 151: J2EE 1.4 Specification.
  2. Is it really valid to call an external Web service straight from an EJB, as classically promoted (and as shown in fig J2EE.2-2 page 14 in the J2EE 1.4 spec)? The EJB spec indeed states that an EJB is not allowed to listen on a socket (*), what is obviously required to read the reply from the Web service. Should Web services not be rather called via a connector? Could someone clarify this rather crucial point?

    (*) The sentence is the following, to be exact:
    "An enterprise bean must not attempt to listen on a socket, accept connections on a socket, or use a socket for multicast."
  3. I don't have the specs right here but I think that it's ok to open a socket but not to wait for connections on a serversocket.

  4. An enterprise bean is allowed to open a connection to a remote host. That is what's required in order to make a web-service call. The reply from the web service, say using SOAP, is read from the same connection that the request was made on.
    Read the rules of the EJB spec carefully, espeically the restrictions. In the quote you listed it is clearly indicated that listen, accept, and multicast operations are not allowed. If sockets were not permitted all together, the spec would say that.

  5. An enterprise bean is allowed to open a connection to a

    >remote host.

    I agree.

    >That is what's required in order to make a web-service

    Not only! You actually need to be able to perform the 3 following steps:

    (a) open the connection
    (b) write the request to the socket
    (c) read the reply from the socket

    As I read it from the spec, (a) and (b) are ok, but (c) is not as far as it falls under the "don't listen on a socket" restriction.

    > If sockets were not permitted all together, the spec
    > would say that.

    As you can read, it's not my point. My concern is about the (c) operation...
  6. Bertrand,

    The spec. is referring to ServerSockets. The spirit of the rule is that bean code should avoid doing any operations that may block execution for a long period of time. If a bean ties up threads, this can prevent your application server from running properly. In addition, it is the application server's responsibility to accept/listen for client requests, not the bean's. If your bean accepts client requests, the application server can not properly manage their resources, do security checks, manage Tx's, etc.

    It is perfectly valid however for a bean to use a socket in the client sense.

  7. "read" is not the same as "listen". There would be no sense in allowing a bean to write to a socket, but not read a reply from it. I doubt there exists a single protocol, let alone a usefull one, where no reply is given back to the client. It is not the intent of the spec to rule out beans as network client. Rather, it is to assure that beans do not "clash" with one another if the container choses to load multiple instances of the same bean, to keep the beans reasonably location independent, and to take thread-related issues away from the beans. I think the note following the restriction in the EJB spec makes this pretty clear:
    "The EJB architecture allows an enterprise bean instance to be a network socket client, but it does not allow it to be a network server. Allowing the instance to become a network server would conflict with the basic function of the enterprise bean-- to serve the EJB clients."

    The meaning of the terms "listen" and "accept" are quite common terminology, but the SocketPermission API may be the source of some sort of normative reference:

  8. Thanks guys, especially to you Gal. I have read many different interpretations of this restriction. However, I think that to take the SocketPermission API terminology to clarify the statement is indeed a very good and convincing idea. Thanks again!
  9. No problem. It's no secret that the EJB spec is ambiguous at best regarding several restrictions. I don't know if the SocketPermission definition of these terms is exactly what the EJB spec means. However, because some of the restrictions are described in terms of security permissions, I think it a good bet. Anyway it's allways good to discuss these issues to make sure there's no ambiguity in the interpretation among the community. Keep it up :)

  10. Gal wrote:

    No problem. It's no secret that the EJB spec is ambiguous at best regarding several restrictions.


    I find it to be pretty unambiguous myself. I guess it depends upon your background. For example, almost anybody who has written any sort of socket code on a Unix platform knows _exactly_ what the expression "listen" means in terms of socket communications. Since BSD sockets are universally renown, I don't think there can be any question as to what the intent of the EJB spec is.

    God bless,
    -Toby Reyelts
  11. Toby,

    In this particular case you're right, and I have said in a prior message that this terminology is quite common, not only for Unix programmers but also in Java socket programming (to witness, it appears in the Java socket API). As for the EJB spec in general, I do find it to be ambiguous at certain parts. One common example that has attracted a lot of debate on TheServerSide is the static's restriction, or the restrictions on thread management. What if you use a library that uses Singletons? What if you use a library that starts up a background thread? Should you dump this library? What if you create a thread and join it before returning, is that unacceptable?
    In general the language that the spec uses is technical, and the percise interpretation of some of the restrictions is not fully explained, rather it should be deduced from the context of the restriction. I think it's generally a good idea to discuss the interpretations of these restrictions in public forums to give novice users a more detailed explanations, and to form one or more main directions endorsed by the community so that App server vendors try to comply to such uses. Of course, ultimately the spec should try and provide a more concrete description of the restriction.