Cengiz Kayay

Greenhorn
+ Follow
since Feb 16, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Cengiz Kayay

Hi Thomas,

Thanks for trying to explain it to me. I think about Segments as a logical grouping of flights. So each segment will have one flight. For a flight from London -> Germany -> NewYork has 2 segments and corresponding 2 flights. Segment will hold flight number -say- AB345 and the price.
Itenerary will hold segments of type departure or return.
Customer will pick up flights and the selection will be kept in segments.

I think this piece is the most gray area of this assignment.
I am not suprised that they fired that Business Analyst.

You have been a great help to me.
Regards
Cengiz
Hi

Yes I think you are right about the expectations of SUN for using EJB's in the project. And you might be right about using servlet could be slower due to XML parsing. Accessing a session bean from remote has also considerable overhead but I have not done the comparison in speed and throughput...

In short, We are not doing the most efficent architecture here but we are meeting the requirements with tradeoffs in place.

Thanks for the replies...
Cengiz
Hi all,

I have been reading threads in the forum about the session state storage mechanisms. A common approach is to store state in SFSB's -in ejb tier- (flights reserved, user Id, etc..) and store that beans's handle in web tier.(httpSession).
I would like to bring an other approach and I would like to know your opionions on this..

Instead of storing session in EJB tier I would like to store it web tier.
I think state replication (scability) is better and faster for web containers than ejb containers and storing state in EJB tier results as less scability than storing state in web tier. (Web containers geared better for session replication than EJB container.) I got this notion after reading some books on the issue (J2EE design and programming by Rod Johnson). And It makes sense. EJB is a beast and you do not need it at all for little tasks (fecthing date from db.) If you are using EJB one should have a need for distributed application and some proof of his/her need.

The swing client (whether applet or java application) can store the state on its own memory (on the client machine). I think there is no need to store state on the server for this types of clients. And the swing client can access EJB tier thru a servlet. Messages can be passed as XML documents between the swing client and the servlet.(the only overhead will be XML parsing, etc). Because directly accesing EJB tier will expose our business logic to everbody.And It will introduce firewall issues.

Instead, I would assume using web tier for all types of clients (using servlet) and storing session state on the web tier for web clients. (userId, flight information.) and I would assume to keep session state on the cliet itself for swing clients.

Has anybody any opionions on this.? I want to get to the facts instead of Sun's promotions and marketings.


Cheers

Cengiz
Hi All,

I have some doubts using EJB in the FlyByNight project.
What is the rationale of using EJB here.
An architecture without EJB can be more performant and scalable.
Collacated architectures (web container based- single JVM) can be scaled well and more performant than EJB centric approach.

EJB here can only be good for its declarative transaction management and its capability of transparently handling transactions accros transaction resources behind the scenes.

Making FlyByNight project as a distributed application can be an overkill and over engineering.

Distributed applications can be better scaled when the session state is stoed in the web tier not in the EJB tier. Sun recommends us storing session state in the EJB tier. That makes the scability harder to handle. Cause EJB containers has more overhead then web containers when it comes to state replication.

The only thing I see here to use EJBs in this project is because SUN wants it being used, transaction handling can be done automatically by the EJB container and You do not need to write SQL for CMP beans.

By the way, Swing clients can be handled through a servlet. That way we do not need to open our business objects to outher world through a session bean. Getting browser and swing requests thru the web tier is a better approach and one do not get into firewall issues at all. (calling session bean from a swing client directly will get into firewall issues)


Are these reasons enough for EJB being used even when the perfomance and scability issues suffers...

One last thing, Session beans should be used just to wrap the business logic in POJO's. and Entity beans should be used only to access data sources. Putting business logic into EJB would not make that design maintainable. Say you want to remove EJB's for some reason in the future.If you kept your business logic in POJO's you can do that. But If you used EJB for business logic, you need to rewrite the whole thing in POJOS..

EJB does not make sense to me unless It is used in environment where scability is needed at highest levels, components are scattered around the world and a distributed architecture is needed and the state session is stored in web tier not in EJB tier...

Thanks

Cengiz
Hi Tomas,

I feel certainly like now. But I will not give up.

My whole understanding was:

-Itenerary has segments (1 or many).
-Each segment has flights. (1 or many)

The relationship in the BDM confused me. In BDM it says 1 segment has 1 flight. How do you fit connecting flights (London->Brussels->NewYork) in a segment.Segment should stand for the trip from London to Newyork. And under a segment you should have connecting flights, etcs. Segment should be the structure to organize these connecting flights.

So either the BDM is wrong and I have to correct it OR
I have to find an other way to organize these connecting flights...
If the latter is the way to go, then what the hell is SEGMENT for?

From your answer I got the following conclusions:
When a customer ask a flight from London to NewYork, Flight table returns a bunch of flights. Each flight might have legs. (for connecting flights)
Then Segment is synonym for the Flight. and is used to price the whole flight etc.. The data model for this suggestion would be.

Itenerary - Fligts (1 to many)
Flight - Leg (0 to many)

Segment is a logical construct formed in the OO layer.


Please give this (man) a hand !

Thanks

Cengiz
Hi List,

I know this question has been asked many times But I am really confused after all the readings.
Below is my understanding of the Itenerary-Segment-Flight relationship.
Are they correct???

- Customer searches for flights from London to NewYork.
- System searches all flights (FlightDAO) and returns a bunch of flight objects. Each flight object can have more than one leg. Eg: from London to Brussels and from Brussels to NewYork. (a connecting flight)
IF THAT IS THE CASE THEN, THE LEG IS NOT IN THE BDM ???
- Itenerary has segments and each segment has 1 flight.
- WHAT IS THE REAL PURPOSE OF THE SEGMENT HERE ?
- HOW WE WOULD ORGANIZE DIFFERENT FLIGHTS FOR A DESTINATION UNDER THE ITENERARY AND SEGMENTS.

I am really confused after all these readings. Can anybody please clarify?

Thanks for the answers..
Hi List,

I have some questions and I would appreciate all the answers from guys who passed the test already.
I am preparing for Part II and my assumptions are:

- To integrate with the Frequent Flier Mileage System, I consider to wrap it as a webservice and to access the webservice JAX-RPC could be used ?
- To integrate with the credit card service, I would consider this third-party service already setup their webserver to use XML-RPC and to access it XML-RPC could be used ?
- Do I have to use EntityBeans at all? Cause, the system does not say that the architecture needs to be distributed and it is not currently a complex application. I would like to use DAO with POJO business logic objects instead. I will do the transaction management with JTA in a servlet filter (see: adventure builder architecture)
- I would use a Session EJB (EJB tier) for the swing client to access the business logic thru a business delegate object. The business logic will be in the web tier and it will be shared with the EJB tier.
- I would try to use no session state in the web tier and ejb tier to maximize the scability and failover.
- I want to use Struts framework in this MVC based architecture.(service to Worker pattern)
- In my component diagram, I will show the MVC pattern in the UI tier, Session Bean with the Business Delegate with Session Facade and Service Locator in the EJB tier, Application Service wrapping the business logic in POJO's in web tier, DAO objects for DB access in the Integration tier and POJO's that wrap access to credit card service (XML-RPC) and frequent flier system (JAX-RPC to access the web service, I assume to wrap the existing system as a web service)
- In the component diagram I will also show the modules (Registration, Customer, Payment, etc with their interfaces)
- I will also send a RUP style SAD document additionaly to show the 4+1 view (Logical view, Use case view, Deployment View, Data View, Implementation View)

Are my assumptions OK, so far.?
Anything I have missed ?

Thanks for your all comments.
Regards

Cengiz