Hot answers tagged

71

Databases are not very good at information hiding, which is quite plausible, because their job is to actually expose information. But this makes them a lousy tool when it comes to encapsulation. Why do you want encapsulation? Scenario: you tie a couple of components to an RDBMS directly, and you see one particular component becoming a performance bottle-...


56

What is more important and significant about a microservice: its API or its database schema? The API, because that is its contract with the rest of the world. The database schema is simply a convenient way of storing the data managed by the service, hopefully organised in a way that optimises the microservice´s performance. The development team should be ...


42

The usual approach is to isolate those microservices as much as possible - treat them as single units. Then transactions can be developed in context of the service as a whole (ie not part of usual DB transactions, though you can still have DB transactions internal to the service). Think how transactions occur and what kind make sense for your services then, ...


30

Well, there are a lot of ways to learn how to build a RESTful web application and no, there isn't a unique right way. RESTful is not a standard but it uses a set of standards (HTTP, URI, Mime Type, ...). Start with this: How I Explained REST to my wife Then, proceed with this: RESTful Web Services Cookbook And then put your entire effort to develop web ...


30

I think the standard wisdom is to never have transactions cross microservice boundaries. If any given set of data really needs to be atomically consistent with another, those two things belong together. This is one of the reasons it is very hard to split a system into services until you have fully designed it. Which in the modern world probably means ...


25

The Maven file structure may help with this In essence the Spring configuration files (that can have any name by the way, not just the generic applicationContext.xml) are treated as classpath resources and filed under src/main/resources. During the build process, these are then copied into the WEB-INF/classes directory which is the normal place for these ...


17

I think that if consistency is a strong requirement in your application you should ask yourself if microservices is the better approach. Like Martin Fowler says: Microservices introduce eventual consistency issues because of their laudable insistence on decentralized data management. With a monolith, you can update a bunch of things together in a single ...


16

As suggested in at least one of the answers here but also elsewhere on the web, it is possible to design one microservice which persists entities together within a normal transaction if you need consistency between the two entities. But at the same time, you might well have the situation where the entities really do not belong in the same microservice, ...


15

Microservice Architecture is hard to describe but the best way to think about it is a marriage between Component Oriented Architecture and Service Oriented Architecture. Software as a suite is composed of many small business components with a very specific business domain responsibility. Their interface to the outside world either in provided services or ...


13

Java was (and still is) simply the most popular language for the kind of application where the SOA concept is most attractive, i.e. heterogenous distributed and integrated systems with constantly shifting requirements aka "enterprise applications". So everyone was already using Java for such systems before SOA became a buzzword in exactly the same area. As ...


12

Decoupling only works if there really is separation. Consider if you have an ordering system: Table: CUSTOMER Table: ORDER If that's all you've got, there's no reason to decouple them. On the other hand, if you have this: Table: CUSTOMER Table: ORDER Table: CUSTOMER_NEWSLETTER Then you could argue that ORDER and CUSTOMER_NEWSLETTER are part of two ...


12

I've encountered this before (many times) and what I've ended up doing preferring is: Take the BL out of the website. Make the website a consumer of the API. Treat the website as just some other client of your API. Your API IS the service. If you find yourself thinking that you need special API methods just for the website, think again! If its good for ...


12

I was part of a team that successfully built a microservices architecture using a service bus. Initially, we believed that microservices and an event driven architecture would enable us to fix the underlying shared data ball-of-mud database. What we learned was that microservices and an event driven architecture required us to get rid of the underlying ...


12

Service Providers, doing only one thing The core difference, which has widespread consequences of the project, is that with Microservices these Service Providers are independently deployable and scalable. This is great, because you can be more agile. If a service needs changed, you just change that one, none of its kin. If you want to try a new framework ...


11

The difference may be subtle between both. For example in .NET world, you may have an application which would feel like monolithic to an end user and which will work on a same machine, but inside, would be separated into a bunch of WCF services. You may also have architectures where libraries are not strongly linked (addins/plugins) and are just following a ...


10

Are your web services individually deployable? Individually scalable? Individually monitored? Microservices are just more granular (and decoupled) varieties of the web services most places have to provide a little more control on the Ops side of the world. Is that useful for you? Maybe. Maybe not. Different solutions have different needs, and if your ...


10

Never over architect from the get-go. You will spend most of your time on the architecture and not the actual business case you are implementing. (This is especially true if you are trying out a new architecture approach, like micro services) When I start out with something new and especially something that I have no idea if anyone will ever use, I always ...


9

Another advantage of services is that when you update the service, it is immediately deployed to all consumers of the service. So if you fixed a bug, or performance issue, everyone gets the benefit as soon as the updated service goes live, instead of having to distribute an update that people may choose to ignore.


9

Not allowing "direct database access" from an application allows the underlying database, and even the schema, to change without having to change the client applications. Clients simply code to the service interface, never needing to know how the data is persisted.


9

What exclusive traits Java has that other languages/platforms don't, that makes it so popular for SOAs? There's nothing much in Java itself that makes it especially suitable for SOAs. Sure, it offers garbage collection and dynamic code loading and the like, and they're all useful, but they're hardly unique features of Java. What did make a difference ...


9

I'm not sure what you mean by "one and only one software!" but I think you may be reading too much into this document. Since it talks about what not how, it sounds much more like a high level requirements document for a system and not a single application. This is actually a very important document for any large project. I'm sure that if you were to look ...


8

Where I work we have an ESB to which 6 different applications (or should I say "endpoints") are connected. Those 6 applications work with 3 different Oracle schemas on 2 database instances. Some of these applications coexist in the same schema not because they are related but because our database infrastructure is managed by an external provider and ...


8

Library Advantages: Lower overhead per call (only jump or even inlined) = may increase performance Simplest thing that could possibly work No risk of centralized service going down and impacting all consumers Service Advantages: Everyone gets upgrades immediately and transparently (unless versioned API offerred) Consumers cannot decompile the code Can ...


8

I've seen the worst possible nightmares in software architecture due to data integration, and the best weapon against this type of mess that I've encountered so far id DDD-Style Bounded Contexts. Which is not very far away from "SOA done right", on a certain sense. However, data itself is not the best way to attack the problem. One should focus on the ...


8

Because <5% of code is actually defining a service, and I would argue a substantially less amount of time. Once the interface is defined, it's largely done. The rest of the time is spent in OO (or alternatives) making things work. Simply put, it's not a big win to make a specialized language for that small slice of the problem. If anything, having two ...


8

From a developer's point of view, you are right in saying that these "visual" environments are really hard to work with. SharePoint 2010 Workflows, which I use, throws out every best practice around creating good enterprise software - no automated testing, no code reuse, unreadable software... Anything more complex than an out-of-the-box template can be ...


7

Unfortunately there is no such thing as "the standard solution", so you have to figure out what your requirements are and from that choose the option that fits best. Here are few options. For a network application integration perspective SOAP over http might be the best(laborious but transparent) way to find a means to create the integration. The windows ...


7

Decoupling databases and keeping the data consistent between them is an expert level task. It is very easy to get wrong and end up with the problems of duplicates etc, that the current system is designed to avoid. Frankly, taking a working system and doing this is pretty much a guarantee of introducing new bugs for no real value to the users.


7

There is only one real benefit, yet its huge: Separation of Concerns. So, instead of process orchestration logic being embedded in our system, it becomes and external configuration. A map, basicly. You can change it (much more) independently, you can have multiple processes, multiple versions of processes, multiple versions of multiple processes running at ...


7

OOP is a programming paradigm. SOA is a system architecture concept.SOA can be implemented using OO code (or any other type of coding, it does not matter). OOP can be part of a SOA architecture or can be used outside of that architecture. OO and SOA are two different concepts (level wise). We could for example compare SOA based architecture to non-SOA based ...


Only top voted, non community-wiki answers of a minimum length are eligible