interesting thread, especially as I'm of the building architecture type designer and a tutor in that field also.
I find it interesting and fitting that architecture is use in software design.
In our field we establish constraints, analyse the brief, create bubble diagrams (like flow charts) create a site analysis (considering the "environment" and "context") draw some sketch designs (remembering the type of drawing has to be suitable for the viewer, perhaps the client (maybe little knowledge of construction), the client is shown drawings that will describe to them how they'll experience the building and its spaces. Maybe drawings are done for other consultants (mostly interested in there disciplines) and they can handle much more detail and are less interested in the experience. And all the way through are trying to do all this within the budget.
I hope you appreciate the analogy
As a building architect, or as a software architect, you might be interested in John Zachman's 1987 article on the need for IT systems architecture which he presents based on an analogy with building architecture and plans. In 1987 he starts with a bubble diagram as do you 25 years later which perhaps shows the maturity of the building architecture design process compared to IT and software systems design processes. Perhaps due to the rapidly changing IT landscape and the options open to IT/software design, such IT maturity is yet to be established, or maybe the analogy doesn't hold there as IT changes so rapidly.
Perhaps due to the rapidly changing IT landscape and the options open to
IT/software design, such IT maturity is yet to be established, or maybe the
analogy doesn't hold there as IT changes so rapidly.
Not to mention that the vast majority of projects in IT are substantially different than every other IT project.
If 90% of architects spent all of their time developing building that were substantially different than all others and had a lead time that is typically less than a year then it might be similar.
We tend to use the Software Design and Software Architecture loosely as equivalent terms. However, there are two different things.
In a nutshell, Software Architecture captures nonfunctional requirements( environment and system constraints, technologies, platform,...), analyses high level structure of the software components. The goal is a Software Architecture Design Document which is very important in stakeholders' early decision.
In contrast, Software Design or Software Implementation Design to be clear, elicits functional requirements. It is about detail implementation of divers software components.
Incidentally, Software Architecture and Software Design don't use the same techniques or methodology to meet their respective goals( they don't have the same goals!!!). The former uses 5 Architectural Views for example produce the Software Architecture Document, but the latter deals with class diagrams, sequence diagrams, use cases, state diagrams, etc... to produce Software code.
Anything more than a simple App I will design properly.
Start with a requirement outline and build the candidate classes from there. Then add in use cases to see what is needed or missing.
I use UMLet[^] for modelling and I try to at least model the main classes and activities.
Reality is an illusion caused by a lack of alcohol
Its a nice discussion. I would like to add some of my approaches to convince the management about a Software product Architecture:
1. At first I directly talk with my managers and try explain them about the importance of proper Architecture.
2. I prepare a POC and then have a meeting again with them.
3. I even include Tech Leads & some Senior Developers.
4. I circulate some supporting articles/blogs to them.
Be a good professional who shares programming secrets with others.
I really have fallen in love with the DDD concept. In short this is how we always work out a project.
All you need in the beginning is a whiteboard and a marker.
1. Define the domains within the scope of your project
2. Define the components within each domain.
3. VERY IMPORTANT: Give the domains and components GOOD names.
4. AGREE on the CONTRACTS of each component
5. Document your Diagram and Contracts.
6. Split the teams up each dealing with their component(s) and let them create UML diagrams.
7. Let each ULM diagram be coded out by a team that did not create the diagram.
I am trying to make distributed application in RMI/CORBA like ebay : allow individuals to submit classified ads to sell items with an auction system. At the closing date of the auction, the buyers who bid the last (if it exists) has the privilege of being able to acquire the object.A user can at any time be buyer or seller. Information of "user" necessary for the rest are mainly: name, password, bank details.
As want to operate::
1: Get a list of items currently for sale (list or search by keyword possibly). Obtained including a description, a current price, a date (or time remaining) closing of the sale.
When an item is worth :
1: get a minimum of information about the seller
2: the bid there must have authenticated.
Can I get help and little explanation about the architecture?
Well I am editing it....why u misinterpreted that...if u also know that this is not the place to give the code ...n I already admitted ....but u stick on that point rather than the main subject...strange..!!!
I did not misinterpret it. You distinctly asked for someone to write the code for you and then explain it to you. Why did you write that if that is not what you meant?
u stick on that point rather than the main subject
No, you asked for someone to write a bunch of code for you and I simply explained to you that that was not going to happen. Why you keep harping on that instead of posting the code you have written and asking an answerable question is beyond me.
I think u r good enough to understand the english words....I never ask someone to write code for me....even I admitted that in the first reply. n I dont understand why u take this so seriously ...u forcefully put ur assumption ..if u r interested to help me anyway ..do this otherwise leave it n I have changed the post .i think it is fine enough now.
I'm working on a new design for our old (25+) application. In this design should be more than one SQL servers (synchronized via replication). Each SQL server wrapped inside a DAL layer, and those DAL's are grouped using load balancing.
I looking to add cache to this design, and at first I thought that the best place to do so is at the individual DAL, however in this case I have to design a synchronization method between separated DALs.
To solve this synchronization problem I thought about a cache service to serve all the DALs (and maybe other parts of the design).
My question is, according to your knowledge and experience, will it be still effective to use a remote service to cache, or better to design cache synchronization that cross DALs?
Persumably you have 25 or more applications. And each of those use 1 or more databases.
After that your explanation loses me.
Do you intend, at some future time to consolidate databases? And that is a hard plan driven by business reasons? Because if not then they is absolutely no reason why any of these should be combined into a single cache.
Is there a distributed transaction model in play? If not then there is no need for "synchronization". And if there is then you should look into an actual distributed transaction model.
And why do you think you need to cache everything? Or even anything for that matter?
And I have no idea what you think "load balancing" means in this context. That term means a way of balancing requests across different servers. A DAL (Data Access Layer) exists within the application and unless all of the applications run on one machine load balancing across multiple applications would be difficult.
First of all thank you for your time...
and now some explanations to make it clear...
There is only one app - a web one. The application is distributed so the DAL is only a part of it (there are many layers between the UI that sits in the web server and the DAL which is combined, if not necessary physically, with the actual DB). The DAL is designed in a stateless way so we can lunch infinite number of DALs. In case of multiple DALs they grouped with load balancing. And when I say load balancing I mean exactly what you mean...
I thought about cache to improve performance of the DAL, but after looking into it I saw that I must
or make some synchronization between local caches
or make some cache server.
My question was about the usefulness of such cache server...
The DAL is designed in a stateless way so we can lunch infinite number of DALs
Then you have a server, not a DAL.
Kornfeld Eliyahu Peter wrote:
My question was about the usefulness of such cache server..
Depends on the data and the nature of the business.
If, for example, you have some small set of data that is used a lot and doesn't change often then caching is doable even with the complication of cross server syncing. As long as there is some allowed latency in the timeliness.
Conversely if you are loading billions of customer records by request from a user then there isn't much point because each request by itself likely has a very limited lifespan in the cache. And you would also need to implement sticky sessions for it to be useful.
We're developing a couple of web applications and want to allow users some advanced options if they've identified themselves.
The goal is that the user should only remember one username/password for all our applications (and services, we provide all kinds of newsletters and alerts as well).
SSO (Single-Sign On) was the first thing that came to mind, so my question is: what kind of recommendations can you give? I read a little about OpenId, but I know Google, Yahoo, windows live, ... also provides this.
Should we choose an existing service, and wich one is the best or should we write something for ourselves for our company only?
In the (near or further) future I would like to add the personnel as well through ldap or something.
This stuff is completely new to me so any advice, tutorials, recommendations would be helpful.
I have not a huge experience with SSO but just from how I'd feel as a user I'd say using an existing service as only possibility would be not a great idea.
If you us another service then you should add your own possibility too, such as CodeProject does offer a merged sign-on for codeproject.com and rootadmin.com - combined with the chance to use a Google account for signin in/up.
To the best of my knowledge you wouldn't be wrong to take a look at a form of Federated Identity Management using a Token Service. OpenId, SAML, WIF and OAuth are all token-based and will take you down the road of claims-based authentication and authorization.
I would have used something like STS as a starting point for a token service, but our management in their infinite wisdom want us to roll our own token service. This despite the fact that our token service will not be interoperable with anything else as it doesn't support any common standards beyond putting a token on the same HTTP header as other token services do. Oh, and there's no integrity check for our claims and everything is passed as clear text. Well, not as clear text actually, we're base64 encoding the token so it would only take a determined person a couple of extra seconds to walk right on in. Then there's the issue of token size, which is limited, so we'll roll our own zip function to cope with that, even though a decent token service will already do this for you, along with everything else we've implemented for no good reason.
But whatever, rant over. Just don't try and reinvent the wheel like our place does. Token authentication is not a walk in the park by any stretch of the imagination so anything you can use off the shelf will save you a ton or arseache.