Discussions

News: Turning EJB components into Web Services

  1. Turning EJB components into Web Services (9 messages)

    J2EE 1.4 focused heavily on the world of web services. This article discusses JAX-RPC, and outlines the steps for exposing a stateless session bean as a Web service. It finishes up talking about best practices for exposing EJBs in this way.

    Best practices
    Here are a few best practices for developing an EJB Web service:

    • Avoid overusing Web services in your applications. Examine whether you really need to expose your EJB as a Web service.
    • Use a coarse-grained session façade that encapsulates your business logic to be used as a Web service. Avoid exposing all your application's session beans as Web services.
    • Examine properly whether you need either RPC-style or document-style Web services. RPC-style Web services are more efficient than document-style Web services. On the contrary, document style is more flexible because you can use schema.
    • Make sure you design your Web service so that it creates minimal network traffic.
    • Avoid maintaining any kind of state information in your EJB components that you expose as Web services.
    • Use JAX-RPC data types as the method parameters for your Web service to give it interoperability with heterogeneous Web services. Avoid types such as Collection, HashMap, and Lists as parameters for your Web service if interoperability is important for your application.
    • Many of the conventional best practices for J2EE applications (Web applications) are also relevant to EJB Web services. For example, avoid exposing an EJB component that involves long-running transactions as a Web service.
    • Weigh your security requirements against performance, because security comes with a higher cost. The performance costs of end-to-end security are high.
    Read more: Turn EJB components into Web services
  2. Next up, How to turn your old black and white TV into a fish tropical bowl!

    I'm sure this will find at least one fanatical enthusiast but if I had to pick two of the dullest Java technologies of the post-.com boom these would be them.

    We've got Hibernate, JDO, JMS, ActiveSpaces and JavaSpaces. We've got great Java based technologies but why bore us with yet more EJBs and to make matters worse Web Services.

    Of course, if you life revolves around writing pet-stores then this is probably the article for you, enjoy!

    -John- Zzzzzz
  3. Next up, How to turn your old black and white TV into a fish tropical bowl!I'm sure this will find at least one fanatical enthusiast but if I had to pick two of the dullest Java technologies of the post-.com boom these would be them.We've got Hibernate, JDO, JMS, ActiveSpaces and JavaSpaces. We've got great Java based technologies but why bore us with yet more EJBs and to make matters worse Web Services.Of course, if you life revolves around writing pet-stores then this is probably the article for you, enjoy!-John- Zzzzzz
    Many enterprise implementations still use the EJB philosophy(could be that they have talent that can figure out the so called problems with EJBs the right way).

    JMS is a addon for other enterprise technologies.

    When it comes to boredom with using EJBs; well its the individuals opinion(just like some people like Pulpfiction to the core and some others don't due to their conservative thoughts)
  4. Well, I'm sorry you find EJB's boring, but it seems to me that web services certainly have their advantages in interoperability for loosely coupled system.
     
    And so if web services are part of your design, wrapping the service over a session bean lets you take advantage of the EJB container's ability to easily distribute your service(s), among the other niceties provided by the container.

    So what technologies would you use if the mandate is to implement a highly interoperable, easily distributable module?
  5. There's nothing seminal offered by ejb's in terms of either loose coupling or even ease of use/distribution. Pretty much most (if not every) "enterprise system" (whatever that means nowadays) that I have seen is fairly customized and very specific to the enterprise itself. The _myth_ of "ease of distribution" can not be realized by reinventing component technologies. OO artifacts and thus by extension components, have been reinvented way too many times in the last ten or so years - enough already.

    What's "boring" (though not necessarily unproductive always) is that these broker / proxy / facade patterns have been reimplemented or renamed in so many different yet similar ways, I totally fail to see the value in arguing the benefits of one "approach" over another - same rehash. The interesting thing offered is the complexity in their configurations in which is hidden implicit meta-models. I wish more people would focus on these metamodels, than creating yet another persistence manager or a "radically new" component approach.

    Webservices, for all the "ease of distribution" that they offer are pretty much the same as component based architecture. Their (probable) success lies in the fact that the powerhouses (Sun, M$, IBM etc.) have put their concerted muscle behind them ... and because of the similarity, ejb users have taken to them so easily, there is absolutely NO paradigm shift and hence inertia is maintained.

    Unfortunately, given the experiences from all reinvented + standards driven technologies, these technologies rarely offer anything seminal, other than enforcing interoperaability. This leads to their medium and long term vulnerability to disruptive technologies. Hence, for all the promise and hoopla, I retain my concerns regarding its health and (stunted growth) in the coming years. It can be succesful only if it offers little e.g. SOAP, which essentially defines extremely little in terms of a standard exchange schema. Oh yes then we can call them "lightweight" (fashionable nowadays isn't it?)
  6. Unfortunately, given the experiences from all reinvented + standards driven technologies, these technologies rarely offer anything seminal, other than enforcing interoperaability.
    "other than"? What is that supposed to mean? That interoperability has been around for ages and the whole IT industry was just getting a kick out of inventing XML based transports?
    It can be succesful only if it offers little e.g. SOAP, which essentially defines extremely little in terms of a standard exchange schema. Oh yes then we can call them "lightweight" (fashionable nowadays isn't it?)
    Where did you learn to write posts that are blissfully devoid of any content? Who told you SOAP defines a "standard exchange schema"? Have you heard of the term "payload"?
  7. First off, the point was, there is little in terms of any new models or approaches being offered. As for interoperability, the definition and expectations have changed over the years, and will continue to do so. Yes interoperability has existed in different forms since the beginning. I hope you're not suggesting that because of XML or ejb's "Interoperability" has suddenly descended upon IT. That would be a little presumptuous if not outright juvenile, don't you think? The more abstractions, models and technologies change, the more disparate systems will arise, leading to more interoperability problems, and hence more solutions. My issue was with the same problem being solved by the same solution over and over again - and (this is the key issue) over-reaching claims being made about either interoperability and/or some new paradigm, which isn't the case, and THAT is what is so boring (ref, earlier post). For instance SOAP started out with the promise of an "Object" access protocol, but the fact remains, there is NOTHING Object oriented about it (or even object based - for the purists).
    That interoperability has been around for ages and the whole IT industry was just getting a kick out of inventing XML based transports?
    Pretty much. Yes. You got that right. I have seen XML being used fairly irresponsibly way too many times(e.g. for simple configuration files etc.) It is verbose and highly structured. If you have a braindead simple model, use a braindead simple language/tool.
    Who told you SOAP defines a "standard exchange schema"? Have you heard of the term "payload"?
    Well, a little birdie from W3C forest flew by and whispered it in my ear. Try seeking it out from the primer at: http://www.w3.org/TR/2003/REC-soap12-part0-20030624/

    I have quoted the opening lines for the uninitiated...

    "SOAP Version 1.2 provides the definition of the XML-based information which can be used for exchanging structured and typed information between peers in a decentralized, distributed environment. [SOAP Part1] explains that a SOAP message is formally specified as an XML Infoset [XML Infoset], which provides an abstract description of its contents."

    The specification revolves around, if not entirely based on a schema for exchanging (pretty much) arbitrary information enclosed inside of the envelope ("formal specification implies that a schema exists). So yes, in ANY messaging standard or framework, a standard exchange schema IS required. Yes SOAP may be regarded as an (application level) transport WHICH IS WHY in the first place it can have a payload.

    SOAP and WSDL are useful if used correctly, simply because they're an extension of what existed in other forms (and used to be called "component based architecture") which is fair.
  8. A fun diversion[ Go to top ]

    Much as I enjoy reading the conficting views by people who either use such technologies as Hibernate, JDO, JMS, ActiveSpaces and JavaSpaces above EJB's and vice-versa, I thought the point of this article was to highlight the boons and pitfalls associated with publishing EJB methods as Web Services.

    Now I agree that if I had the time, and my company had the money to sit down and re-architect all our enterprise applications (and our customers were willing to wait for any updates to the products over this period), we might take a look at the alternative technologies as mentioned above. But as we don't we are left with what we ahve and a gradual change process.

    As stated previously, we have to integrate with non-java based systems, over network connections, and the developers in both areas understand SOAP. This makes the development of integration technologies much quicker than if we all too alternative approaches.

    Business needs drive all aspects of commercial software development. We cannot all jump in feet first to every technology we like without looking at cost / benefits. (well thats the world I live in).

    p.s. I thought the article was quite well delivered
  9. A fun diversion[ Go to top ]

    Every technology has its own pros and cons. Its gets adopted in various verticals depending on what it can offer.

    Often we have need to integrate between a .NET and J2EE environment. SOAP is the obvious choice because is simple, "lightweight" (if i may say so) and a standard.

    As mentioned by Ron, business does drives all aspects of commercial development.
  10. There is another issu (apart from the more philosophical ones) which may prove to be a showstopper: If you rely on typed Exceptions to signal business- or system-conditions, you should ensure that all exceptions thrown by the exposed component extend javax.xml.soap.SOAPException. If they do not, the client will have a problem in getting the info you want to convey out of the (de-)serialized Exception (this at least was true for BEA WL generated WebServices using 8 SP 2 with JDK 1.4.2).

    This plus the fact that the data types you should use are (as pointed out in the article) a subset of available Java-types and that any logic that would go with objects taking part in the conversation is obviously lost down the line - plus the nightmare of clients automatically breaking with every interface change unless you do clever things to the SOAP-messages on the way - leads me to strongly suggest you do not directly expose EJB-interfaces. Rather add a wrapping- and delegation layer that decouples the WebService interface from the core app.

    Cheers, Bastian