Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Patterns for communication applications

 
mik kenstr�m
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I'm starting to study design patterns throughout using books like
Head First Design Patterns and Applied Java Patterns.

I'm especially interested in communications software and what kind of patterns that kind of software use. JMS and Web Services have their own mechanics how yo use them but how about RMI and Socket based applications?

Does anyone of you know that what patters should be used e.g. making
a RMI or Socket based server? If using sockets should I also make e.g. messageclasses to be used in server and client side etc. If using GUI maybe
communication should be started from GUI with Command pattern ...

Where should I start? Any conrete samples or documentation available?

I remembered that in year 95 - 97 there was a design patters book considering this kind of issues and samples were build with C++.

Any hints how to start?

Cheers

Mikke
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Services like RMI are already an implementation of a pattern; it�s an interface that hides distribution code from a specific implementation, if my memory serves me well. When I was doing my Java Developers Certificate I made the mistake of creating an interface on top of RMI to hide RMI implementation away from the client.

An interface on top of an interface often happens with bad OOP design. Many developers often try to hide SQL specific code by creating an interface. But SQL is already a pretty fine interface already; you don�t want to duplicate in the OOP code what the SQL server alread does because the interface become the bottleneck that only caters for the lowest common denominator.

If you want to do GUI using MVC, maybe there are already frameworks that already implement the pattern, and only require you to use metadata to create the GUI widgets.
 
mik kenstr�m
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okey, maybe RMI is not a good example but how about own text based protocol
which uses TCPIP carrying messages?

I'm thinking hard that how to build a design pattern based solution for this kind of software. 90's there where quite many C/C++ based frameworks like
these.

Now it's difficult find such using Google especially those made with Java.

So, if anyone have any references I would be very grateful to have them.

Cheers,

Mikke
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by mik kenstr�m:
I'm thinking hard that how to build a design pattern based solution for this kind of software.


What are you trying to gain from basing the solution on design patterns?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gerald Davis:
Many developers often try to hide SQL specific code by creating an interface. But SQL is already a pretty fine interface already; you don�t want to duplicate in the OOP code what the SQL server alread does because the interface become the bottleneck that only caters for the lowest common denominator.


My experience is quite different: for anything but the simplest system, the needed SQL differs enough between different vendors that abstracting away from it pays back manifold.

It also allows you to use other persistence mechanism than RDBMS' - which can be quite interesting for systems that are supposed to live longer than a couple of years and might be used in environments you couldn't anticipate from the beginning.


If you want to do GUI using MVC, maybe there are already frameworks that already implement the pattern, and only require you to use metadata to create the GUI widgets.


https://binding.dev.java.net/ seems to be quite usefull.
 
Gerald Davis
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I should have known better myself; I guess that I cannot argue with you then. I wonder if there is a small layer of code abstraction for each vender that would standardise SQL.

Originally posted by Ilja Preuss:

SQL differs enough between different vendors that abstracting away from it pays back manifold.


I am sure what precisely what you mean
 
mik kenstr�m
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
quote riginally posted by mik kenstr�m:
I'm thinking hard that how to build a design pattern based solution for this kind of software.



quote:What are you trying to gain from basing the solution on design patterns?
A lot. OOP based language gives a more elegant and better way to maintain
your Framework or what ever your are building.

Why do you ask this? I thing it's quite clear fact you too. But don't want
to talk about it more.

Maybe it's easier way to get source code for e.g. one of Jakarta's projects
and see what patterns they use in different places and how.

Prost!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by mik kenstr�m:
OOP based language gives a more elegant and better way to maintain
your Framework or what ever your are building.


Ah, yes - OOP is a powerful tool. OOP != Design Patterns, though.


Why do you ask this?


Because you can have a good OO design without thinking much about patterns, and concentrating too much on patterns actually can lead to an overcomplicated design.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Messaging patterns there are. (Hmmm, looking forward to the next Star Wars movie I am.) My little Messaging Patterns page has some thoughts I used to organize some issues at work, and a link to Enterprise Integration Patterns which is much more rigorous and complete.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic