I work for a polygot organisation where we code in multiple different languages and architectural styles.
I have been writing Service Orientated Application's for around two years now, and have gotten comfortable with the way I do things, and that's the problem.
At the Big SOA level we all agree on how to use SOA principles to connect different pieces of the solution/enterprise.
At the component level we all differ slightly;
Currently I take the every high level component as a service approach to SOA, favouring capability driven interfaces and softeware fortresses. Be the implemenation beans or wcf services the pattern remains unchanged.
Like so, SOA Design Pattern
Others in my organisation opt for the rich domain model of standard classes underneath a facade.
Architectural styles like SOAP, REST have both been used at this level.
We also differ in the style of method call, command style messages vs more activity descriptive messages.
I have used both and am happy with either, my question are there other methods are other engineers using to compose their SOA.
I am interesed in new ideas, how ever wacky, to stimulate new ways of thinking around the topic of building a SOA.
I spent awhile building up a components-based approach to SOA called SoaKit that might be helpful. See http://bradjcox.blogspot.com for rationale.
The basic idea is to avoid tools-based approaches (JAX-WS) in favor of a suite of pre-built components (provided by SoaKit) that each do commonly-needed functions and can be snapped together easily to do the whole job. Example components: add SAML signed header, decrypt/encrypt message parts, XSLT/XQUERY transforms, and so forth and so on, with each such component independently configurable.
If an enterprise is a city, a service is a house in that city, and SoaKit components are bricks for building houses. The blog has articles that contrast that with the mud-brick approach commonly used today. The analogy is to evoke the impact Roman brick architecture brought to building construction, seeking to bring the same impact to software.
Hope the notion is helpful. Shelved the idea because the world seemed bent on monolithic magic push-button approaches (JAX-WS) that are nearly impossible to control or understand. That's been my experience with JAX-WS/Metro and WSO2 at least.
Related
CakePHP Applications being made in our company tends to become unmaintainable as it becomes more complex. I figured that one specific reason is inheritance which makes the functions in child classes depends a lot on it's parent classes and vice-versa (implementing template method pattern). Why is CakePHP designed this way and not friendly in using Dependency Injection, Strategies, or Factory patterns?
There is not such a bad design as you claim in the framework. Sure, there are probably things that could be done better but I would like to see a more substantial critic including solid arguments and examples. I assume you're not using the framework as it was intended.
Let me quote the first paragraph from this page.
According to Eric Evans, Domain-driven design (DDD) is not a technology or a methodology. It’s a different way of thinking about how to organize your applications and structure your code. This way of thinking complements very well the popular MVC architecture. The domain model provides a structural view of the system. Most of the time, applications don’t change, what changes is the domain. MVC, however, doesn’t really tell you how your model should be structured. That’s why some frameworks don’t force you to use a specific model structure, instead, they let your model evolve as your knowledge and expertise grows.
You're not showing code (for a reason?) so I guess your problem comes from stuffing everything into the table objects in src/Model/Table/ or doing something similar.
But you're totally free to create a folder structure like
/src/Service
/src/Model/Domain
and then simply instantiate services as you need them in your controller actions. A service could be for example \App\Service\User\Registration and using objects from App\Model\Domain\User.
I agree that the framework in fact doesn't provide any recommendation or template structure for how this could look like. For exactly this topic there is a discussion going on here. Because of a lack of such a structure I've started working on a plugin that provides this. The plugin doesn't require but suggest the usage of DI containers for the people who want them.
Given the whole fancy topic around DI and DDD so far I would say there is not the one way to get things right but different paths as long as the code is easy to maintain. And honestly, as long as this goal is archived I really don't care about how you call it. :) I think many people tend do make this topic to academic instead of simply trying to be practical.
Not everybody is even needing that structure. It depends on if you're building a RAD CRUD application or a more complex app. Not every application needs a DDD approach. There are so many shades of gray when it comes to design the business layer, no matter how the framework would do it, somebody would always complain about it.
I personally almost never missed a DI container in CakePHP, not even in the biggest project having more than ~560 database tables which was a hospital management solution and it just worked well.
I would suggest you to ask a more specific question about your approach how you structured your code and showing your structure and code and then asking for advice on how to improve it instead of blaming the tool you're using in the first place without providing context.
Unfortunately CakePHP v3 can not compare to the Zend3/Laminas, Symfony or Laravel.It is 7-8 years behind the other frameworks.If you are using cake for years or it is your 1st and last framework it is normal to not realise that.But if you have to use it after Zend 3... cake seems like really bad ecosystem.
Bad documentation
Bad ORM
Poor Routing system
Bad Templating engine
Bad idea to mix Data Mapper and Active Record
DIC is totally missing
Components - not good but not terrible
...
And many more thinks that should not be underestimated like - lack of GOOD tutorials, pluigns/addons/packages
The above thinks make developers to follow bad practices that adds a lot of technical depth.
If you care just for - it works! But not how it works and why it is bad, cake will fit ok for you.
Cake can not scale as good as Symfony/Laminas if you are doing big project.(yea AWS/GC can help for scaling a lot of thinks but not for scaling source code)
Cake doesn't allow you rapid development like Laravel/Symfony for decent project.
I'm wondering who and WHY would start a new project today using Cake as it has zero benefits over the other frameworks.
Probably only devs who used only Cake for last decade and do not want to start learning new technologies or devs that thinks SOLID is just a fancy hype with zero benefits like design patterns, DRY and KISS
CakePHP framework supplies user interaction with databases using Active record, it means that exist a high coupling between business layer and database layer which has negative effects in unit testing and because of that the framework is not friendly with Dependency Injection. The same issue happens with Factory pattern, high coupling mentioned before makes more difficult use simulated objects in unit testing.
Hope it helps!
Alberto
I am developing an SOA project using principles I learned in Udi Dahan's Advanced Distributed Systems Design course. So far the project has 6 completely independent services, as well as an IT/Ops service for aggregation and integration with third party services. I also have a set of libraries I've developed for use across all of these services with infrastructure code, i/o, and utilities.
Is it better to keep these services' code together under one solution, or to keep them in entirely separate solutions? Or both? Integration testing will be much simpler with one solution, but I'm concerned with service encapsulation - my gut tells me I don't want a developer working on one service to know how another service works, because it can lead to unintentional coupling. Has anyone run into real-world issues with service encapsulation when keeping all codebases under one solution?
I would keep the services in separate solutions or even separate repositories.
I don't think it has anything to do with service encapsulation, but more to help deal with code contention better and make it hard to take dependancies between services.
As for common code (like contracts) put them in a separate repository and use nuget (or similar) to reference form your solutions.
Make sense?
Aspect-oriented programming is a subject matter that has been very difficult for me to find any good information on. My old Software Engineering textbook only mentions it briefly (and vaguely), and the wikipedia and various other tutorials/articles I've been able to find on it give ultra-academic, highly-abstracted definitions of just what it is, how to use it, and when to use it. Definitions I just don't seem to understand.
My (very poor) understanding of AOP is that there are many aspects of producing a high-quality software system that don't fit neatly into a nice little cohesive package. Some classes, such as Loggers, Validators, DatabaseQueries, etc., will be used all over your codebase and thus will be highly-coupled. My (again, very poor) understanding of AOP is that it is concerned with the best practices of how to handle these types of "universally-coupled" packages.
Question : Is this true, or am I totally off? If I'm completely wrong, can someone please give a concise, laymen explanation for what AOP is, an example of a so-called aspect, and perhaps even provide a simple code example?
Separation of Concerns is a fundamental principle in software development, there is a classic paper by David Parnas On the Criteria To Be Used in Decomposing Systems into Modules that may introduce you to the subject and also read Uncle Bob's SOLID Principles.
But then there are Cross Cutting concerns that might be included in many use cases like authentication, authorization, validation, logging, transaction handling, exception handling, caching, etc that spawn all the layers in software. And if you want to tackle the problem without duplication and employing the DRY principle, you must handle it in a sophisticated way.
You must use declarative programming, that simply in .net could be annotating a method or a property by an attribute and what happened later is changing the behavior of code in runtime depending of those annotations.
You can find a nice chapter on this topic in Sommerville's Software engineering book
Useful links
C2 wiki CrossCuttingConcern, MSDN, How to Address Crosscutting Concerns in Aspect Oriented Software Development
AOP is a technique where we extract and remove the cross cutting concerns (logging, Exception handling, ....) from our code into it’s own aspect. leaving our original code focusing only on the business logic. not only this makes our code more readable, maintainable but also the code is DRY.
This can be better explained by an example:
Aspect Oriented Programming (AOP) in the .net world using Castle Windsor
or
Aspect Oriented Programming (AOP) in the .net world using Unity
AOP is about crosscutting concerns i.e. things that you need to do throughout the whole application. For instance logging. Suppose you want to trace when you enter and exit a method. This is very easy with aspects. You basically specify a "handler" for an event, such as entering a method. If necessary you can also specify with "wildcards" which methods you are interested in and then it is just a matter of writing the handler code, that could for instance log some info.
Aspect Oriented Programming is basically for separating the cross-cutting concerns (Non-functional) and develop it as aspects, like, security, logging, monitor etc., kept it aside whenever you need in your application, you can use it as plug & play. Only benefit we can achieve is clean code ,less code and programmers can focus on business logic(core concerns) , so that better modularity and quality system can be developed.
I am going to use Entity Framework and WCF in my application. The suggested practice, as I saw, is using POCO with Entity Framework and also using POCO classes as DataContracts. That is actually what POCO and Attributes are used for, -if I am not wrong.
However I am asked to use seperate classses for Entity Framework POCO's and WCF DataContracts. And to use a mapper between POCO's and DataContracts. Like, Foo and FooContract with same properties.
I am on the first approachs side but I wonder if the second approach (seperate classes approach) provides flexibility to the application or is it just a waste of effort.
I will be grateful if you can share your thoughts and experiences about using seperate classes for POCO and DataContracts, pros and cons about that.
Having separate classes for your POCOs and your Contracts will allow you to create Message Oriented services rather than RPC Style services.
Having Message Oriented services will allow your services to be more flexible, do more work, and be less tied to the objects that each service uses.
Message Based services also fall more in line with the spirit of Service Oriented Architectures. You can read more about Message Oriented services at Wikipedia.
I would also suggest picking up Service-Oriented Architecture: Concepts, Technology & Design by Thomas Erl if you are interested in the principles behind good service design.
Having different data classes at persistence layer and contract level gives you the most flexibility. For example, you may not want to expose all your persistent fields over a contract or you may want to expose different hierarchy of data over a contract etc. It also allows to change both independently of each other.
It may seem at first that using different classes at both level is duplication - but over long term, efforts are not so much (compared to flexibility that you get). You may get tempted to use same classes and develop different one when need arises but issue with that approach is that within short time frame, your services get tightly coupled with data classes rather than information/data that services should be exposing/working with.
I agree with #JustinNiessner and the best guidance I have found for architecting .NET applications using SOLID principles is a series of posts by .Net Junkie and the associated codeplex project. Clearly stated and informative, well worth reading.
I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!
We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.
Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?
I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.
You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.
From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.
The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.
There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.
First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.
In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.
Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.
Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.
Here is a good blog to get started: http://blogs.msdn.com/dsimmons
CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.