Transfer Objects in EJB 3.0

Hello,
I am building Enterprise application with EJB 3.0 and JSF. In many J2EE books there's that Trasfer Object pattern ( sometimes called Value Object or so), I just wonder what are your experiences in using TO in Java EE ( EJB 3.0).
Because entity beans in EJB 3.0 are POJOs I think that there is no need to
use TO pattern.
Im my app I receive entity from session bean and bind that entity to JSF components. This is the easisest solution for me because I don't build boring
transfer object, and don't have to wory about transformation between TO and Entity beans. Am I doing right or I am maybe missing something??
By reading EJB 3.0 spec. when session bean returns entity it becomes
detached so its just plain java object. ??
I know that using TO you can reduce coupling between client and EJB but
you must implement additional level with TO objects and transformations, so
it looks to me that by using TO you just get more complexity and problems ?
Tell me what are your thoughts and experiences.
Regards,
Niksa Jakovljevic
FOS

Hi Niksa,
Your intuition about EJB 3.0 is correct. One of the advantages of Java Persistence API entities
is that they can be passed directly to clients without having to convert their data to separate transfer
objects. The reason this was a common pattern in EJB 2.x and earlier is that CMP 2.x beans are 1st
class EJB components that are limited in their ability to be used outside of the ejb tier.
--ken

Similar Messages

Error while Transfer Object

Hi,
I have a Data-Transfer-Object which is transfered between a client and an EJB. While this transfer I get this exception:
java.rmi.MarshalException: CORBA MARSHAL 1398079699 Maybe; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization UIDs : Source (Rep. IDRMI:com.tsystems.ik.to.BANFTO:0000000000000000) = 0000000000000000 whereas Target (Rep. ID RMI:com.tsystems.ik.to.BANFTO:5F16928AAE9F82C6:70F941F18AA0F040) = 70F941F18AA0F040 vmcid: SUN minor code: 211 completed: Maybe
Any ideas, where the error is?
My DTO:
import java.io.Serializable;
public class BANFTO implements Serializable {
private String number;
private String name;
public BANFTO (){}
public String getName() {
return name;
public void setName(String name) {
this.name = name;
public String getNumber() {
return number;
public void setNumber(String number) {
this.number = number;

I had the same problem.
I deleted automatically generated deployment and RMIC code, did a rebuild all projects, deployed on server, restarted server and it just worked out.

Data Transfer Object Class

HI, i'm new with the web dynpro, so i been told to use java web dynpro using the Data Transfer Object, with a conection to Oracle.
anybody has information about the web dynpro using Data Transfer Object.
thanks in advance!!

Hi,
Their are lot of articles on the same here, please search for java bean models. Will give some hints
I guess what you are planning to do is
DB--> EJB/POJO--
> Webdynpro
Regards
Ayyapparaj

How to combine Session Facade and Transfer object?

Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
Thank you!
Astghik

Astghik wrote:
Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
I would simply recommend establishing a service tier. Your services should be stateless. You can go the extra mile and have a session facade, but in the majority of cases, coding to an interface for your service accomplishes the same goals.
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
The idea of the transfer object is very similar to the Command pattern. I think if you investigate that pattern, it will be more obvious. The transfer object reduces network latency by consolidating all the parameters into an object, ideally, this also consolidates multiple method calls. If you combine a transfer object (or command object) with a service tier, you get the best of both worlds. The service can delegate calls to helper objects (or other services or components) using the data in the transfer / command object.
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
The is your domain. It will vary from application to application. The principles above are more general (e.g., patterns and architectural tiers) and should apply to most domains. However, your actual use case may require something different.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Consider using something like iBatis or Spring's JDBC templating to make your life easier with JDBC.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
Versioning is a separate issue. Generally, the more coarsely grained your transfer / command object is, the more changes are likely to impact dependent objects.
Your command or transfer object does not have to be a vanilla JavaBean, where you are basically creating a bean that has data from other objects. You can simply use your command / transfer object to encapsulate already existing domain objects. I see no need to map to a JavaBean with what you have described.
Generally, a method signature should be understandable. This means that many times it is better to pass the method, say, two coarsely grained objects than a signature with a dozen primitives. There are no hard and fast rules here. If you find a method signature getting large, consider a transfer / command object. If you want one service to delegate calls to a number of other services, you can also create a transfer / command object to furnish the controlling service with the data it needs to invoke the dependent services.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
This is a large, open-ended question. If you are going to display it to a user on a screen, I do not see how you avoid a network transfer with the data. The general answer is to not pass the data itself but rather a token (such as a primary key, or a primary key and a start and stop range such as you see on a Google search result). You do want to limit the data over the network, but this comes at a cost. Usually, the database will receive additional load. Once that becomes unacceptable, you might start putting things into session. Then you worry about memory concerns, etc. There is no silver bullet to the problem. It depends on what issues you are trying to address and what trade-offs are acceptable in your environment.
Thank you!
AstghikBest of luck.
- Saish

Passing object to EJB

Hi, I had a serializable data transfer object and i tried to pass into my session bean such as
public java.util.List retrieveCaseData(CASBasicDTO caseBasicDTO) throws Exception and i have this
error : java.lang.ClassCastException
It is very wierd. I tried to declare a new DTO inside my EJB, it works,but it give me an error when i try to pass in and out the DTO object. I half suspect is something to do with the RMI stuffs, but I don't know how to go about it to solve this problem.
Your advise is greatly appreciated. Thanks a lot!! :)

Do not hard-code the serial ID into your Objects - since you're dealing with remote calls, it's absolutely critical that the Objects on each side of the remote invocation be the exact same "version" of the Object. If they're not the same, you can/will get a marshalling-type exception, not a ClassCastException.

Questions on scripts, tables & transfer objects between clients.

1. In script, how to use the same print program for two different layouts? with procedure.!
2. Why cant sapscripts be client independent.?
3. Want to maintain a table in dev server and if i update the data, it should simultanously update in Quality and Production servers. How? please explain in details.
4. How to transfer object between clients.? explain.
Points will be promptly rewarded for HELPFULL answers.!

Hi!
3. With SE01, you can create a transport request for all table entries.
SE01 - Create button - Workbench request - Give description and save
Select the created request and click on Display object list.
Click on Display - Change button
Insert line button
ProgID: R3TR
Object: TABU
Object name: Z_YOUR_TABLE
Double click on the table name
Insert line
Key: *
Save everything
Release the transport in SE10 transaction and transport with STMS transaction.
Regards
Tamá

Transfer Object in JSF, Spring, and Hibernate

The application on which I am working deploys the JavaServer Faces, Spring and Hibernate frameworks.
We are going to use the "transfer object" to move data between J2EE tiers from the front end to the back end and vice versa. In addition, data "types" may need to be converted --
At the front end, the "type" of the data that are entered by users may not match that in the database table. For example, checkboxes may be marked or left blank by users. The "type" of the checkboxes is "boolean" in the JSF backing bean. However, we have either "Y" or "N" for the corresponding field in the database table.
The JSF backing bean holds data as well as controller functionality. Of course, the transfer object holds data only.
With regard to class properties, Is the transfer object an exact copy of the JSF backing bean? And at which tier the data are converted to match their correspoding "types" in the database tables?
We also have the "data objects" which are exact representation of database tables.
Thanks for your advices.

Small example: you can decide in the business layer
whether to convert it to boolean or Boolean (which
has a 3rd state: null).But it all goes back to your data model. If your data model supports null for that property, then of course boolean is a poor choice. If that case one could use Boolean. None of this has anything to do with re-usability, which was your objection.
I think the re-usability question goes back to the data model as well. Suppose your data model says this property is boolean valued. However if your database does not support booleans natively, then you need to map the value for storage in the database. But that is the data persistence layers problem.
OTOH, suppose your data model says that this property may be 'Y' or 'N'. Then the Java class represent the business object should not have a boolean property, we should make it match the data model.
However, I think that most cases where people are storing 'Y' or 'N' in a field in the database fall into the first case, where the data model is a boolean and they are working around limitations in the database. There is no reason in that case to perpetuate the same limitations in the Java code.

Default values of columns not transferred in SSIS Transfer Objects Task

I am working on a project that is creating a new application, my area of the project being the migration of data from the old application database, transforming it, and populating the new database.
The transformations to the old data are done in a staging database.
At the end of the process, the staging database ends up with a lot of new applications tables, populated with the migrated legacy data.
We need to move these tables from the staging database to (initially) our test databases, but ultimately what will be the live database.
We have tried using the "Transfer SQL Server Objects Task" in SSIS, but have ran into a problem that a lot of the database tables have default values for columns.
These default values are not brought over.
Example. Tables contain a "GUID" field, which has a default of value of newid()
Right clicking and the table generating the CREATE script generates
[GUID] [uniqueidentifier] ROWGUIDCOL NOT NULL CONSTRAINT [DF_tbCRM_Client_GUID] DEFAULT (newid()),
However, the Transfer objects task does not create this default of newid()
Examining the SQL generated by the Import / Export Wizard when investigating this shows that the wizard generates this column as
[GUID] uniqueidentifier NOT NULL
and the column default value is lost.
Is there something i should be setting somewhere to force SSIS to bring these column definitions over correctly?

Kaarthik Sivashanmugam wrote:
This behavior is by design to maintain backward compatibility with the Copy SQL Server Objects task in SQL Server 2000. Only two constraints (Primary key and foreign key constraints) are expected to be copied by Transfer Objects task.
thank you for you response Sivashanmugam.
How can I move these tables (of which there are over a hundred) from my staging database into the application database - and keep the table definitions correct?
I cannot use the transfer objects task, as this will not define the tables correctly.
I cannot use the import and export wizard, as this will also not define the tables correctly.
This means I will manually have to code the drop, create and inserts for over a hundred tables?

Transfer Object Pattern and Concurrency Transaction Mgmt

I am developing an application that implements a remote rich client. For
performance reasons I have chosen to use the Transfer Object pattern. I
have been very successful with this from a performance standpoint, it
really paid off. I am using it in combination with an assembler pattern
to construct Transfer Objects for the view and to also reassemble domain
objects based on changes made to transfer objects on my client side.
Anyways the only problem I am having with it is I can't seem to figure
out how I should implement optimistic locking with it. Is there a best
practices to handle transaction control here?
I generally try to keep visibility of stale data down, but there are still
situations where concurrent clients could have requested to edit the same
the Transfer Object at the same time. I would ideally like to handle this
using a flavor of optimistic locking. I in fact have implemented
optimistic locking on the domain side, but now I am not sure how or if I
should integrate this into the Transfer Object or View side. The version
field used in optimistic locking is generally a hidden field. The only
way I can see to handle this with the view side is to expose this field on
the Domain Objects and actually store it into assembeled transfer objects.
This seems like it may be a bad idea from a design standpoint.
The problem is the client requests data and it assembled and delivered to the client. Then at some later time the client may send a request to the server to update this data. At this time a new transaction must be started where the server reloads the domain data and copies over the requested changes. Since the domain data was just loaded you wouldn't ever trigger a versioning problem unless the version was maintained on the transfer object and copied over as well. I am developing this project with hibernate on the back end and unfortunately hibernate doesn't acknowledge manual changes to the version field.
I just feel like there must be a better way to do this. I believe that using the Transfer Object or DTO pattern for remote client/server architectures is pretty common. So there must be a best practice to deal with concurrency? Suggestions, insight, lay it on me please.
thx

I personal respect both concepts and am using both in an application I am currently work.
Firstly, I have my Transfer Object which I call xxxData.
Next, the entities are called xxx
I have my DAO classes that handles all CRUD operation. but within the DAO class I have two methods
private <EntityClass> retrieveEntityFromObject(<EntityClassData> data) {}
private <EntityClassData> retrieveEntityFromObject(<EntityClass> entity) {}so with these methods, I separate my business logic from my data layer. My codes will alway use data objects instead of entities. For example, a create method will be
public ProductData createProduct(ProductData data)
entity.persist(retrieveEntityFromObject(data));
}I hope someone understands
Regards

Static methods in Transfer Objects

Hi all,
I have a doubt about Transfer Object:
Is it possible to have a static method (or field)
inside a Transfer Object returned from
a Session Bean to a Client ?
Many thanks in advance,
Moreno

Static fields, yeah, they'd cause some interesting problems, so are not a good idea in TOs. You can do it, but YMMV (Your Mileage May Vary).
Static method? I'd get rid of it and put it in a utility class or somewhere else. Static methods are pretty meaningless when applied to TOs. The idea is to encapsulate data and some behavior - not provide procedural functionality.

ABAP Objects and EJB

Hi every one,
Can <b>ABAP Objects and EJB</b> be compared?
-Naveen.

Hi Naveen,
Check this guide- might be useful-
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/dc09af90-0201-0010-d09b-bd611a11070b
Regards,
Moorthy

Business Objects(BOs) & Data Transfer Objects(DTOs)-both needed ?

In a J2EE system...
I know that "Business Objects" (BOs) are basically value objects (VOs) ...lots of getters and setters and some business logic. These are basically to model nouns in the system. Eg Student BO.
I know that "Data Transfer Objects" (DTOs) are value objects (VOs)....with getters and setters... with the purpose of avoiding multiple method calls...to avoid overhead...which effects performance. eg it's better to pass a Student DTO then say...pass the student ID and student name and student age etc etc.
Main question : Should a system have both ? If yes, why do I need a StudentBO.java and then another StudentDTO.java....when they are so similar ?...when both are basically VOs ? Can't I just use BOs to serve as DTOs ?
Thanks.

Hi,
I've started using BO's and DTO's since 3 months .With my experiece i understand we nned both of them.
The BusinessObject represents the data client. It is the object that requires access to the data source to obtain and store data.
DTO
This represents a Transfer Object used as a data carrier. The DataAccessObject may use a Transfer Object to return data to the client. The DataAccessObject may also receive the data from the client in a Transfer Object to update the data in the data source.
From this i want to tell you that We are not gonna do any operation on BO's but we do operations on DTO
Ashwin

Objects of EJB in flex

Hello.
i want know if is possible that i can use Java Objects in my flex application using Blaze-Ds.
I have all my business logic in Objects inside EJBs. Then, i need use it in a new flex application. I was read that i can do it, but i don't know how.
Thanks
Danilo
Santa Marta - Colombia

Hi there,
Shortly put: Flex Builder is not Dreamweaver and nor are the Flex applications like HTML web pages. You can't creat any templates with wizzards or whatsoever, especially because Flex isn't really used to create web sites but rich internet applications ( although a web site might fall into this category, the two are still quite different Worlds ). So, the most you can do is either to develop a skeleton web site that you can fill with components later on ( which in my opinion is just a waste of time ) or create many little and standalone components that you can reuse in each project ( and also in projects that might not have anything to do with web sites ).
If you are looking to create templates that you might have gotten used to in Dreamweaver ( or other softwares like DW ), then I think that nor Flash or Flex are the technologies for you ( especially not then if you are thinking of templates the same way when using these technologies as if you were using Dreamweaver/HTML templates ). Flex 4 did introduce "templates" but those templates do not really fall into this "website templates" category either ( if you want to read up on the what Flex 4 templates are then visit this page: http://livedocs.adobe.com/flex/gumbo/html/duplicate_1_WS52085436-ABD3-4d4d-B5E2-41C668CF68 47.html ).
With best regards,
Barna Biro

Simple Question - Data Transfer Object

Hey gurus,
I like the option in JBuilder to automatically create Data Transfer Objects and an Assembler for it. But what? I used to make the assembler a Session Bean, and JBuilder makes it a normal Java class with static methods. I know JBuilder always ships with the best solutions, but...
what is the advantage of the static class here? And in my case, i have the session beans and the entity beans deployed on a different server, would that make a difference for the advantage?
greets,
Nick.

Hey gurus,
I like the option in JBuilder to automatically create
Data Transfer Objects and an Assembler for it. But
what? I used to make the assembler a Session Bean,
and JBuilder makes it a normal Java class with static
methods. I know JBuilder always ships with the best
solutions, but...
well....... not always
:-)

Data Transfer Objects

Is it safe to assume that Data Transfer Objects should be populated by Business Objects that are local to entity beans or whatever is being used to populate them?

jschell wrote:
ttb999 wrote:
jschell wrote:
So if the point of DTOs is to reduce network traffic, why would you initially populate them using a remote object? That doesn't have anything to do with what I said.Well that was the jist of my question.Your statement has a historical perspective which probably doesn't mean much in current DTO usage.
Originally RMI was promoted as a a 'method' interface. As such you would have had the equivalent of a DTO with setter/getter for each attribute. Each setter/getter would invoke a remote procedure call to the server.
Thus a data object with 5 attributes would cause 5 network calls to 'populate' the attributes.
That was vastly inefficient.
Consequently the first DTO type (which was not called a DTO) was promoted as a way to avoid that.
If you want you can look up "Remote Procedure Call" (RPC) which would have been the origin of where the 'method' idiom originated.And quite apart from performance, populating a local object from the remote prevents disruption of the local data in case the network connection is (temporarilly) lost.

Transfer Objects in EJB 3.0

Similar Messages

Maybe you are looking for