We have a project that is pretty nearly done now and has hundreds of existing WEB API Services.
We have documented everything as far as design and example URLs on a wiki as we went.
Now that we are near the end, I have been tasked with finding a product that that is more truly meant to document WEB API services like API Blueprint or Swagger.
I migrated a few API services from our wiki to API Blueprint and Apiary.
But that editor is kind of clunky and now I have stumbled onto RAML and like the human readable syntax much more as well as it's reusability features.
Our second goal however is to be able to use that same API documentation to perform integration testing.
Does anyone know of any tools that could auto document our services without me having to manually move everything over? I need a kind of an environment that would also support Integration testing.
It depends on the language.
For ASP.NET 5 / WebApi you have the RAML .NET Tools
You can check all the available tools here and filter by language and type.
I am newer to the topic of GI.I just what to know why we are using GI,what is GI.
General interface is a proprietary UI framework developed by TIBCO. It features AJAX and rich client experience. They used it for one of AMX BPM interfaces : Workspace, and made it available via licensing for implementation.
This was another time... back then multiple companies tried to suggest a (often proprietary) approach to rich client based + back-end calling web UI. Ajax was the rage... and everybody tried to impose a framework.
A lot of that changed in the following years, when some new tools emerged, like Google Web Toolkit (GWT), JSF, Wicket, etc.
Eventually, TIBCO itself would use GWT in a second BPM UI : Openspace.
Arguably, most of these framework looks complex and outdated when compared to the lighter,current web frameworks, such as : JQuery, Webix, etc. These are mostly done with Javascript.
All,
I'm beginning to explore what frameworks (open source) and tools for building web applications. What should I select and learn for the following layers,
Layer 1
Client side JavaScript / AJAX library or framework that will invoke REST style services provided by layer-
2
Layer 2
Provides a framework to rapidly create REST style services out of existing applications and out of a NoSQL document oriented database provided by layer-3. I need this layer in cases where I need to expose REST style services out of my traditional apps and RDBMS.
Layer 3
Which NoSQL to use - CouchDB or MongoDB that would work well with layer-2?
Will I need a MVC framework like RoR or a web/component framework like Wicket? Am I missing anything?
I also need recommendations for which tooling/IDE (and associated plugins) for the development environment. Thanks in advance for your answers/thoughts.
We've had pretty decent luck using a Java stack:
For the presentation, we use jQuery and jQueryUI, with Freemarker for XHTML/CSS templating, including to invoke REST web services through various UIs.
Restlet (www.restlet.org) is a wonderfully rich framework for crafting REST web services in Java. We decided to use it on a major product after it was strongly recommended to us by the engineering director of a top 10 e-commerce site in the US. And everything he said about it was true.
Unless you know you're going to face a really large amount of write volume, you're probably best off using one of the tried and true SQL databases supporting ACID transactional guarantees. We used Oracle, then switched to PostgreSQL, using the MyBatis (formerly iBatis) SQL Mapper to shield our code from the details of the database. With the advent of 64-bit addresses and scads of inexpensive DRAM, plus SSDs, these old workhorses do scale quite high.
If you are anticipating very large amounts of writes, by all means consider a so-called "NoSQL" database. I heard very good things about Vertica from the top network ops folks at a major technology company last week. MongoDB and CouchDB both look interesting. Or you may be able to leverage persistent distributed cache technology like Redis or EhCache to offload a traditional database.
The task you're trying to accomplish determines the technology you use.
If you're interested in the .NET platform, consider:
RavenDB for the data layer.
WCF Data Services for your REST services layer. Here's a guide to WCF Data Services with some great video tutorials.
If you need a web front-end, consider ASP.NET MVC or plain HTML as you see fit. jQuery and AJAX modules are well suited in both.
Arguably, ASP.NET MVC IS a REST endpoint of sorts, so you could skip the WCF services.
All the above can be leveraged with free tools, including:
Visual Studio Express
Raven DB's HTML interface at http://localhost:8080/
In the past I have primarily built all my web applications using an N-tier architecture, implementing the BLL and DAL layers. Recently, I have started doing some RoR development as well as looking into ASP.NET MVC.
I understand the differences between the different architectures(as referenced by some other SO posts), but I can't really think of any reasons why I wouldn't choose an MVC model going forward for a new project.
Is there any reasons/times in your experience when an MVC architecture would not be suitable, or any reasons why you would choose a BLL/DAL architecture instead?
I don't think your options are mutually exclusive. You could perfectly use MVC while using BLL/DAL for your model logic.
You can implement the M part of MVC as you prefer, there is no restriction about that. Using BLL and DAL would be a valid option.
For me? the only reason I'd not use MVC is because the application I'm working on was already started in web forms. I'm not a big proponent of scrap/rewrite, but anything new I do is in MVC.
One of the factors could be the statefulness of your web application. If it's a basic web application that gets everything from the server with a few JavaScript hooks such as client side validations, then the Rails type MVC is really great. I am not familiar with MVC on ASP.NET, but I've heard it's similar to that in Rails.
If the web application is really stateful, then a better approach would be to have a dual MVC layer - one on the client side, and the other for the server. The MVC on the server will mostly concern itself with authentication, authorization, churning out data in standard formats, etc. The client side MVC will concern itself with things such as DOM events, user actions, how they affect the application state, and how/when should data be requested/sent to the server.
MVC is just a way to organize code, just as BLL or DAL would do. MVC in Rails basically hides DAL altogether by using a set of conventions. Usually business logic resides in the models itself. However, if your application demands more complex BLL where object interactions can be intricate, then there's no reason why that BLL can't peacefully co-exist with the M in MVC.
I don't use MVC only on really tiny projects consisting of ~1-2 files and ~10-20 lines of code. And they will hardly evolve into something bigger.
But if they will, it will be time to rearchitect them into a MVC ones.
The only drawback we've had is that MVC pushes you toward a html/javascript interface where rich internet applications become more difficult. For example if you want to present the user with a calendar control, you may need to roll your own since you can't drop one on from the toolbox. That said, MVC is great. When we really need RIA applications we use MVVM and Silverlight.
For certain pages, MVC can be a little overkill:
splash pages
landing pages
marketing pages that are going to be thrown away after one use
one-off's
It's easy to get wrapped up creating a beautiful MVC architecture, when a small page, concisely written, can be OK on these situations.
MVC may also be impractical if you're in time trouble, and you need something out REALLY fast. Like your marketing team is out at a conference, they're having trouble, and needs something to show in their booth this second before they lose their biggest customer.
Life above the service tier suggests you should use the MVC pattern in a way that adheres to the SOFEA principles, and watch out for "Front controller" type frameworks disguising behind the MVC acronym.
(or, you can still use them, but at least read the article, understand the differences and choose wisely).
The simple answer is, no.
MVC is all around a better architecture than your old-school n-tier architecture, for many reasons. It's the standard approach in other UI models (e.g. Swing). The only reason it took so long to make it to web applications was because it took the software community, collectively, a little while to get used to the statelessness of the web and to be able to deal with the views and controllers in a way that made sense.
Personally, I would rate it based on the complexity of the target application. MVC (or more structured approaches in general) lend themselves very well to large scale applications where design consistency and segregation of code is a benefit outweighing the cost of supporting the design.
If its a small site, or very few pages/controls, I would avoid sticking to strict design patterns. But that is just my preference.
As one poster said, you also have to consider the state of any existing applications, and your development team skills / experience.
We have already use the MVC for the Windows application,Now we need to convert that thing in the Web application we don't have any problem in any thing. We are using the Web service and every Business Logic is in the Web service.
So you can use the MVC in the web application.
M-Model(Functions and Procedure which communicate with Business logic)
V-View(Design)
C-Controller(Form Logic)
so that is no connection in the DAL,BLL and in MVC.
you can define your Business logic and use in it any where in the MVC.
That's my point of view MVC is very useful for Re-usability i prefer if your application is big then you must use MVC.
I wouldn't use MVC pattern only in the case when I have an existing desktop application built with MVP and I have to convert it to a web environment. That's because I already have written logic for presenter.
In any other case I would use MVC.
You can refer to following
http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx
and http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 refer "Undisputable Facts".
I've came across this new acronym, SOFEA, apparently a new programming paradigm for web applications.
Still didn't manage to make sense of it - if someone volunteers to make it clearer for me I'll be very thankful.
SOFEA is an abbreviation for Service Oriented Front End Applications/Architecture, it refers to a web application architecture where all of the UI functionality is provided by javascript or flash-based logic. It doesn't interact with the web server per se to provide application level access to data, but rather interacts with web services through AJAX. Essentially, you provide all of the UI logic in a single (or few) web pages. These pages work with web services to access and update data.
Reference at InfoQ
AKA SOUI by the way... (Service Oriented UI) ref: here
As integration on the response above, as alternative for the comunication between the two decoupled layer presentation and busines logic you can use different technics and technology as XML or Json using REST & RESTFUL paradigm or even SOAP and last but defenetly not least websocket.