Discussions

Web tier: servlets, JSP, Web frameworks: Service Data Objects (SDO)

  1. Service Data Objects (SDO) (4 messages)

    I've just begin work on a rich client project. I'm not at liberty to give exact details, so let's pretend the user interface is for managing employee information in a human resources system. This information is not stored in a central location, but is instead made available across many different services. For example, the employee id and name are stored in the HR service, salary and contact info in the payroll service, username and security roles in the security service, and so on. The UI's job is to present all this information to the end user in a unified way - as far as the user perceives, the information is all available in one central location (the UI). It seems to me that what I want is to dynamically create new DTOs at runtime that are a composite of the DTOs returned by these various services. I could then drive my UI off of these new DTOs. So, the HR service might return an Employee DTO, payroll a PaidPerson DTO, and security a User DTO. The composite DTO would contain information from all those DTOs. The hard part is "joining" them and then propagating changes from this dynamic DTO back to the respective services. All this should happen on the client side alone.
    Has anyone else had to solve such a problem? What approach did you use?
    After searching around a bit on the internet, I came across the SDO spec (JSR 235), which seems to be what I'm looking for. Unfortunatly, it's so new that I can't find anything to work with based on it.

      Thanks in advance!
  2. hi,

    One way to solve this problem is to have a DAO which talks with these services which retrieves separate DTOs to a ValueObject Assembler (Session Bean Helper) which assembles Employee, EmployeeDetails, EmployeeRegistration entities. Employee ->EmployeeDetails
    Employee -> EmployeeRegistration
    [DTOs are serializable and dirty markable...]

    Relationships can be modelled in the Aggregate DTO. The choice of storing all the info in one composite is driven by the user interface. Once the user interface modifies the object and sends it back. The updated entities are sent back to the services if required to change.

    To your point, SDO are on the same line. For now, check out :
    Brightside framework
    http://www.bs-factory.org/components/svo.shtml


    Bhagvan K
    http://www.architectcorner.com
  3. I appreciate your response. I thought of doing that, but this UI is very dynamic in that different users will have different "views" of the landscape, so to speak. What would be really nice is to dynamically compose new logical objects at runtime based on the properties of the current user. I looked at the SVO project, but it doesn't seem to offer the dynamic run time composition of objects from various sources. For example, my logical "employee" object might have a salary field that is actually populated from the "PaidEmployee" POJO retrieved from the payroll service, and it might also have a securityRoles field that is actually populated from the User POJO retrieved from the Security system. However, not all users who use the system will see a salary field or a securityRoles field. This new logical object must be dynamic and smart. It must be dynamic in that its fields are determined at runtime and all come from various (different) services, and it must be smart enough to know that if I modify the salary field, it must then call into the payroll system to update the value, but if I add or remove a security roll it must call in to the security system to modify the user's roles. It must also be smart enough to "join" POJOs from various services into a single unified logical object. For it to be effecient, it must also record a history of changes against these new logical objects, and submit them in one batch transaction to all the various services involved. Again, I would much prefer that all of this happen on the client side, as I want to avoid writing new services (that are really just glue). This is why SDO seems like the perfect solution. It appears to be written for this very issue. SVO comes pretty close, but it is more static in nature. It creates/instruments actual POJOs (from a single service at a time) and seems more geared toward addressing the issue of tracking changes to objects, rather than composing objects from various services. If am wrong about this, please let me know (I'd love to be wrong, as SVO is available now and SDO is not). The SVO project claims to solve the same problem as the SDO spec, but I don't think it addresses the issue of composing new objects that are a composite view of many services? This, to me, is the main value of SDO.
  4. One of Patterns and also the goals claimed by SDO spec is SOC, Separation data using from data provision.
    In a real world of muti-tier application, data user or data consumers are across muti-tiers. for example,
    client UI is a data consumer, data are edited and all the changes recorded as changeSummary. then, user submit
    the work. flowing business logic be run on the server side,that may run on another java vm, the data also can be
    edited, and at end of the transaction ,all the changes are submit to data source. it's was said the a DataGraph
    was a unit for transfer data between tiers.however,in my point of view sdo spec dosnt's address this
    issue clearly, how are DataGraph are used in a muti-tier applications, how various of data consumers
    (Client UI, server side business logic components) share a DataGraph to complete a transaction,When we
    transfer a DataGraph from client for server side, the changSummary are transfered or not? In a real world,
    DataGraph may contain many DataObjects, that may cause bad performance. we can also DTOs,but when dto is used
    history information about the DataGraph is lost.
  5. Does anybody has code sample in any opebsource sdo with client and server there are lot of sdo implementations