Open source non-trivial SOA examples - soa

I've been looking for open source examples of SOA applications, but most of the times I find simple tutorial hello world style examples that introduce the tricks of the respective middleware.
Do you have any suggestion about any middle to big size example with multiple layers and/or governance ? Isn't it some kind of common example (a la Lena in image processing) for SOA ?
Any suggestions ?
Thanks

What you may want to do is look at OpenESB:
http://wiki.open-esb.java.net/Wiki.jsp?page=OpenESBIntroductionTutorial
Once you have a working example then you can look at extending it yourself, as you will have the tools to do that, and see how you can get applications to work together.
Are you trying to learn how to use SOA or do you want to look at an architectural diagram where it has been used in a complex system?
The introduction above is for learning to use it, via OpenESB, I don't know where you may find a diagram of a large example of SOA.
It may help if you could narrow your question down to what precisely are you looking for.

I do not know of a detailed example you seek. If you are taking an approach of learning how to use SOA by checking examples, it may be a bad approach. You need to first know what and how you are going to do your SOA and then see what features are are enough for your needs.

Related

Simple explanation of "Unified Modelling Language", why is it important?

i am new to asp.net and i was told that i need to know UML thoroughly to build successful software, is this correct? i mean cant i just "code and fix" and "model" in my brain. how important is UML and what is the best way to learn it?
UML is a standard used to convey information about the design of an object oriented software system in a (mostly) graphical format.
It is important as it makes communicating about such a system easier.
UML is a simple way to graphically document a system and its interactions. Its value to you is not necessarily using UML itself, but the value of documenting a system before coding or modifying it.
I see the advantages as
You are forced to think about the whole design before you start building. A drawing is a lot easier to change than a whole lot of code. Mistakes at this stage are easier to rectify.
It helps to understand the system and interactions far better than code alone can. With all the self-documenting code that you can write, a good diagram will nearly always be clearer to and fast to pick up.
The disadvantages are
Takes time to produce, when you would probably rather be coding and experimenting
Can get out of date if effort is not put in to keeping up to date.
i mean cant i just "code and fix" and
"model" in my brain
You can. It's done every day. And a lot of what's going through it at the time, and how you convey your ideas on napkins is already a form of UML without its rigid nomenclature.
But if you're working with colleagues on big systems, there may be occasions were they speak the language.

What does a developer need on the front end to ensure a successful project?

I have an idea for a business that requires a well designed web application. I'm not a rocket surgeon, but I'm smart enough to know that you get what you pay for and am willing to pay for talent. However, I want the development process to go as smoothly as possible and would like to know how to make that happen.
So, what information do developers need (or want) initially from the owner to avoid having to make assumptions about business (or other) requirements? Do I need to create state transition diagrams or write use cases?
Essentially, how do I take the concept in my head and package it in a way that allows the developer to do what they do best? (assuming that is creating good software. haha)
Any advice is appreciated.
Shawn
You may need to reword your question, as it is too general to get a good answer, so some vague details would be helpful.
But, the better vision you have of what you want the smoother it will be.
I find UML diagrams too confining, when you aren't going to be doing the work, as you may not come up with the best design.
So, if you start with designing out what each page should look like, as you envision it, then you can write up use cases, which are short scenarios.
So, you may write up:
A user needs to be able to log in using OpenID.
This will tell the developer one function that you want, and who you expect to do that action.
But, don't put in technologies, as you may think that a SOAP service is your best bet, but upon talking about it you may find that there is a better solution.
Use cases are good points to show what you are envisioning, and give text to your page designs.
Talk to the developers. Explain what you want and why you want it. Together you make the flow charts and whatnot. Writing requirements is part of the design process, and it's a good idea to have the developers onboard as soon as possible. Start simple and small, then grow and expand while iterating.
In talking over web services before, I have found the best starting point is drawing on a sheet of paper what you think the site will look like, and add in a few arrows from things you want clickable to the pages that should result. Keep it simple, nothing too fancy, and hopefully you and the developer can come to an understanding of what you want pretty quickly.
Use cases might be best for checking off all the points later in the project about how complete your site is; I haven't really found it to be a helpful starting point, but I'm sure others disagree. (They just seem too tedius to read when actually writing code.)
Same with state transition diagrams; they are too tedious and I think most developers will assume you made mistakes in them anyway. :) Everyone else does... Unless your project hinges very tightly on the correctness of a state machine, I wouldn't really bother.
This book contains some good advice on what constitutes a good statement of requirements from a programmers point of view. It also has the useful guideline of not trying to set the form of your requirements too early, and a substantial piece on describing the problem you are trying to solve.
I like UI mockups based on actual program/site flows e.g registering a customer or placing order. Diagrams/pictures of GUIs with structured, consistent data examples are unambiguous.
I agree that UML and use cases are only really useful if everyone speaks UML and the projects are of sufficient complexity (few are).
You may want to read up on Agile/Scrum techniques. These are becoming a sort of standard and when properly managed can save weeks of development time.
I find that words don't do a good job of communicating how a system is supposed to work. Wireframes, white-board drawings/transition diagrams, and low-fidelity prototypes are great ways to communicate a concrete idea. One example of a low-fidelity prototype is a "clickable" paper prototype that allows a user to touch "buttons" on paper to go from one drawing to another. It costs very little time (cheaper), but goes a long way to communicate an idea between two parties.
Stay away from formal documentation, UML diagrams, or class (technical documentation) diagrams that don't speak to you. This is what large, risk-averse companies move toward to be more "mature". These are also byproducts of an idea that is hashed out, and it sounds like you're in the hashing out stage.

What's the easiest way to explain What is Hadoop and Map/Reduce?

It's very easy to explain NoSQL from high level view - it is basically "key-value" storage. Of course with thousand minor and important things, but in general it's just key value storage.
What's the best way to explain Hadoop and Map/Reduce?
May be some "real world" example which can be easy to give an compare for even newbies? Thanks!
I recently found this great article describing Map Reduce :
I’ve been planning on writing about
the Google’s MapReduce algorithm for
some time but I couldn’t find a good
practical example. Then we had a
Northwest C++ Users Group presentation
by Steve Yegge and a followup
discussion and beers, and I had a
little epiphany. Steve was talking
about, among other things, the build
process. And that’s just a bunch of
algorithms that are perfect for
explaining MapReduce.
The code examples are in C++, but the content is really language agnostic.
Here's a great tutorial on map/reduce in general, explaining the background, basics and data flow. I'm finding it useful to explain Google's App Engine implementation as well.
http://developer.yahoo.com/hadoop/tutorial/module4.html

ASP.NET: I'm new to n-tier architecture. Can someone give me a high level overview?

can you please describe what an n-tier architecture is. what is a data access layer? what type of code would typically go into this data access layer class? i have basically the same question for the business access layer. what type of code typically goes there? finally, can you also explain, in high level, how these layers interact with each other? thanks.
http://en.wikipedia.org/wiki/N-tier
Microsoft Patterns & Practices site is a good resource for this type of stuff. They've published a book ($$$ for print, free-as-in-beer ebook), the Microsoft Application Architecture Guide v2, which has a solid overview and walkthrough of N-Tier:
Application Architecture Guide: Design Fundamentals
Google is your friend, as is wikipedia as STW pointed out. You might wanna check out this though - http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx as it gives a practical example.
I've been mulling this around in my head for a few years, so I'll just throw it out and see what happens:
N-tier is crap.
When developers first learn about it, they twist their code into all sorts of hideous contortions to make it fit "n-tier". Then (if they are not incompetent) they grow up and just sort of give up on that approach. Then (if they are reasonably competent) they realize that all the other real sorts of architecture, which you have to learn over time and which can't be distilled into this ridiculous one-size-fits-all 3-bucket magic, do frequently (sort of) map to the 3 tiers. But they aren't built on the 3 tiers - you don't start with 3 magic buckets and everything falls neatly into them. 3 tiers simply tend to emerge from a proper design. Starting with 3 tiers is backwards.
So my advice - which may be wrong, I'm just testing this idea out - is don't try to understand 3-tier until you understand all the other, more basic patterns and practices, and you've built some solid software using them. Feedback welcome.
If you're like me, you learn by playing with code rather than reading articles. Here's a little example tutorial.
Oh, and also read up on the difference between a Tier and a Layer. It's a pet hate for some StackOverflowers :)

How To: Pattern Recognition

I'm interested in learning more about pattern recognition. I know that's somewhat of a broad field, so I'll list some specific types of problems I would like to learn to deal with:
Finding patterns in a seemingly random set of bytes.
Recognizing known shapes (such as circles and squares) in images.
Noticing movement patterns given a stream of positions (Vector3)
This is a new area of experimentation for me personally, and to be honest, I simply don't know where to start :-) I'm obviously not looking for the answers to be provided to me on a silver platter, but some search terms and/or online resources where I can start to acquaint myself with the concepts of the above problem domains would be awesome.
Thanks!
ps: For extra credit, if said resources provide code examples/discussion in C# would be grand :-) but doesn't need to be
Hidden Markov Models are a great place to look, as well as Artificial Neural Networks.
Edit: You could take a look at NeuronDotNet, it's open source and you could poke around the code.
Edit 2: You can also take a look at ITK, it's also open source and implements a lot of these types of algorithms.
Edit 3: Here's a pretty good intro to neural nets. It covers a lot of the basics and includes source code (albeit in C++). He implemented an unsupervised learning algorithm, I think you may be looking for a supervised backpropagation algorithm to train your network.
Edit 4: Another good intro, avoids really heavy math, but provides references to a lot of that detail at the bottom, if you want to dig into it. Includes pseudo-code, good diagrams, and a lengthy description of backpropagation.
This is kind of like saying "I'd like to learn more about electronics.. anyone tell me where to start?" Pattern Recognition is a whole field - there are hundreds, if not thousands of books out there, and any university has at least several (probably 10 or more) courses at the grad level on this. There are numerous journals dedicated to this as well, that have been publishing for decades ... conferences ..
You might start with the wikipedia.
http://en.wikipedia.org/wiki/Pattern_recognition
This is kind of an old question, but it's relevant so I figured I'd post it here :-) Stanford began offering an online Machine Learning class here - http://www.ml-class.org
OpenCV has some functions for pattern recognition in images.
You might want to look at this :http://opencv.willowgarage.com/documentation/pattern_recognition.html. (broken link: closest thing in the new doc is http://opencv.willowgarage.com/documentation/cpp/ml__machine_learning.html, although it is no longer what I'd call helpful documentation for a beginner - see other answers)
However, I also recommend starting with Matlab because openCV is not intuitive to use.
Lot of useful links on this page on computer vision related pattern recognition. Some of the links seem to be broken now but you may find it useful.
I am not an expert on this, but reading about Hidden Markov Models is a good way to start.
Beware false patterns! For any decently large data set you will find subsets that appear to have pattern, even if it is a data set of coin flips. No good process for pattern recognition should be without statistical techniques to assess confidence that the detected patterns are real. When possible, run your algorithms on random data to see what patterns they detect. These experiments will give you a baseline for the strength of a pattern that can be found in random (a.k.a "null") data. This kind of technique can help you assess the "false discovery rate" for your findings.
learning pattern-recoginition is easier in matlab..
there are several examples and there are functions to use.
it is good for the understanding concepts and experiments...
I would recommend starting with some MATLAB toolbox. MATLAB is an especially convenient place to start playing around with stuff like this due to its interactive console. A nice toolbox I personally used and really liked is PRTools (http://prtools.org); they have an implementation of pretty much every pattern recognition tool and also some other machine learning tools (Neural Networks, etc.). But the nice thing about MATLAB is that there are many other toolboxes as well you can try out (there is even a proprietary toolbox from Mathworks)
Whenever you feel comfortable enough with the different tools (and found out which classifier is perfomring best for you problem), you can start thinking about implementing the machine learning in a different application.

Resources