This question is purely about semantical convention. I came onto a project where the architect named the API layer (.NET Core API) solution "middleware."
I have always referred to these projects as the API, e.g. MyMagicCompanyAPI.
To me, Middleware is usually the part of the code that intercepts http requests and does something before the request info is passed down the pipeline, e.g. .NET Core Middleware or the Angular Interceptor.
On that note, is it wrong to call an API middleware? If not, is it preferable/more accurate to just call it an API over calling it middelware?
Can a .NET Core API be Called “Middleware”?
Short answer: YES
Depending on the context in which it is being used.
.NET Core's, Angular's, (et al.) use of the term within their architecture is not the only contextual use of the term middleware.
As you said, semantics. Or better yet, it is a matter of context.
A whole API can be a middleware in a distributed system.
In distributed applications
The term is most commonly used for software that enables communication and management of data in distributed applications.
Other examples
The term middleware is used in other contexts as well. Middleware is sometimes used in a similar sense to a software driver, an abstraction layer that hides detail about hardware devices or other software from an application.
Reference https://en.wikipedia.org/wiki/Middleware
On that note, is it wrong to call an API middleware? If not, is it preferable/more accurate to just call it an API over calling it middelware?
That would be a matter of preference/opinion of the maintainer(s) of the said system as a whole.
Related
I have had a read on what's new in .NET4.6 and one of the things is ASP.NET 5 which I am quite excited about.
One of the new things is New modular HTTP request pipeline, however there is no more info on how exactly is it going to change.
The only reference in the article is
ASP.NET 5 introduces a new HTTP request pipeline that is lean and
fast. This pipeline is modular so you can add only the components that
you need. By reducing the overhead in the pipeline, your app will
experience better throughput. The new pipeline also supports OWIN.
What are major differences between ASP.NET4.5 and ASP.NET5 Http pipelines? How modularity will be controlled?
The biggest difference in my opinion is the modularity of the new request pipeline. In the past, the application lifecycle followed a relatively strict path that you could hook into via classes implementing IHttpModule. This would allow you to affect the request, but only at certain points along the way by subscribing to the different events that occur (e.g. BeginRequest, AuthenticateRequest, etc.).
The full descriptions of these can be found on MSDN: IIS 5 & 6 or IIS 7, and a walkthrough of creating such a module can be found here.
In the new ASP.NET 5 world, the request pipeline is decoupled from System.Web and IIS. Instead of a pre-defined path, it uses the concept of middleware. If you are familiar with OWIN, the idea is nearly identical, but the basic idea is that these Middleware Components are registered and then the request passes through them in the order that they are registered.
Each middleware component is provided a RequestDelegate (the next middleware component in the pipeline) and the current HttpContext per-request. On each request, the component is invoked, and then has the opportunity to pass the request along to the next in the chain if applicable. For example, an authentication component might opt not to pass the request along to the next component if authentication fails. Using this system, you can really handle a request any way you choose, and can be as light-weight or as feature-rich as you need it to be.
This example is a little bit dated now (e.g. IBuilder has been renamed to IApplicationBuilder), but it is still a great overview of how building and registering these components looks.
I am confused between these two nuances:
Is EJB itself middleware, or is there any middleware used in the deployment of EJB?
Same goes for RMI- is RMI itself middleware or is middleware used in RMI?
Define Middleware, if it is in the middle what is it between? I agree with the basic idea of this Wikipedia definition:
Middleware is a computer software that provides services to software
applications beyond those available from the operating system. It can
be described as "software glue".[1] Middleware makes it easier for
software developers to perform communication and input/output, so they
can focus on the specific purpose of their application
So the key idea is you write software and exploit something more sophisticated than the plain operating system. I would not say that middleware is only doing communication and input/output, as I'll explain later.
Now define EJBs. There are two things here: the EJB itself, that is application software that you write; you write an EJB as part of your application development so it is not middleware. But you write to a specification defined by Java EE, and deploy your EJB to an EJB Container provided by an Application Server. The EJB Container and App Server are providing something more sophisticated than the operating system. So the container and server are middleware.
The EJB Container facilities include communications (eg. RMI access and JDBC database access) but also include things such as security and transactions.
EJBs are a component of Java EE, which is a middleware.
RMI is another one, and also another component of Java EE.
You can see that these terms aren't too precise.
I agree with EJP.
Middleware, as it says, is software that provides service for distributed applications, it connects kernel(like server) and user apps.
EJB is a component architecture in server-side and is part of Java EE, it is built on RMI. So both of them are components of middleware.
For me, I liken middleware to the UNIX philosophy per McIlroy: "Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."
The middleware is all about handling the "text streams".
Each program does one thing, does it well. Having said that, it works on its own, but is also written to work together with others. If a program is to work on its own, then in my view, it is asynchronous. For this you need the middleware if it's to work with others.
I think the RPC (RMI) stuff is too tightly coupled, and synchronous, so it fails my definition of middleware. I think the EJB is trying to do far too much than handle "text streams".
There's obviously more to this topic. Try Middleware but it all gets too complicated for me, probably because people are trying to define middleware as stuff that allows programs from different vendors to talk to each other. Now you get into rivalry and competition, "standards" and ISO stuff.
The intent is to create a set of web services that people can reuse. These services mostly interact with a backend DB creating, retreiving and processing data.
We want to expose services so that people can use to create data mashups and other applications.
End users are webpages that can be within our domain or outside our domain. For pages outside the domain we plan to release widgets that would be configured to retreive and display the data.
One requirement - application should be extremely scalable in terms of the number of users it can handle.
Our code base is .net and we are looking at ASPX webmethods (or ASHX), ASMX webmethods and WCF (starting to read up on WCF).
In terms of security/access I found that maintaining sessionid, memberships is doable in all three. WCF seems a bit complicated to setup. I could not immediately see the value of asmx when we can get all done just using a webmethod in aspx (with a little tweaking).
Also, assuming that with the ASP.NET MVC2 I might be able to get clean urls as well for these webmethods.
Questions
Which one will be the most effective in terms of performance and scalability?
Any reason why I should choose WCF or ASMX?
Thank you for taking the time to read through this post and apologies for the naive questions since I am new to .net.
EDIT I kind of understand that WCF is the way to go. Just to understand the evolution of the technologies it would be good if someone can throw light on why a aspx webmethod is different from an asmx when similar things (apart from discovery) can be accomplished by both. The aspx webmethods can be made to return data in other formats (plaintext, json). Also, it seems that we can build restful services using ashx. Apologies again for the naive questions.
You should use WCF for developing webservices in .Net. WCF is highly configurable with many options for security, transport protocols, serialization, extensions etc. Raw performance is also significantly higher. Also WCF is being actively developed and many new features being added in version 3.5 and 4. There are also variations like WCF data services and WCF RIA services. WCF 4.0 also has better REST and JSON support which you can directly use in ASP.Net / JQuery.
ASMX is considered deprecated technology and replaced by WCF. So if you are going to start new development which requires exposing reusable services, WCF is the way to go.
I am not necessarily disagreeing with previous answer. But, from a different perspective, WFC is tricky to configure. It requires bindings, endpoints, packet sizes, a lot of confussing parameters, etc in your configuration files, and there are many serialization/deserialization issues reported. Also WCF is a relatively new technology (therefore still exposed to bugs and patches needed).
The client-generated [Reference.cs] files might have unwanted interfaces, and each public property client class exposed in the WSDL gets generated with the same observer pattern that LINQ to SQL or Entity Framework uses ( OnChanged, OnChanging, etc) so this adds a lot of fat to the client code, as opposed to the traditional SOAP Web client way.
My recommendation, if you aren't using Remoting over TCP or if you don't need the 2-way notification mechanism for remote changes - all these are very cool features of WCF - you don't need to use it.
Does Astoria Service Model only support
ATOM,JSON,XML,XML+HTTP
Are formats like SOAP,WSDL,ASMX outdated? .So when i wish to develop SOA can i ignore SOAP,ASMX,WSDL formats?
I would add to the above answer and say there is in-fact a way to discover the metadata about the Data Services (REST) endpoint. Every endpoint includes a service document (just do a GET on the root of the endpoint) that describes the sets exposed by the service. Further, going to the $metadata endpoint from the root of the service (i.e. http://mydomain/myservice.svc/$metadata) returns an XML metadata document that fully describes the service (the sets, types, properties on types, relationships between sets, and service operations).
No, most definitely not!
ASMX = ASP.NET webservices - this is outdated, it was introduced in .NET 1.0 and basically replaced with WCF in .NET 3.0.
BUT: WCF is definitely NOT outdated! WCF is the Microsoft standard way of communicating between two systems. It uses SOAP (including WSDL and XSD) by default, and this is mature and reliable technology which works well in enterprise scenarios where you need things like data integrity, (human and machine readable) service description through WSDL and service metadata, and so forth. SOAP also offers more advanced features like reliable messaging and transactional support.
REST / ADO.NET Data Services is a more lightweight, easier-to-get-at approach at exposing services, but it's lacking in many ways: there's no unified service description available, so you cannot really "discover" what methods and what datatypes the service offer; either you have knowledge yourself, or the service provider gives you a documentation in plain English, but there's no standard way of describing a REST service to the outside world (yet). Also, you don't really know ahead of time what kind of data that service might return - there's no XML schema to stick to - it's more of a "let's hit the service and see what comes back" approach which might work quite OK in some cases, but not really in larger scale, enterprise-style environments.
So to sum up: the SOAP (WSDL,XSD) vs. REST debate is ongoing, both have their reasons to be, and I don't see one of them replacing the other - they're supplanting one another.
I've been a longtime ASP.NET developer in the web forms model, and am using a new project as an opportunity to get my feet wet with ASP.NET MVC.
The application will need an API so that a group of other apps can communicate with it. I've always built API's out just using a standard web service prior to this.
As a sidenote, I'm a little hesitant to plunge headfirst into the REST style of creating API's, for this particular instance at least. This application will likely need a concept of API versioning, and I think that the REST approach, where the API is essentially scattered across all the controllers of the site, is a little cumbersome in that regard. (But I'm not completely opposed to it if there is a good answer to the potential versioning potential requirement.)
So, what say ye, Stack Overflow denizens?
I'd agree with Kilhoffer. Try using a "Facade" wrapper class that inherits from an "IFacade". In your Facade class put your code to consume your web service. In this way your controllers will simply make calls to the Facade. The plus side of this being that you can swap a "DummyFacade" that implements the same IFacade interface in that doesn't actually talk to the web service and just returns static content. Lets you actually do some unit testing without hitting the service. Basically the same idea as the Repository pattern.
I would still recommend a service layer that can serve client side consumers or server side consumers. Possibly even returning data in a variety of formats, depending on the consuming caller.