I'm just getting into how to write a good architecture of a good software
system, and I'm learning how to separate high level components into Layers.
In this case, I'm trying to use Tiers, so as to model each Layer as a black
box.
There are 4 tiers in my architecture: Presentation, Application Services,
Business Logic, and Domain/Persistence. For the purposes of my question,
we really only need to focus on the Presentation and Application Services.
The Application Services Layer will contain a Service that allows tracking
of a certain event. The Presentation will have several views that should
update dynamically as the tracking model of the events change. Inherently,
it seems that I need a one-way change-propagation mechanism.
Since I'm trying to model these Layers as Tiers, I'd like to restrict communication
between Facade objects for each Tier, and when necessary, allow a Tier
to aggregate an object from one Tier lower, though only known by interface.
I'm programming this application in Java, so the obvious thing to use is
Observable/Observer. However, I don't like that the update method for the
Observer interface forces you to cast object arguments. I want to work around
this by defining my own interface and class for this mechanism. The problem,
then, is that the Application Logic will depend on an interface from the Presentation
Tier, a certain no-no for this architecture. Is this a sign that I should try
modeling with MVC fore-most and Layer the Model? Or would it be a better idea to
model each of the views with an interface known in the Application Services Layer.
It seems like a bad place to put it, and I'm stuck. Also, I'm using the View-Handler design pattern to handle the multiple views.
Observer/Observable is often not the best approach, especially in Java where you have to derive from Observable thus wasting your single inheritance. It also, as you discuss, causes coupling which is bad when it crosses tiers.
I would be more inclined to investigate a pure Event model, with the services providing a way to register EventListeners and firing, perhaps, a PropertyChangeEvent when the change occurs.
The Services layer could then be notifying other services, or notifying the Presentation layer -- it doesn't know and doesn't care, and only the presentation is coupled to the service by way of registering as a listener.
It seems to me that your question is less about Publish/Subscribe than it is how to get the layers to communicate.
Short answer:
Use MVC/MVP. Look up blog posts about them, download source code, and remember: if all you have is a hammer, everything looks like a nail. Meaning don't apply patterns because you have them, apply them because you need them.
Long answer:
If you're working in Java, I suggest Head First Design Patterns which will get you oriented to the way of thinking in patterns. After you have your head around design patterns, which I think you're on your way to now, you can look at Patterns of Enterprise Application Architecture. Feel free to skip Head First, but it is a very good book that I highly recommend if you're getting into architecture.
Once you've digested the Fowler book, or at least have a basic understanding of N-Tiered Enterprise Architecture, you should be well on your way.
Related
Our company has purchased a SDK that can be used for Android apps. The SDK is written in java and its very big.
I have to create a wrapper for this SDK so our partners doesn't need to directly use the SDK, but call our wapper functions instead.
I am wondering what is the best design pattern for doing a job like this? I am have been looking at the proxy design pattern, but not sure if this is the correct one.
Many thanks for any suggestions,
The one that comes to mind is the Facade pattern.
From the Wikipedia description:
A facade is an object that provides a simplified interface to a larger
body of code, such as a class library.
The facade pattern is one of the original design patterns that was described in the GoF book. There the description reads:
Provide a unified interface to a set of interfaces in a subsystem.
Facade defines a higher-level interface that makes the subsystem
easier to use.
Seems to fit your use case perfectly.
This sounds like the classic case for the facade pattern. You want to design an API for your partners that captures your high-level use cases. The implementation would delegate to this purchased SDK, but without allowing its implementation details to propagate up to your partner's code.
http://en.wikipedia.org/wiki/Facade_pattern
The proxy pattern looks less relevant to this problem. Proxy tends to be a one-for-one mapping to the wrapped API just for infrastructure requirements. The classic example is remote method invocation.
http://en.wikipedia.org/wiki/Proxy_pattern
The Facade pattern sounds like the most appropriate one.
However, choosing the best design pattern is not a guarantee of success. Whether you will succeed really depends on the nature of the SDK that you are attempting to "wrap", and what you are really trying to achieve by wrapping it.
For example, in a past project I made the mistake of using facade-like wrappers to abstract over two different triple-store APIs. I wanted to have the freedom to switch triple-store implementations. It was a bad idea. I essentially ended up mirroring a large subset of the API functionality in the facade. It was a major implementation effort, and the end result was no simpler. In hindsight, it was simply not worth it.
In summary:
If you can make your facade API small and simple, this is a good idea. (The ideal facade is one that simply hides a whole bunch of complexity or configurability that you don't want the clients to use.)
If your facade is large and complicated, and/or entails complicated "mapping" to the actual APIs you are wrapping, you are liable to have a lot of coding to do, and you may end up with something that is objectively worse than what you started with.
I don't think this question can be answered without knowing exactly how your partners are going to use your wrapper. Design an API that's suitable for them and then just delegate the calls to the appropriate (series of) SDK calls.
You might call that a facade if you wish, but I think your task is bigger. I'd say it's a new layer in a layered architecture. In that layer you can use all the patterns you see fit.
I am thinking to work on a programming problem for which, I suppose, I will need to know a lot of advanced programming concepts. For some reasons I have decided to code it in Java - even though I am not proficient in it.
So I want you to help me with suggestions, guidance, pointers to resources, books, tutorials or any generic advises that you think is pertinent.
Here is the basic nature of my problem:
I need to create a client-server architecture. Server supports multiple concurrent clients. Clients send it simple instructions (may be server exposes some kind of API/ runs listener on specific port), server executes the instructions and send result back to client.
The main job of the server is to do huge volume of data processing based on the instructions given to it. It takes data from backend database/ file systems. Data volume can easily surge up to ~ 200GB - 700GB. Data will be usually streamed to it, but it may require to hold huge volume of data in memory cache during processing (and if RAM is not enough, then page it to disk). Computations are generally numerically intensive in nature (let's say taking the inverse of a matrix)
The server should be able to do multithreading (I don't know what this term mean in Java, what I wish is, the server should be able to distribute the job in multiple parallel sub-processes.)
The server itself should be very lightweight. I Do NOT need any GUI Interface.
It will be great if I design it in a way so that I can integrate it later with HPC frameworks like Hadoop.
Now if I got to do this, what kind of programming do I need to learn? By the way, I have good understanding on OOP, I am somewhat familiar with Data Structures and algorithms, I know basic Java (never done any network or multithreaded programming in Java before, but have used typical oop concepts, generics, comparable interfaces etc.). I basically work in database programming, but have also done lot of C, C++, C#, Python in the past.
Given the requirement and my background, please suggest,
How should I begin to work on this project? What is the way to architect the project?
Should I create some basic API definitions first and then start working on the details?
Should I follow any particular design pattern? Where to learn them from?
What are the things I need to learn in Java and where to learn them from?
What is the best way to read huge data in memory? Is Java nio good solution?
If I instantiate a class with huge amount of data, would it work? (example, let's say I have a Vector class to represent a matrix with millions of elements and the constructor of the class reads huge data set in the memory). What's the best way to handle that?
You will want to define how the client and server will talk to eachother. The easiest way is to use established protocols such as HTTP by creating REST services that the client can call without much coding.
Most frameworks that support HTTP create several listeners that run in different threads. This gives you multi threading out of the box.
I'd suggest looking into I prefer Spring Controllers. Spring is fairly light weight.
If you want to use these frameworks, you will want to quickly find, and incorporate them into your application for compilation and packaging.
I would suggest looking into Maven for this. It's a big time saver. In particular using archetypes to create your project's folder structure, and auto download dependencies, and their dependencies.
Finally my words of wisdom. Ensure your services are singleton stateless services. This means you only create the objects once, and each thread uses the same objects. There is lots less garbage collection happening. This makes a huge difference when processing large amounts of requests.
Be careful not to use class level variables to hold state, in these services. If you do, different threads will over write each others data.
First thing I would like to say that as per your explanation of the things you seem to be in a pretty good shape to use java as your server side language.
The kind of client server architecture you choose may depend on what kind of clients actually you are serving to. Would they be typical GUI or CUI based desktop clients or the web clients.
In the latter case you could use Spring Framework in a normal fashion and for the former one you could go further to explore Spring's support for Restful Web services. I would advise not to go with socket or TCP based networking solutions or use java networking.
Spring's RESTful API gives you a very cool abstraction over things like networking and multi threading even for a desktop based client. In case of a desktop client you can use JSON/XML as response and can use HttpClient library for making calls to server, which is a very cool abstraction of the underlying networking stuff.
Further up Spring's design patterns follow a very linear flow of data. A lot of your fundamental design considerations are catered by the Spring itself using Dependency Injection and Inversion of Control which are extremely simple to incorporate.
For a detailed analysis of design patterns related to specific requirements I would suggest you to read the book called Java Design Patterns: A Tutorial of Addison Wesley publications and the author is James W. Cooper.
One more thing about the API design. It would be preferable for you to first create a API specification and then go further to implement them.
In web development we use java .net or php5 .
All are OO. and have all the OO features.
But in real time websites do these OO features play any major role other than inheritance.?
Can anybody list some with real time examples.
In application development there may be a vast use of OO.
But in case of websites, does OO playing a major role?
How?
Back in 1995 the book Design Patterns managed to produce this phenomenal insight on page 20:
Favor object composition over class inheritance
Since then, proper object-orientation has been about that instead of inheritance. Particularly, the SOLID principles describe a set of principles for object-orientation that are applicable for any code base where maintainability is important. Polymorphism is important, but inheritance is irrelevant.
That applies to web applications as well as any other type of application.
I make heavy use of encapsulation and polymorphism. Specifically I use the Strategy Pattern (among others) pretty heavily to compartmentalize a great deal of my functionality. When combined with dependency injection, it makes it really easy for me to separate functionality of say, my persistence layer, from my business logic or presentation layer.
For instance, it's trivial to swap out a hibernate implementation with a JDBC implementation, etc. Actually, recently, I just switched from an e-mail service that operates synchronously with the web request to one that uses a message queue to asynchronously send mail. All I had to do once I'd implemented the new layer was change which class was injected into my beans that use it.
Edit: To address your comment, #zod, I don't use it so with with regards to the pages that are executed although that does happen from time to time (for instance, I have different classes for HTML email and plain text email depending on what the user has requested) but I primarily make use of the OO principals in the configuration of the application. Does that make sense?
As a start, the main principles of OO come in handy.Take for example data encapsulation in an MVC pattern; The fact that you can have a User model that does all the user stuff means that everything that has to do with users is encapsulated in that one model. This makes it easier to add and modify features later on. The extensibility also comes in handy when you want to extend your program with the code other people have written. As long as you know the public interface of their classes, you can use them.
TO give a simple example we as a company heavily use it for security. We have plugins for various frameworks that controls who tries to reach which class and method. In addition to that we can avoid user to reach that class and method without adding extra lines to class.
Other than that we are using them to clarify the code as well.
Beside all of those doing OOP is good way to create a big project with a big team.
Having used DDD for a web site and finding it to be a neat approach, I'm wondering if this can/should be applied to desktop applications? Also, with the classes being separated into different packages, how could the MVC pattern be mixed in?
Generally speaking, there is no reason why you should not use DDD for desktop/GUI applications. The problem you hint at is IMHO more of an architecture/design problem. Mainstream approach to build web applications today is the MVC architecture, however, in the GUI world, there is a component based architecture with event handling. You can build components out of MVC, i think Cocoa is done in such a way. Retrofitting components into MVC might be harder. The reason is that components/widgets often contain logic which should be split in views and controllers. However it is still possible, but it is up to you to decide if you really want to go into MVC, which is IMHO sort of lower level architecture than components.
I find it difficult to implement DDD in rich applications namely because of how difficult it is to facilitate the controller because of the necessary listeners. I like using the Observer pattern in conjunction with Strategy where an Observer uses a Strategy object to operate on an Observable.
We are looking at reworking a java business management web service that has been in use for over 4 years now. The software's internal architecture has been all custom built and with a bad separation of of the presentation layer and business logic. As well the overall model layer has proven it can't effectively keep up with changing business logic and needs refactored. As I am planning out this task I have been looking at available frameworks that I could leverage to make the application more friendly to new developers hired on and changing business logic. I have never used struts or JSF before but read up on them in a somewhat brief and overview method and at first glance am not overly impressed by either, however I find JSF more intriguing.
First Both Frameworks seem to focus on the Controller and View portions of the MVC pattern. Leaving you to do whatever on the model/business layer. (am I correct?)
With the rework we want to be able to employ outside contractors to help expedite the rework so finding a unified development methodology is important to insure quality of code and decrease inconsistencies and ramp-up times.
So what recommendation would you have on frameworks, practices, etc that might help this effort. I really don't want to reinvent the wheel with a custom framework and find us in a similar situation later.
There are a couple of things you should think about when undertaking this approach:
Your specific needs vs. the focus
of a particular framework
Availability of coders who know the
framework (in-house and on the
market)
Learning curve for the
framework, and the level of its acceptance & support in the broader community of developers.
Many people speak highly of Spring MVC, though if IOC is new to you (or you don't buy the concept) this may be a bit more than you want to bite off "all at once."
Another well established option is Struts (though I'd strongly suggest Struts 2 for new development).
One thing to be wary of is the size & scope of a "framework transplant" operation. If your app is in dire need of serious structural reorganization, it's quite likely you could end up basically starting from scratch and hanging chunks of your existing business logic off of a skeleton built upon framework. The time/money/resources (and opportunity cost!) should not be underestimated, and you should be certain management really buys off so you don't get the plug pulled on you halfway through. It's really really important to "measure thrice and cut once" here, and make sure you're biting off a chunk of work you can chew -- going from "legacy app" to "brand new state of the art app using all new technologies" is frankly best done in stages, rather than all at once.
It would be helpful to understand the size & relative complexity of the application as well as it's basic nature (is it a very web-UI intensive app, or a back office system which does lots of jobs?) in order to make better suggestions about particular frameworks: though you could certainly build most webapps on any given framework, some are slanted more heavily in one direction than another (e.g., Struts and Wicket have a pretty different focus)
Additionally, there's nothing wrong with trying a couple candidate platforms alongside your existing application. Though I know nothing about your current app's technology backplane, unless you've done something really strange it's likely quite possible to install one or more frameworks and experiment with them alongside your existing app (e.g., write new features against them, or rewrite portions of existing code using them, then hook that code into the backend). This will let you experiment and "try before you buy". I'd suggest having your team give this a whirl on one or more "short list" framework candidates to get the feel for how it'll work in practice. This is, incidentally, not a terrible way to approach refactoring: gradually replace old functionality with your new framework.
Final (I think) piece of advice: look long & hard at your datamodel and the interfaces thereto. That's typically going to be where the real gremlins are, and regardless of framework you want to get that right. I'd strongly consider making that your #1 refactoring target, rather than the adoption of a particular framework. A strong datamodel is going to make implementing ANY framework (and handling upgrades) much easier...and should your management change directions on you and end up delaying the framework upgrade for whatever reason, time spent refactoring the data model will pay off.
EDIT:
Given your comments about the shape of the product, I'd double-down on the "be very, very careful" advice. The spot you're in now is very common (and notorious) and has eaten many teams (and careers) alive. You need strong understanding & support from stakeholders up the chain and on the business side as this is going to be a hugh undertaking which will, by nature, take longer & cost more than you imagine. The technical team's ability to be clear-eyed and realistic about the cost + scope of the changes here is CRUCIAL to success -- if you underestimate significantly you're jeopardizing budget, careers, and potentially the business itself. If you overestimate, you may never get to start :)
One approach, once you have strong buy-in and support from management, is to really treat this as a whole new product -- put the old stuff on maintenance, roll up your sleeves, and start designing the replacement system with all the knowledge you've gained in the previous implementation. In that case, I'd work out the component and data interactions sans-framework, then look at how a given set of candidate frameworks would support that implementation. Starting with the framework may lead you to unnatural places, and could land you back in a similar spot down the road.
Some well-known popular frameworks to check out:
Struts2 - MVC /w AJAX support
Wicket - AJAX heavy
Struts1 - Granddaddy of pretty much all Java frameworks; worth a look
Spring MVC - Spring's IOC webframework
If you liked JSF and want to use it, I would recommend the use of JBoss Seam. You can also use Spring, but I think that using JBoss Seam makes the use of JSF much easier. I am using it for almost 1 year now with good results. And if you want to modelate your process as a business process you can try JBPM (along with Seam).
If you want to know more about agile methodologies so you can improve both your methodologies and practices, take a look first on the agile manifesto http://agilemanifesto.org/ . And then start trying established methodologies like XP or Scrum.
But take your time, start trying one change than another not to confuse yourself
JSF allows you to focus on components, while JSP based solutions don't as well, or as much. You'll still find yourself coding a lot of jsp'ized html stuff, while with JSF solutions, you really don't need to.
Look at RichFaces or IceFaces as libs. RichFaces makes it trivially easy to do AJAX type stuff. Just add the tag <a4j:support event="onkeyup" reRender="output"/> to your standard JSF control. In the example above, on the keyup event for the control, it will rerender an area <a4j:region, or another JSF, Richfaces tag. Nothing simpler.