I have a REST API providing a service to my users. And I also have a website to allow my users to get some information and register to use the API.
So far, both my website and my API are totally decoupled (2 separate app with 2 separate databases). However, now I need to share information between them.
I think of 2 solutions :
1) Exposing the data I need to share from app_1 through a small API used by app_2.
2) Merging the 2 apps and more precisely the 2 databases.
But I can't decide which could be the best solution.
Thanks
The trend at the moment is to use method 1. Do some research on the Micro Services pattern and that will explain more. This also helps you scale your applications components independently should one have more load than another.
Related
I am new to micro services and I am keen to use this architecture. I am interested to know what architecture structure should be used for systems with multiple customer interfaces where customer systems may use one or many of the available services. Here is a simple illustration of a couple of ways I think it would be used:
An example of this type of system could be:
Company with multiple staff using system for quotes of products
using products, quotes and users mirco services
Company with website to display products
using products micro service
Company with multiple staff using system for own quotes
using quotes and users micro services
Each of these companies would have their own custom build interface only displaying relevant services.
As in the illustrations all quotes, products and users could be stored local to the mirco services, using unique references to identify records for each company. I dont know if this is advisable as it could make data difficult to manage and could grow fast making it difficult to manage.
Alternatively I could store such as users and quotes local to the client system and reference the micro services for data thats generic. Here mirco services could be used just to handle common logic and return results. This does feel someone illogical and problematic to me.
I've not been able to find anything online to explain the best course of action for this scenario and would be grateful for any experienced feedback on this.
I am afraid you will not find many useful recipes or patterns for microservice architectures yet. I think that the relative quiet on your question is that it doesn’t have enough detail for anybody to readily grasp. I will make a wag:
From first principles, you have the concept of a quote which would have to interrogate the product to get a price and other details. It might need to access users to produce commission information, and customers for things like discounts and lead times. Similar concepts may be used in different applications; for example inventory, catalog, ordering [ slightly different from quote ].
The idea in microservices is to reduce the overlap between these concepts by dispatching the common operations as their own (micro) services, and constructing the aggregate services in terms of them. Just because something exists as a service does not mean it has to be publicly available. It can be private to just these services.
When you have strained your system into these single function services, the resulting system will communicate more, but will be able to be deployed more flexibly. For example, more resources &| redundancy might be applied to the product service if it is overtaxed by requests from many services. In the end, infrastructure like service mesh help to isolate the implementation of these micro services from the sorts of deployment considerations.
Don’t be misled into thinking there is a free lunch. Micro service architectures require more upfront work in defining the service boundaries. A failure in this critical area can yield much worse problems than a poorly scaled monolithic app. Even when you have defined your services well, you might find they rely upon external services that are not as well considered. The only solace there is that it is much easier to insulate your self from these if you have already insulated the rest of your system from its parts.
After much research following various courses online, video tutorials and some documentation provided by Netflix, I have come to understand the first structure in the diagram in the best solution.
Each service should be able to effectively function independently, with the exception of referencing other services for additional information. Each service should in effect be able to be picked up and put into another system without any need to be aware of anything beyond the API layer of the architecture.
I hope this is of some use to someone trying to get to grips with this architecture.
I'm trying to install and configure a highly availability setup for the WSO2 API Manager. I've been reading through this document: http://docs.wso2.org/wiki/display/Cluster/Clustering+API+Manager and in there it explains to break up the 4 components of the application into separate folders and that these 4 components can run on a single server. I'm not sure why this is needed. All I really want to do is take 2 servers, install the full application on both of them (without breaking the application up into 4 different pieces) and cluster them together between two servers with an Elastic Load Balancer in front of them.
What is the purpose of splitting up the multiple components on the same server if they all run out of a single installation? I'm looking for the simplest way to provide fail over capability to this application if one server goes down. Any insight into their methodology would be greatly appreciated.
Thanks.
The article you've linked describes on distributing different components of API Manager. If you look at the very end of that article there's a link to clustering configuration doc. In a production deployment usually it is encouraged that the 4 components are run on different nodes rather than having everything in a node and having multiple such nodes. That's why it goes on explaining breaking it down to separate components. The official AM doc below has a page on different deployment patterns.
You can go through the following articles to get a better understanding on clustering API Manager.
http://docs.wso2.org/wiki/display/AM140/Clustered+Deployment
http://sanjeewamalalgoda.blogspot.com/2012/09/how-do-clustering-and-enable-replicate.html
My 2cts:
The documentation mentioned in the remarks, explains how WSO2 sees the world of clustering. Spread the different functionality over different JVM's. This sounds logical from architectural point of view. A dis-advantages is that the diffent applications need to me administrated as well by operations. This makes the technical architecture rather complex.
In our situation, we defined 2 different servers with extra CPU and memory, on these servers we have installed the full WSO2 API Manager and defined the cluster configuration. Everything provisioned via Puppet.
Just a straightforward install, all data-source pointing to one schema in an Oracle database.
And...it is working; Our Developers happy, Operations happy, Architect department happy
This post http://www.theserverside.net/tt/articles/showarticle.tss?id=Top5WSMistakes
encourages me to create the web service for business logic layer but many people use it in the data access layer.
I want to create a project where i want to access the same data repository from a desktop application, website and a cell phone. What would you recommend me?
Is there any case it may be a good idea to implement web services to both layers?
The question is too open ended so the answer is: it depends.
What needs do your applications have for the data? Is it just data access or some business logic involved? If it is just accessing of data, do you really want the client to have direct control over it? How similar are the three applications? Do they share functionality or just data?
As I see it there are two main paths you can chose:
1 - expose a web service for the business, with the data hidden behind the web service. This is a good setup if the three clients (I'll call the desktop app, web app and cell phone "clients" since that is what they are) share functionality (i.e. they are different views for the same business model). This avoids duplicating similar business logic in all the clients;
2 - expose the data directly with a web service. This is a good setup if the three clients have nothing in common but just use the same data for different purposes. But in this case, with the three sets of business logic, where are you going to put the logic? In the clients? How will that work for the desktop application (considering you install this desktop app 300 times or so)? You again need some service and the clients to be thin clients not thick ones.
If you take 1) and 2) into consideration you will see that usually it is better to have a service layer in front of your data.
Going back to the "it depends", analyze your special needs first and only then choose the solution that is best suited for your situation.
How about a point 3? make your data access layer into a library (.jar, .dll or whatever technology you are using) and make that available to the (1? 2? 3?) business web services that serve your clients?
Could someone please direct me to some good documentation or feedback here on what are best practices for implementing web services in an application that handles different concerns? For example, should I create different services, one that handles security, (AuthService), one that handles data-entry for customer service reps, (CRUDService), BillingService and so on or should I just encapsulate all these "services" into one, e.g. ApplicationService? Basically, I am asking if it is bad design to create multiple services (files) within one application. Can some of you note on your experiences or what you've experienced?
Also, let's say three of the listed services from above connect to the same database, but are actually hitting totally different concerns, e.g. one is for all transactions like CRUD, and the other one is for purely reporting purposes. Should I create two services here, one CRUDService and the other for ReportingService? Is it bad to create two different database connections via these 2 services? Or how can I share the same database connection with different services?
I think there is a tendency among publicly available services to just dump everything into one service. Which, may not be a bad idea for a publicly available API. It just makes it easier for developers. However, for any project i work on, i try to break things down into logical groups. This way your client doesn't need to be inheriting functionality it may not need. Updating services would also be a slightly easier task because you're only affecting a certain subset of your web service framework and not everything. So if your service contract breaks and your clients no longer support it, they may still be able to use other parts of your system, but not that particular one. Where as if you break a contract on your aggregated service, everything fails. Finally, if you have to implement something like a fail-over support, you have more flexibility to choose which service requires more fail-over nodes, allowing you to better manage your resources allocation.
If you want best practices take a look to the SOA Design Pattern Catalog
Not having dealt much with creating web-services, either from scratch, or by breaking apart an existing application, where does one start? Should a web-service encapsulate an entity, much like a class does, or should the service have more/less to it?
I realize that much of this is based on a case by case analysis of what the needs are, but are there any general guide-lines or best practices or even small nuggets of information that web-service veterans can impart to a relative newbie?
Our web services are built around functional areas. Sometimes this is just for a single entity, sometimes it's more than that.
For example, if you have a CRM, one of your web services might revolve around managing Contacts. Creating, updating, searching for, etc. If you do some type of batch type processing, a web service might exist to create and submit a job.
As far as best practices, bear in mind that web services add to the processing overhead. Mainly in serializing / deserializing the data as it goes across the wire. Because of this the main upside is solely in scalability. Meaning that you trade an increased per transaction processing time for the ability to run the service through multiple machines.
The main parts to pull out into a web service are those areas which are common across multiple applications, or which you intend to expose publicly, or which would benefit from greater load balancing.
Of course, you need to analyze your application to see where any bottlenecks really are. In some cases it doesn't make sense. For example, if you have a single application that isn't sharing its code and/or the bottleneck is primarily database related.
Web Services are exactly what they sound like Services for the Web.
A web service should be built as an API for the service layer of your app.
A service usually encapsulates an entity larger than a single class.
To learn more about service layers and refactoring to add a service layer read about DDD.
Good Luck
The number 1 question is: To what end are you refactoring your application functionality to be consumned as a bunch of web services?