• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Service-Endpoint Servlet, or directly EJB ?

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

our mission is to design a classic web/servletcontainer + ejbserver + database application.

In order to provide maximum future flexiblity for support of multiple client types, maximum interoperability, I chose to represent all services provided on the EJB container as web services. The "normal" way to do this, is by publishing th web services backed by the ejb�s at servlet-container level.

Now: imagine we want to change web server in the future, and the server doesnt support servlets. It is a
php-based framework, whiclh can only access web services to integrate J2EE
applications. So, now, we have 2 choices: the first solution is to have a
free web server with servet container, and to publish web services with
the servlets. The other choice we have is not to use the free
servlet-enabled web server, but to use web services which are directly
provided by the ejb-container from the start ! What would you say is a better choice ? I think directly using web services from the ejb-container is a better choice from the start. What would you say ? The only I thing I am not sure about is whether Sun has clerly made it a requirement for ejb-containers to support webservices. Have they ? If yes, web services directly provided from the ejb container are the right choice for the most flexible framework !! And in this case, I think XML is the right choice right away, for communication between webserver/servletcontainer and ejb-container.
What would you say ? Would you use XML ? XML is so flexible, we can do the
whole use cases with one XML type of document. If the requirements change,
in the future, we will most likely only have to modify this document, if
at all - because it is very flexible from the start.
I know it is not part of the requirements to think that far, but :
- using this XML approach is simplifying so many things, and even sequence
diagrams, that I want to use it.

Best regards,

Jay
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jay,

I will apologize for the strong disagreement in my response, but the intend is to make you understand the absurdity of such technical solution and not to discourage you in any way. Please keep asking questions and continue learning this very complex and very exigent technology - J2EE.


I think XML is the right choice right away, for communication between webserver/servletcontainer and ejb-container.
What would you say ? Would you use XML ? XML is so flexible, we can do the
whole use cases with one XML type of document. If the requirements change,
in the future, we will most likely only have to modify this document, if
at all - because it is very flexible from the start.


Absolutely not. I have to strongly disagree with you and as a matter of fact this might be considered one of the first J2EE-EJB anti-patterns. If you chose XML for communication between layers then consider this:
  • XML doesn’t provide an OOP approach. Method names + return values + parameter types make OOP.
  • You have to parse the XML inside your methods and this will slow down your application quite a lot. Since J2EE is heavily used for implementing large distributed systems, a solution abusing XML & parsing will over kill that application.
  • You cannot take the advantage of compile time checking. Your input parameters (or return values) are all XML streams and if input parameters are incorrect passed you’ll get that only at run-time.
  • Nevertheless is very ugly! You’ll end up writing a lot of DOM parsing spaghetti code, making your code horrible and hard to maintain. Don’t forget: your application’s lifetime means 20% development & testing and 80% maintenance. People maintaining your code will curse you every day, 5 days a week from 9am to 5pm


  • And I’m pretty sure this list can grow.


    In order to provide maximum future flexiblity for support of multiple client types, maximum interoperability, I chose to represent all services provided on the EJB container as web services. The "normal" way to do this, is by publishing th web services backed by the ejb�s at servlet-container level.


    Did you ever asked:
  • How transaction management will be implemented? How distributed transactions will work?
  • How efficient your clustering will be?
  • How will you secure your application? Can you still provide method level security checking?
  • How much control over the "normal" backed ejbs will your application have?
  • How about entity beans? Will they be web services as well? Would you have as many web services as tables your database has?

  • And again this list can grow as well.
     
    Hug your destiny! And hug this tiny ad:
    a bit of art, as a gift, the permaculture playing cards
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic