XMLValueObjects

Discussions

J2EE patterns: XMLValueObjects

  1. XMLValueObjects (33 messages)

    Instead of creating different kind of Value Object structures, why not use standard XML classes and interface for internal storage or querying value objects?

    Creating a pattern like the XML Envelope pattern (used in SOAP) I saw on the site, and agreeing about a DTD, or the structure of the envelope (what attributes to store or what patterns to use, eg. some kind of version count pattern), we will be able to create a standard way of returning data from a session bean.

    This way code will be less dependent on the implementation of value objects and beans will prepared for soap.

    Threaded Messages (33)

  2. XMLValueObjects[ Go to top ]

    Be careful here. One thing to consider is the over-utilization of XML for internal formats. Remember that there is extra overhead for converting the data from the native format (database)-> to the java representation (Entity Beans) -> to XML -> and either parsing it back to Java OR sending it on to a SOAP interface. Parsing is expensive, and should only be used when you are exposing your Java interfaces to non-Java clients - otherwise why go to the intermediate XML format. It should be done on a case-by-case basis.
    If your "native" code is Java then you should try to remain as "native" as possible for most applications. A layer of indirection solves many problems, but also adds complexity and extra work.
    However, if you are going to use XML, there is not too much reason to develop a generic DTD, as all of your XML value object classes are going to have to have their own XML datatype schema definition, so a generic DTD is not possible.
  3. XMLValueObjects[ Go to top ]

    We use this pattern in publishing systems. The conversion from db to entity bean to xml is only done in a few cases. In most other cases ("read-only" data), a session bean calls a standard class that converts a resultset to xml and has facilities to plug-in data manipulators.

    I don't see this as "less native" than the ValueObject pattern, I just propose another interface for the ValueObject (some requirements: support for hierarchical and/or relational data, support for metadata to be used in frameworks). The org.w3c java interfaces are just as native as any other Java interface? The implementation could even be optimized to minimize memory allocation and network traffic.

    Thanks for the response.
    Michael
  4. XMLValueObjects[ Go to top ]

    Michael,

      do you propose to pass XML as DOM tree, not text?

    Sorry, it is not clear from the previous postings.

    Thanks,
    Andriy Palamarchuk
  5. XMLValueObjects[ Go to top ]

    Yes,
    I propose to pass DOM classes instead of text.
    Most important, I think standard dom interfaces should be used instead of everyone inventing types of ValueObject for different purposes (use in framework, dynamic value object, detail object, aggregation). You could build your own implementation classes that are optimized for storage or transport over a network.

    Most distributed applications that use 3rd party services or provide services (either to applications or browsers) will IMHO use more and more XML for different purposes. So why not prepare your beans for this?
  6. XMLValueObjects[ Go to top ]

    I've been on a project that does what you propose, and have found the naiive approach to XML to be fragile. Schemas evolve, and vanilla DOM doesn't support the notion of "types" (Schema might help with this).

    A better solution would be to use wrappers around the DOM, with type-safe methods (like Castor can generate). Otherwise you end up passing data-only structures that must have DOM-specific processing code on each tier that you want to work with the data (not very OO).
  7. XMLValueObjects[ Go to top ]

    I was wondering if you could pass a java object which had a
    "toXML()" method.
    The route most people would take would be
    database ---> jdbc ---> value objects ---> dom on server
    ---> passed to client.

    database --> jdbc --> value objects with a toXML() method on the server --> java object to client --> xml when required.


  8. XMLValueObjects[ Go to top ]

    I totally agree! We've used Castor's mapping features to create a set of Value objects that we use when communicating between java vms-- if we are "exporting" them, we use castor's mapping framework to marshall and unmarshall them to and from XML. What's nice is that the mapping definitions are declarative, so we can change the value objects or the xml representation without necessitating a change in the other. It also prevents the problem that Mark points out-- DOM code everywhere in the application. Further, since Castor can use SAX, we perform faster than a DOM-based implementation for most documents.....
  9. XMLValueObjects[ Go to top ]

    Michael,
    by passing DOM objects to a client, you will fully depend on the fact that the same XML parser, which is used on the server side, is also installed on the client.
    Additionally, you will have to pass a very large number of objects, because DOM represents every single node of a XML-document as one or more separate objects. All these objects would have to be serialized to transmit them to the client, which will be absolutely more overhead than transmitting just the XML text or "classic" value object.


    Andreas
  10. XMLValueObjects[ Go to top ]

    How safe is it to pass DOM trees over the network?
    May be I'm wrong, but as far as I remember DOM iterfaces are not serializable. So how do you ensure that the implementation is serializable (without providing your own)?
  11. XMLValueObjects[ Go to top ]

    Hi,

    I liked this idea when it comes to passing value objects from java platform to non-java platform. But when it comes to passing an object from java to java platforms, I believe using RMI is a better option due to their compact data representations on wire. One buys performance here. XML is still a non-compact data representation although a very flexible one. I admit that there are ways to compress it but still I am really doubting what is it that I earn by marshalling value objects as XML. Also don't forget for manipulating XML interfaces in Java, you need to convert them to Java objects. That becomes an additional overhead. I believe EJBs are better off by marshalling value objects as Java objects rather than XML interfaces.

    Just "my view of the world"...
    Reema.
  12. XMLValueObjects[ Go to top ]

    In current project I'm using exactly this pattern, but only because it fits our current needs perfectly.

    We need to provide same content with different layout to different clients, so for each client we have one jsp page that we partially fill with dynamic content.
    Request parameter defines which "command" should be executed (which XML should be generated). Dynamic content is provided by ContentGeneratorBean.getContent(command), which in turn creates XML through get...XML() methods of entity beans or some other means.
    XML is finally transformed into HTML/WML through XSL.

    Whole XML stuff is done on simple string level (I find Jakarta ECS very nice for this purpose), so there is no too much overhead on XML creation side. XSL transformation on our production machine usualy takes 15-100 ms, even with pretty big and complex XML and XSL, so the whole thing is pretty performant.

    Without final XSL transformation, I would not even consider using XML as a transport. Even if we put aside performance reasons, there is simply no easy way to marshall/unmarshall your entity beans to/from XML. We should probably wait till Adelard JSR gives some fruit and see what happens then. After we have a nice, standard way to marshall/unmarshall it's going to be pretty easy to benchmark it against simple serialize/deserialize cycle, and everybody will have a clear choice with known pros and cons.
  13. XMLValueObjects[ Go to top ]

    There is a very easy way to marshal your beans to and from XML - and that's to use a code generator.

    And guess what, I have one!

    Jonathan
    http://www.faraway.co.uk/tallsoft/lowroad/
  14. XMLValueObjects[ Go to top ]

    I really have no time now to fully evaluate your product (although feature list looks very promising), so you'll have to correct me if I'm wrong in saying that it cannot do what I need.

    I have entity beans with some cmp and cmr fields. Also I have some internaly calculated fields witch may be _very_ expensive to calculate (some tree walking or invoking sql to calculate some aggregates, etc).
    So, in order not to kill performance, almost every entity bean has several XML representations, containing only those fields needed in given context. As far as I can tell, your tool does not support this.

    I'm aware of several tools that could/should do XML marshalling but they are all alpha or beta 1 or simply unable to do what I need.
  15. XMLValueObjects[ Go to top ]

    Hi Dejan,

    OK, I'll concede my code generator doesn't touch your current requirements. I'll shut up now..... :)

    Jonathan
  16. XMLValueObjects[ Go to top ]

    "This way code will be less dependent on the implementation of value objects and beans will prepared for soap."

    I'm not sure what this really buys you with respect to dependencies. With XML value objects, the code is now dependent on the XML schema. Every time the schema changes, the client-side unmarshalling logic will need to be changed, not unlike a dependency on a Java value object's public methods. There are design principles to minimize the impact of change, but a change is required nonetheless using either Java or XML value objects.

    The real power of XML, in my opinion, is its portability across language barriers.
  17. XMLValueObjects[ Go to top ]

    Hi again,

    the value object to xml idea is used often - and as you say its for data feeds or client presentation more often than for internal comms. The LowRoad does this (shameless plug).

    As for the problem of schema updates cascading throughout the system - this is the nature of computer code. The only time I've got round this is by having a version number element at that start of the XML, and the unmarshaller maintains all old versions of the XML reader. It then tries to 'guess' what values to use when it received an old XML stream. This works within minor version upgrades, and a major version upgrade then forces every part of the system to change.

    It actually worked very well.

    Jonathan
  18. XMLValueObjects[ Go to top ]

    On a recent project we created a DOMWrapper object that encapsulates the DOM object implementation. The DOMWrapper is basically all the other component's API into the DOM implementation. As DTDs/Schemas for the DOM implementation change, these changes don't get cascaded through the system. We modify the DOMWrapper to reflect changes to the DTDs/Schemas, preserving encapsulation.

    You can even handle versioning issues in the DOMWrapper (ie need to support multiple versions of the DOM at a single time). A DOMWrapperFactory could aid in producing different versions of the DOMWrapper objects depending on the version.

    -ryan
  19. XMLValueObjects[ Go to top ]

    Why use EJB's at all? They are overly bulky and not very useful. XMLValueObjects??? Why has it come to this? Are you guys brain-dead?

    Why don't you instead cut out the middle man and create the object that you really nead?

    public class SimpleF$#*ingObject implements Serializable {

     //member data

    //Constructor
      public class SimpleF$#&ObjecT(Connection conn, int id)
       throw SQLException
    {
      loadData(conn, id);
    }

    //getters/setters
    }

    Very simple, clean, and realistic. What benefit does it bring you that you are able to look up your bean via JNDI? Nothing but more overhead and high vendor costs for bulky and mostly useless app-servers. Do all of you really have transactions spanning multiple database instances and such? I really doubt it. Go pick up your design-patterns book and tell me in all honesty that you find EJB's to be great stuff..BLehhhh..

    To really know if you've taken it too far, ask yourself one question. Are ther any scenerios in server-side development where one wouldn't need to use EJB's?

    If you can't answer that question, then you have been inflicted with EJBitis, and should seek help as soon as possible. Go quickly and pick up the latest DDJ and lock yourself in your office until it's safe to come out again.

    Jesse
  20. XMLValueObjects[ Go to top ]

    "Very simple, clean, and realistic. What benefit does it bring you that you are able to look up your bean via JNDI?"

    Location transparency and the ability to cluster services for high availability, to name a few. By the way, the example value object is dependent on a database connection. I'd rather have a server-side method populate the value object without the value object (model) having knowledge of where the data came from.

    "Do all of you really have transactions spanning multiple database instances and such?"

    Not multiple databases, but many distributed, transactionally-aware services using the same database (and tables). How would you go about ensuring data integrity?

    "Go pick up your design-patterns book and tell me in all honesty that you find EJB's to be great stuff."

    EJBs embody many powerful design patterns including Proxy, Factory Method, Template Method, etc. What's your point? Let's stick to the technical merits and demerits of the technology.

    Mike

  21. XMLValueObjects[ Go to top ]

    "Location transparency and the ability to cluster services for high availability, to name a few. By the way, the example value object is dependent on a database connection. I'd rather have a server-side method populate the value object without the value object (model) having knowledge of where the data came from. "

    Since when have EJB's given you location transparency and high availability? To find an EJB you must set your JNDI lookup service location. For high availability you must cluster multiple redundant memory/speed pigs together to perform your task. Not to mention the horrible performance losses ensued when using EJB's...

    Jini does all of this better/faster/cheaper. Jini has TRUE location transparency. You discover the service that you want to work on. As far as clustering and redundancy go, simply run multiple services wherever you want, and voila! Jini handles the rest....

    What's wrong with the object knowing where it's data came from? As far as I remember, SQL92 has been standaradized on almost every database in existance. Do you know that SQL was invented to help secretaries access the big bad database back in the day? Are you telling me that secretaries have been performing a task for years that we developers should now be afraid of..Give me a break.

    "Not multiple databases, but many distributed, transactionally-aware services using the same database (and tables). How would you go about ensuring data integrity? "

    Once again.. Use Jini. Transactions are fully supported through the API. As well as the benefit of letting each service decide how to participate in the transaction!

    "EJBs embody many powerful design patterns including Proxy, Factory Method, Template Method, etc. What's your point? Let's stick to the technical merits and demerits of the technology. "

    Just because they "employ" these patterns does not make them overall a good design. EJB strives to solve problems by providing bulky application containers to perform redundant tasks for coders who do not trust each others abilities at designing services.

    The design of the EJB specification has everything to do with the technical merits and demerits of the technology. The entire thing is inherently flawed, so trying to ignore this only covers up what is wrong.

    Take a look at your pattern repository here. Do you see a trend in the patterns being applied? I do. They all strive to fix some wrong encountered with EJB's. Be it Entity beans are too bulky or whatever, they all strive to fix something inherently wrong. Why try? Why not use something else. Just because it comes from Sun does not make it a good technology. I don't care how many books are written about it. Now please, let's here some good arguments in EJB's favor.

    Jesse


  22. XMLValueObjects[ Go to top ]

    "Since when have EJB's given you location transparency and high availability? To find an EJB you must set your JNDI lookup service location."

    From the perspective of the application, the location of the service is transparent, even throughout a cluster. The configuration of the JNDI service is dynamically configurable, meaning it doesn't require a code change.

    "For high availability you must cluster multiple redundant memory/speed pigs together to perform your task. Not to mention the horrible performance losses ensued when using EJB's..."

    Clustering multiple, redundant services is the essence of high availability. The memory and performance requirements of those services and their container is application and application server dependent.

    There's no doubt that EJBs (not unlike any distributed technology) can be designed with severe performance and scalability problems. I'm assuming you've quantified these performance losses for your application.


    "Jini does all of this better/faster/cheaper. Jini has TRUE location transparency. You discover the service that you want to work on. As far as clustering and redundancy go, simply run multiple services wherever you want, and voila! Jini handles the rest...."

    Ah, this is a Jini vs. EJB debate. I agree that the dynamic service discovery metaphor in Jini is more powerful than that provided by the EJB specification. However, JINI is less mature in the areas of persistence, resource pooling, and security. I'd like to see the two technologies leverage their respective advantages in the future. With respect to clustering, I don't see the difference between running multiple JINI services and multiple EJB containers. Your argument is based on the perception that EJB containers are too heavy-handed.


    "What's wrong with the object knowing where it's data came from? As far as I remember, SQL92 has been standaradized on almost every database in existance. Do you know that SQL was invented to help secretaries access the big bad database back in the day? Are you telling me that secretaries have been performing a task for years that we developers should now be afraid of..Give me a break."

    Fear is different than dependence. I'd rather the value object not know how to populate its own state from the database connection to avoid coupling the value object schema from the database schema. Instead, I'd like to use a database access layer that centralizes database access to isolate this dependence. Now we've come full circle to your original suggestion of design patterns study, me thinks.

    "Once again.. Use Jini. Transactions are fully supported through the API. As well as the benefit of letting each service decide how to participate in the transaction!"

    Fully supported in the API maybe, but how many implementations allow me to declare transactional attributes and persistence policies. Again, I believe both technologies have their advantages and disadvantages to be weighed on an application-specific basis. Your suggestion that I use JINI doesn't take into account the requirements I'm trying to meet, and therefore I believe it's technically irresponsible to make such blanket suggestions.

    "Just because they "employ" these patterns does not make them overall a good design. EJB strives to solve problems by providing bulky application containers to perform redundant tasks for coders who do not trust each others abilities at designing services."

    I never argued that employing patterns yielded good designs. You asked me to study design patterns as a measure of the quality of EJBs, and based solely on that facet I believe EJBs hit the mark. I'm not sure what trust has to do with this debate, though I'd argue that the standardization of a component model in general is a worthy goal.

    "Take a look at your pattern repository here. Do you see a trend in the patterns being applied? I do. They all strive to fix some wrong encountered with EJB's. Be it Entity beans are too bulky or whatever, they all strive to fix something inherently wrong."

    They all strive to find common solutions to the difficulty in designing distributed systems in general. I don't disagree that there are shortcomings in the EJB specification, but I believe future technologies will draw on these patterns as a basis for improvement.

    "Why try? Why not use something else. Just because it comes from Sun does not make it a good technology. I don't care how many books are written about it."

    The choice of another technology presumes that there is something better, in a relative sense, for a specific set of application requirements. It's all about weighing the pros and cons and picking the technology that best matches the situation at hand. Where the technology comes from or how many pages are written about it is completely irrelevant, and I made no claims to the contrary.

    "Now please, let's here some good arguments in EJB's favor."

    This is way beyond the scope of the original post about XML value objects, so I'll refrain at this level. If you'd like to kick up a new discussion thread, we could broaden the audience and get a better sampling of case studies for and against EJBs.

    Mike
  23. XMLValueObjects[ Go to top ]

    "From the perspective of the application, the location of the service is transparent, even throughout a cluster. The configuration of the JNDI service is dynamically configurable, meaning it doesn't require a code change."

    Yes, it does require changes. When you change the location of your lookup service, your app has to change to find the new service. Now, that may be through a command-line argument, or some other way, but nonetheless, it is far from dynamic. Jini on the other hand, is truly dynamic and needs no changes whatsoever.

    "Clustering multiple, redundant services is the essence of high availability. The memory and performance requirements of those services and their container is application and application server dependent. "

    Yes you are right in the first line. On the note of the second, the differences a far greater. Jini is free, Jini is faster, Jini let's you explore and do much more than the sandbox of EJB. I challenge you to refute this.

    "...However, JINI is less mature in the areas of persistence, resource pooling, and security. I'd like to see the two technologies leverage their respective advantages in the future. With respect to clustering, I don't see the difference between running multiple JINI services and multiple EJB containers. Your argument is based on the perception that EJB containers are too heavy-handed. "

    Wrong wrong wrong...Jini does not define any behavior regarding persistence(I'm assuming you mean database.) because that is not Jini's job, but the service writers perogative. Jini only defines the contract for "well-behaved" services and discovery protocols. How you communicate with one another is entirely up to you. Of course, Sun's implementation currently uses RMI.

    What do you mean by resource pooling? The only "resources" that Jini has to maintain are leases and proxies. It is up to the service writer to define resources that they need. Although, I guess that you could say RMI tries to manage and re-use its resource of socket connections.

    Security...Already done. You can find the RMI SSL tutorial on Sun's web-site.

    You don't see the difference between running EJB containers and Jini services?? EJB containers being very heavy is not a perception, but a fact. Once again, Jini is FREE, Jini is FASTER, and Jini uses much less memory. I think these differences are rather large. And of course, the largest difference that I rather enjoy is that there is no "sandbox" with which to work in with Jini. There are not startup/shutdown/etc etc etc.. methods to deal with, nor do I need to maintain 4-5 files for each EJB created. Only the remote interface and the actual object.

    The J2EE people took RMI, which was created with Jini, and bastardized and whored it up into this monolithic J2EE ~thing~ that everyone is into now. I'd like nothing better than for the EJB people to stay as far away as possibly from Jini.


    "Fear is different than dependence. I'd rather the value object not know how to populate its own state from the database connection to avoid coupling the value object schema from the database schema. Instead, I'd like to use a database access layer that centralizes database access to isolate this dependence. Now we've come full circle to your original suggestion of design patterns study, me thinks. "

    Hmmm....Well, where else are you going to store your object data? File system? Probably not.. Database? Yes. Unless you are building a magic object box which will hold your data, you are probably wasting CPU cycles worrying about hiding where the data comes from. You ARE going to have to get it sometime aren't you? What better place than the object that uses it? As far as design patterns study, where do you see a flaw in this design? I think your database access layer is an unneeded "middleman" that doesn't do very much for you. (Refactoring book).

    "Your suggestion that I use JINI doesn't take into account the requirements I'm trying to meet, and therefore I believe it's technically irresponsible to make such blanket suggestions. "

    That's a good way to cop out of an argument. No substance here, just fluff.

    "The choice of another technology presumes that there is something better, in a relative sense, for a specific set of application requirements. It's all about weighing the pros and cons and picking the technology that best matches the situation at hand. Where the technology comes from or how many pages are written about it is completely irrelevant, and I made no claims to the contrary. "

    That's exactly the point. There most definitely IS something better then EJB out there for performing distributed computing/enterprise tasks.

    Once again Mike, please provide some solid arguments. All I see here in your post are vague fluffy answers with no real compelling remarks other than "you don't know my requirements". Well then, tell me your application requirements, and I can tell you whether or not Jini would be better. (Which of course it will. :) ).

    "This is way beyond the scope of the original post about XML value objects, so I'll refrain at this level. If you'd like to kick up a new discussion thread, we could broaden the audience and get a better sampling of case studies for and against EJBs. "

    Hmm.. I have no desire to argue amongst the EJB infected anymore, but if you'd like to continue the debate with some real answers, I'd love to reply in another thread.

    Jesse

  24. XMLValueObjects[ Go to top ]

    "Yes, it does require changes. When you change the location of your lookup service, your app has to change to find the new service. Now, that may be through a command-line argument, or some other way, but nonetheless, it is far from dynamic. Jini on the other hand, is truly dynamic and needs no changes whatsoever."

    Except for when the host of the Jini lookup service changes, right? Is this really that different? At any rate, this alone wouldn't be a show-stopped for either technology given my requirements.

    "Jini is free, Jini is faster, Jini let's you explore and do much more than the sandbox of EJB. I challenge you to refute this."

    Refute what? The spec and reference implementation are free. Jini is faster than what? I would need examples of the sandbox of EJB you're referring to that's an inhibiting factor for your application.

    "Wrong wrong wrong...Jini does not define any behavior
    regarding persistence(I'm assuming you mean database.) because that is not Jini's job, but the service writers perogative."

    Agreed, Jini does not define persistence. EJB does define persistence. So, if my requirement is to allow multiple, distributed applications to update the same database table while preserving data integrity, then I *might* chose container-managed persistence, for example. Sure, I could build the transactional and persistence logic into a Jini service. This requirement alone would first lead me to explore an EJB implementation given the goals of the EJB spec. I may try several technologies, even as simple as an RMI server using straight JDBC.

    "What do you mean by resource pooling?"

    Instance pooling of stateless session beans, for example. Is it possible to pool multiple idempotent services in Jini that can be swapped between client requests? This type of scalability isn't necessary for all applications, so its advantages are relative. My requirements include a certain throughput metric that I've been able to achieve with stateless session beans without a lot of trouble.

    "Security...Already done. You can find the RMI SSL tutorial on Sun's web-site."

    SSL is protocol-level security. My application requires role-based security to a method-level granularity. I also want to keep the users and roles decoupled such that method security is pluggable at the role level.

    "Once again, Jini is FREE, Jini is FASTER, and Jini uses much less memory. I think these differences are rather large."

    These are all relative qualities. I could chose to use a free EJB container (e.g. JBoss), employ various performance techniques to increase throughput and response time, and minimize memory by maintaining shallower pools. This is also application server dependent. My speed and memory requirements are being achieved.

    "Hmmm....Well, where else are you going to store your object data? File system? Probably not.. Database? Yes. Unless you are building a magic object box which will hold your data, you are probably wasting CPU cycles worrying about hiding where the data comes from. You ARE going to have to get it sometime aren't you? What better place than the object that uses it? As far as design patterns study, where do you see a flaw in this design? I think your database access layer is an unneeded "middleman" that doesn't do very much for you. (Refactoring book)."

    The data is required to be stored in a relational database, but I don't want my value object dependent on the database table schema. I'd like to evolve the value object independent of the schema to keep clients isolated from these changes. The database access layer provides this insulation in a succinct and maintainable area of the system, and in the case of my application carries its weight. The CPU cycles incurred by having another database-aware layer manufacture these value objects is negligible in my case.

    "That's a good way to cop out of an argument. No substance here, just fluff."

    I think there's plenty of substance here. Vague notions of free, faster, and much less memory seem like fluff to me.

    "Well then, tell me your application requirements, and I can tell you whether or not Jini would be better. (Which of course it will. :) )."

    This is a futile debate if you're just going to claim that Jini will be better regardless of the requirements. Obviously, from your statement above, you're not interested in debating the technologies in good faith. I've offered several of my requirements during this discussion. I'm sure that Jini could meet many (if not all of them), but with both technologies there's a large gap between what the spec allows and what implementations provide.

    "Hmm.. I have no desire to argue amongst the EJB infected anymore, but if you'd like to continue the debate with some real answers, I'd love to reply in another thread."

    Really? Then, why are you involved on this thread? It sounds like you're itching for an argument. You're point has been made quite clearly: Jini is your technology of choice, and EJBs be damned.

    Mike

  25. XMLValueObjects[ Go to top ]

    "Except for when the host of the Jini lookup service changes, right? Is this really that different? At any rate, this alone wouldn't be a show-stopped for either technology given my requirements. "

    Wrong again. Jini can use unicast discovery (as in how JNDI finds lookup services) or multicast discovery. Multicast discovery enables you to find a lookup service anywhere on the network. I can change the IP/DNS of any of the lookup services and my app will always find it without a single change. When building reliable, fault-tolerant enterprise applications elminating any single points of failure becomes a big deal, but your needs may be different.

    "Refute what? The spec and reference implementation are free. Jini is faster than what? I would need examples of the sandbox of EJB you're referring to that's an inhibiting factor for your application. "

    Almost any Jini application, overall, is going to be faster and less of a CPU/Memory pig than most EJB-based applications. It can't help but be. For instance:

    - Instead of the completely brain-dead idea of pooling beans that are already RMI capable, you only get one remote object in RMI. What about "resource-pooling" you ask? Well, Sun's JRMP implementation can handle as many socket-connections as the host platform allows. Yes, it's true, you as the developer would have to worry about threads, but for most real developers, this is not an issue.

    - Jini-based applications have no need to store resource references such as JDBC connections into a JNDI reference pool. (Of course you could if you wanted to.) You are free to do as you like.

    - 3/4 of the services most EJB vendors provide(well, I'm mainly referncing my experiences with Weblogic) are not needed for EJB development, and thus are mainly useless wastes of memory.

    - Are you seeing a trend here? In Jini you can do WHATEVER you want with your services, while in EJB you are comforatably blanketed inside a safe, non-thinking world clearly defined by contracts and interfaces that have to be implemented by your implementations.

    - Jini has the notion of LookupCache's. This enables you to store locally on your client redundant references to remote services, as well as the ability to search and scan those references without having to actually query the LookupServices directly. This has helped me immensely in load-balancing services in my apps.

    - EJB vendors and their developers are stuck in a world where network outages, machine failures, and other anomilies are considered to be "abnormal" and thus aren't addressed. Jini on the other hand, is built and modeled around the fact that nothing on the network is reliable. Thus, you as the programmer are obligated(but not forced) to ensure that your services "play well" within this universe. Therefore, most Jini applications will be far more stable and fault-tolerant than there EJB counterparts. Go read up on it at http://www.javaworld.com/javaworld/jw-04-2001/jw-0413-jiniology.html .

    "Agreed, Jini does not define persistence. EJB does define persistence. So, if my requirement is to allow multiple, distributed applications to update the same database table while preserving data integrity, then I *might* chose container-managed persistence, for example. Sure, I could build the transactional and persistence logic into a Jini service. This requirement alone would first lead me to explore an EJB implementation given the goals of the EJB spec. I may try several technologies, even as simple as an RMI server using straight JDBC."

    Again, another completely brain-dead concept. CMP? What, I should learn a vendor's proprietary SQL-like CMP code just to get around having to write that icky SQL logic? What does this buy you? Non-vendor neutrality? Once again, SQL92 has been standardized on almost every database platform in existance. So how is your DB schema going to "tie" you to a platform?

    "This requirement alone would first lead me to explore an EJB implementation given the goals of the EJB spec. "

    Well of course this would you to this conclusion, because you are obviously a poor developer who has no real experience in the backend. You wouldn't last 2 days in the environment that I work in. If you fu%$@-up in your coding in our environment, people lose their lives, literally. This is what lead us to Jini, our environment had to be nearly fault-tolerant and redundant. When you start getting serious about the code that you write, and truly care about software quality, then perhaps you will find EJB somewhat lacking....

    "Instance pooling of stateless session beans, for example. Is it possible to pool multiple idempotent services in Jini that can be swapped between client requests? This type of scalability isn't necessary for all applications, so its advantages are relative. My requirements include a certain throughput metric that I've been able to achieve with stateless session beans without a lot of trouble. "

    Really? How is this helpfuly? I see it as the opposite. RMI is perfectly capable of handling thousands of simultaneous client requests, all on the same object! Wow, what a concept. Another example of how the J2EE people have tried to bastardize the distributed back-end model. Throwing more objects at a problem does not necessarily make it better. Scalable? How long really have you been programming if you think that this is a scalable model?

    "SSL is protocol-level security. My application requires role-based security to a method-level granularity. I also want to keep the users and roles decoupled such that method security is pluggable at the role level. "

    Your application requires "role-based" security? I hope your application architect has his resume handy. Please help me to understand why you would ever need role-base/method based security? Do you have unknown clients connection to your services asking to use them? I really doubt it...More than likely, you implemented this feature "because it was there". This provides no real "security" whatsoever. Of course, once again, one could implement this feature in Jini, but since most Jini users are more advanced than the typical EJB user, you will probably not find many(if any) implementations out there that implement such an inane security model.

    "These are all relative qualities. I could chose to use a free EJB container (e.g. JBoss), employ various performance techniques to increase throughput and response time, and minimize memory by maintaining shallower pools. This is also application server dependent. My speed and memory requirements are being achieved. "

    Great, good for you. Although, I don't think I would use JBoss for a while. I love open-source and all, but I don't think it's really stable enough at this point for serious mission-critical systems. (Unless of course you are just building a pansy little web-site, which is not really "back-end" work anyways...

    "The data is required to be stored in a relational database, but I don't want my value object dependent on the database table schema. I'd like to evolve the value object independent of the schema to keep clients isolated from these changes. The database access layer provides this insulation in a succinct and maintainable area of the system, and in the case of my application carries its weight. The CPU cycles incurred by having another database-aware layer manufacture these value objects is negligible in my case. "

    But thereing lies the fault in your statement. Your "value" object is dependent on the DB schema already. The member variables do reflect the columns of your table do they not? Well, what do you call that? And how does putting SQL code in the object show clients anything? Are you clients very meek people that run away at the sight of DB connections? Or, perhaps you are working with stupid developers who do not know any better? Either way, public/private/package methods are usually an easy fit for these problems. You do have to update something when you DB schema changes don't you? What happens when you add a new column? You have to update your "value" object and your DB access layer. Why not do it in one spot?


    "This is a futile debate if you're just going to claim that Jini will be better regardless of the requirements. Obviously, from your statement above, you're not interested in debating the technologies in good faith. I've offered several of my requirements during this discussion. I'm sure that Jini could meet many (if not all of them), but with both technologies there's a large gap between what the spec allows and what implementations provide. "

    Yes, you are right, I do think Jini is a better choice than any EJB implementation in existance. I have read your requirements, and have come to find that you "require" things that do not make much sense overall. What were they again?

    - CMP - Afraid to write code.
    - Distributed transactions - Perfectly reasonable, and provided by Jini.
    - "Role-based" method security. - Completely brain-dead concept pulled out of your ass from some EJB book. Probably brings ~no~ benefit you your application at all, but it sure sounds perty :).

    Did I cover all of them? Wow. Those are some pretty hefty requirements. The first and third I have shot down for obvious reasons, mainly that you probably really do not "require" them, but you read about them and like them.

    Jini is not for the timid or meek programmer, this is true. But, once you ~get it~, there is no turning back. (Well, at least no until something better comes along.) If you truly care and demand that your systems be written well and reliably for your deployments, once again Jini was built from the ground up for this purpose. The old model of building monolithic app-servers will soon enough be a thing of the past. You just don't see it yet. A new revolution is brewing up in the Java community around Jini in the enterprise, and you will soon hear more about it. (Some I think at JavaOne, if you are going.)

    Well, good luck Mike. I have argued enough with you know to judge your level of competence and knowledge to know that these discussions are not providing anymore joy for myself. :) Although you are right, I do always enjoy putting down EJB die-hards once in a while when I get the chance.

    bite me

    Jesse

  26. XMLValueObjects[ Go to top ]

    what a cute little bundle of negative energy.
  27. XMLValueObjects[ Go to top ]

    Definitely negatively charged but difficult to tell whether it's an immaturon or the massive ego-on particle. ;-p
  28. XMLValueObjects[ Go to top ]

    This discussion rules.

    Super scaleable architectures WILL gravitate towards loosely coupled protocols, PERIOD. There are very few patterns that REQUIRE synchronization. Even when EJBs don't require synchronization it still happens. RMI and CORBA stubs, etc.

    JMS (or API's to message queues) and JINI will very soon begin to fill the void in the super scaleable space.

    Why? two reasons. Skillsets and brittleness.

    Beginners can get cookin' with both technologies much quicker than EJBs. You almost have to have an Architect skillset just to begin to use EJBs correctly. A beginner can scale JMS or JINI much easier.

    The biggest skillset reason is SOAP. Am I a no MSoft fan. But the fact is Architects will be forced to integrate MSoft into their world and vise versa. We won't even discuss legacy access. XML-RPC, Jini, JMS are not just buzzwords for super scaleable systems.

    Check out the diagram in the new Mastering EJBs.

       http://www.TheServerSide.com/portal?

    See something funny about it? Direct interface with EJB containers is removed altogether!!!!

    Later





  29. XMLValueObjects[ Go to top ]

    Looking at a couple of the replys in this thread I can't help but agree with the arguments against using XML for internal application data structures. It works great for external communication. But one of the benefits of OO programming is that classes should be somewhat self documenting (even plan 'ole value objects). Who cares how easy it is to change a data structure when the system is so opaque that a new developer cannot understand the system.

    XML has become a golden hammer for so many developers (see AntiPatterns) that they do not evaluate the costs involved when using it to develop. I'm not talking about the obvious performace issues (although they can be significant). And I did like the suggestion of a toXML() method for objects. It could sit right beside hashcode() and equals() as a general utility. But the real cost is in the how the readability of an application changes when you replace accept(Bid bidObject) with accept(Document domObject)

    I realize that we make many an object oriented compromise (especially with Java) and I am the first developer to scrap OO techniques when I am striving for performance but we must remember that one of the great characteristics of OO languanges is the ability to give methods, instance references, and classes meaningful names.

    It shouldn't be that big of a project to add some getters and setters on an object when we add a database column. I have seen too many overly-complex architectures defy the comprehension of a new developer to want to hide data inside XML.

    Let's not sacrifice clarity to the God of flexibility!

    Gregory D. Dickson
  30. XMLValueObjects[ Go to top ]

    A useful thing about XML and ValueObject is in defining an XML Schema for each ValueObject. Using a tool like Castor or another java binding generator (or JAXB), you can constraint the data directly from a schema instead of overloading your code with complex regexp, range validation, ...

    A ValueObject can extend such XML objects or use them as aggregate (I do prefer this solution). An easy way to check data constraint on the client side and avoiding a round-trip with the Container.
  31. XMLValueObjects[ Go to top ]

    Jesse

    Haven't you gotten sick of your little tirade on the Replace EJB bloat with Jini Pattern discussion yet?
    Do you really expect anybody to listen to you when all you seem to do is throw insults around? You moght be a 100% right but I'll never listen to anything you have to say.
    I means who needs religion when we can all be jini fanatics.
    Jeff Anderson
  32. XMLValueObjects[ Go to top ]

    Well boo hoo Jeff... I'll try and get by without your approval.

    Jesse
  33. XMLValueObjects[ Go to top ]

    Jesse
    My opinion has nothing to do with it. You seem pretty evangelical about jini tech and want to spread the word around to all the other developers in the java community. All the insults and remarks about other developers are pretty counter productive to this purpose. If your goal is to spread the word on jini then you might want to try a different tack, you will be suprised that you might get alot more people seeing things your way. You seem to have some technically intelligent things to say, why hide it behind snide remarks and put downs?
    Jeff Anderson
  34. XMLValueObjects[ Go to top ]

    We have a system taht uses a MAcroMedia flash client talking over HTTP to a servlet and then to Facade Session EJB. You guessed it we use XML to facilitate the movement of the data in a bi-directional manner. However we put the conversion right at the (nearly) last minute, in the specialised Facade object.

    We did build proof-of-concept programs in Visual Basic for embedding into MS Office Programs like Outlook so that calendar and task information can be shared with interfaces that users are well used to.

    For the 'admin client' which configures the whole system and is meant to be run inside the firewall, it is built on Java we used plain old value objects over RMI/IIOP which talk to a different facade object.

    The good thing about the XML is it allows us to have language independent client programs which can operate over HTTP .. it's not SOAP/WSL but sort-of, which suits us fine as we don't need this micro-service architecture but fully end-toend comms between a client and the middle tier and back end. The _bad_ thing about this XML is that it is much more costly in both computer resources and expensive programmer time to marshall and unmarshall the XML to/from Java and the native object system of the target client.

    The admin client can get new features much much faster than the others because it's end-to-end Java.

    But, the ability to use something like Flash to build a nice-looing rich client interface that runs in a browser, as well business advantages of saying 'Yes we can support your MS-Office programs' is a real big bonus that outweighs the disadvantage.

    regs
    scot.