I have a large number of services that my team are building and the auto-generated metadata is getting a bit unmanageable. To combat this, I created a project as a nested site (or sub-site) of the root. This works fine on my IIS local, but doesn't seem to work on a server-based IIS. Is it possible to get URLs like the following:
- http://server/WebServices [Root Project]
- http://server/WebServices/Project1 [Sub Project 1]
- http://server/WebServices/Project2 [Sub Project 2]
I know that using the routes in the AppHost I can get this effect but the resulting metadata is starting to get huge as they're all in one site. What I want is to be able to manage separate services in separate projects and have them come out in a hierarchy similar to above.
Look into the implementation of Routes.AddFromAssembly() extension method which goes through all the services are registers routes with the following conventions:
/{requestDto}
/{requestDto}/{Id}
On each of the HTTP Verbs that are implemented.
You should be able to implement your own conventions using a similar approach.
Related
Say I'm going to create few microservices: Alpha, Beta, Gamma.
In terms of Application structure using older Symfony version like 2, I'd create a bundle for each service, but bundles are no longer recommended in Symfony 4. So... Should I create separate repositories for every service or still create a bundles in a one App?
If you have different microservices, as in different applications, you will not need bundles. You can keep them in different repositories, but a common practice is to use a so called mono-repository. As the name suggests, with a mono-repository you keep all of the projects in a single repository. This has the benefit that changes spanning all projects can be done more easily and in sync. The drawback is that it requires more effort when managing and might cause additional overhead when building and deploying as it will not be easy to see which service has changed so must likely you rebuild all of them. There are a few books and presentations on mono-repositories you might want to check out. In short, Symfony does not restrict how you manage your services. You can have a single repository for all projects or multiple repositories.
If you want to serve all "services" through the same application, even without bundles, you can do so by using namespaces to separate the logic, e.g. for controllers:
my_app
- src
- Controller
- Alpha
- IndexController
- Beta
- IndexController
This should work out of the Box with the default configuration and even if you deviate you can make things like argument resolvers work by just pointing the configuration to the correct folder. Obviously this will require you to make sure that code is not shared between services should you ever want to extract them into their own application. There are some static code analyis tools that help you with keeping your architecture clean, i.e. make sure Alpha does not use code from Gamma and vice versa.
If you want to separate the apps more clearly by doing something like this:
my_app
- src
- AlphaApp
- ...
- BetaApp
- ...
You can still do that but it will require more manual work and the recipes will not work anymore, requiring you to do manual changes to most configurations and moving around files. How to do it depends on whether you want a shared kernel or a separate kernel for each service, but if you go that route I recommend keeping separate projects in the same repository, as it will probably yield cleaner results and be less work.
You can still create bundles in symfony4 though its not recommended by best practices. see https://symfony.com/doc/current/best_practices/creating-the-project.html
I created a tutorial that incorporates various components of J2EE in them. The app is an ear module that has an ejb project and a web project.
the project structure is
john-app
john-ear
john-ejb
john-web
the ejb project has a couple dao that perform basic crud operations using jpa. I'm trying to learn/understand jax-rs to gain a better understanding of json and handling json objects. the project is loosly based on
this project:
http://www.developer.com/java/creating-restful-web-services-with-jax-rs.html
so, i created my BookResource here and made it a stateless ejb. i have everything compiling and deploying without any obvious errors - other parts of the app work (the jpa stuff) but i can't get the jax-rs stuff to
work. i have a couple of"Books" that I created in my database and am wanting to test this by making a rest call through the browser.
so i deploy my .ear file in wildfly (v10) with no obvious errors, I see JNDI mappings for my EJB's...etc
initially, i'd like to be able to test this through my browser, but am not certain what url to use -- the class i have extending javax.ws.rs.core.Application has an application path of /rest and my
BookResource has a path of /library, and for getting all books from the library, the sub-resource is books. I've tried every combination of the url below,
http://localhost:8080/john-[app|ear|ejb|web]/rest/library/books
all to no avail. every call results in a 404 error, and the only time i got ANYTHING is when i tried john-web combination, it threw some ugly exception in the browser. so the questions is with a rest service living inside an ejb module within an ear, what should the url be given the above information. nothing i've tried
seems to work!??
I've not included any code samples to try and keep the explanation short -- i didn't want to include every java file in my little project, but can add anything as requested.
Thanks,
JG
I'm trying to create a Web API project and a client-side web project, where the web project can access the API via ajax. Currently my project looks like this:
I saw this answer on here: Setting app a separate Web API project and ASP.NET app, which explains how the project url can be set to localhost:[port]/api.
But for ASP.NET 5 projects, the properties only have 3 tabs (as opposed to the several found in ASP.NET 4 projects):
What I'm wondering is:
Do I have to set this option somewhere else? (i.e project.json)
How would this work when I publish? Ideally I'd want [websiteURL]/api to serve up my API, whereas that link explicitly put localhost:8080.
Is having these as two projects a good idea? I could easily put API and web in the same project, but I like the separation of client-side and server-side logic.
Any help would be appreciated!
First Point:
Generally speaking in ASP.NET 5, the routing defaults are very good and should work out of the box without much in the way of configuration. You can use configuration and/or attribute based routing in your application (with a detailed overview of both here), although my personal preference is for the attributed approach. Provided you have the following line in your Startup.cs file (which you should have in a new project):
app.UseMvc();
you should be able to route requests to your api controllers in the fashion required (i.e. "/api/...") simply by using [Route] attributes as below (example taken from a standard generated ASP.NET 5 Web API application)
[Route("api/[controller]")]
public class ValuesController : Controller
{
[HttpGet]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
}
The above example will route any GET request made to "/api/values".
While this approach can be used to handle requests made to your api, in order to deliver the files needed for your front end javascript application/single page app, you will need to enable static file serving. If you add the following to the Configure method in your Startup.cs class:
app.UseStaticFiles();
this will allow your application to serve those static files - by default, these are served from the ‘wwwroot’ folder, although this can be changed in the project.json file if required. The files needed for your front end app should then be added to this folder. A tutorial on serving static files can be found here.
Second Point:
In my experience this will not be an issue when you publish your website - provided your server is set up correctly, you will not need to include the port when making a request - navigating to [yourwebsitename]/api/... will suffice.
Third point:
In my opinion this entirely depends on how large the project is likely to grow, although preference and opinion will vary from developer to developer. Generally speaking, if the project will remain small in scope then keeping both in a single project is perfectly ok, as unnecessary complexity is reduced. However it is also very useful as you have pointed out, to maintain a separation of concerns between projects. So aside from the organisational advantage of your approach, the respective dependencies of the two projects are/will be kept separate also.
I've seen api-paste.ini as a conf file after installing openstack.
It looks like substituting some prefixes for python implementation but have no clue about this.
Here, my questions are:
What script is it?
it looks like very bizarre grammar like the following:
[composite:metadata]
use = egg:Paste#urlmap
/: meta
How does it work within python script?
See documentation for Paste Deploy.
The api-paste.ini is the configuration for the above web-services framework. Paste.deploy allows you to separate concerns between writing your application and middleware/filters from the composition of them into a web service. You define you WSGI applications and any middleware filters in the configuration file then you can compose pipelines which include the middleware/filters you want into your web-service, e.g. authentication, rate-limiting, etc.
You want to temporarily remove authentication, take it out of your pipeline and restart your web service.
The declaration above is declaring a composite application, but with only one application binding (a bit unnecessary - normally you would expect to see more than one binding, e.g. for different versions of the application). The WSGI application app:meta will be bound to / and you should have a declaration of app:meta later in the file. The implementation of the composite app is declared via the use and the egg:Paste#urlmap is a simple reference implementation.
You load this in your program with paste.deploy.loadwsgi.loadapp().
There is a proposal/recommendation(?) to move away from Paste Deploy/WebOb to WSME/Pecan see OpenStack Common WSGI
We have a series of web services that live in different environments (dev/qa/staging/production) that are accessed from a web application, a web site, and other services. There are a few different service areas as well. So for production, we have services on four different boxes.
We conquered the db connection string issue by checking the hostname in global.asax and setting some application wide settings based on that hostname. There is a config.xml that is in source control that list the various hostnames and what settings they should get.
However, we haven't found an elegant solution for web services. What we have done so far is add references to all the environments to the projects and add several using statements to the files that use the services. When we checkout the project, we uncomment the appropriate using statement for the environment we're in.
It looks something like this:
// Development
// using com.tracking-services.dev
// using com.upload-services.dev
// QA
// using com.tracking-services.qa
// using com.upload-services.qa
// Production
// using com.tracking-services.www
// using com.upload-services.www
Obviously as we use web services more and more this technique will get more and more burdensome.
I have considered putting the namespaces into web.config.dev, web.config.qa, etc and swapping them out on application start in global.asax. I don't think that will work because by the time global.asax is run the compilation is already done and the web.config changes won't have much effect.
Since the "best practices" include using web services for data access, I'm hoping this is not a unique problem and someone has already come up with a solution.
Or are we going about this whole thing wrong?
Edit:
These are asmx web services. There is no url referenced in the web.config that I can find.
Make one reference and use configuration to switch the target urls as appropriate. No reason to have separate proxies at all.