I'm look for some guidance or best practise for how to configure and structure an Application which conforms to Hexagonal architecture that supports multiple (driver) adapters simultaneously.
My API / Application Layer / Ports represent the boundary of the Application. I am now writing the driver adapters, with the goal that the application supports both a console / CLI adapter and REST adapter in tandem.
Does anyone have any thoughts on approaches to the Main Component that configures and wires the application together?
A single Main Component that configures the full application: including all primary adapters. Along with loading the application configuration. In this case it would start the REST services and start the CLI console app.
A separate Main Component for each type of Primary adapter. ie. One for the REST application. One for the CLI / Console application. My concern is will result in a lot of duplication for configuring the Application within the boundary (ie. the API Services, Repositories, etc etc).
Follow the above approach but extract the common configuration / wiring into a shared class.
If anyone has any examples they could share that would be interesting to see.
Cheers,
Steve
This is an interesting question.
From my point of view, trying to be faithful to the pattern explained by its author, although it would also be posible to run more than one driver adapter for one driver port, the "app as a whole" (let's call it system, since the app is the hexagon) is an instance of a driver adapter running on each driver port of the hexagon, and a driven adapter implementing each driven port.
The configuration of the system is the adapter to select for each port. When you run the main component, you have to specify which adapter you want for every port.
That said, I studied two approaches in order to run the system:
(1) To have an additional component (name it main component, composition root, startup, init, or whatever you want) that instantiates the driven adapters and the hexagon, and finally instantiate the driver adapters and run them. This way, the system architecture would look like an app container in the driver side, and a plugin architecture in the driven side.
(2) To run each driver adapter on its own. It is the driver adapter that starts the game, asking the hexagon for a driver port instance, and the hexagon would ask every driven port for a driven adapter instance.
So to your question about the main component in your example, according to my approach (1), I would have two hexagon instances running, but you could have just one, I don't see any problem on that.
I wrote a theorical article about hexagonal architecture at https://softwarecampament.wordpress.com/portsadapters/ , and now I'm working on an article about how to implement hexagonal architecture, and a code example.
Related
I´m currently looking for a solution to write a JSF application inside a Desktop app.
I think I can use:
Start Main function
Start SWING application
Start JAVA EE application server
Start database (e.g. H2 database)
I found the following solution with Tomcat:
https://www.beyondjava.net/how-to-wrap-bootsfaces-or-jsf-in-general-as-a-native-desktop-application
This is exactly which I would like to have. The only problem is, that Tomcat needs approx. 20 seconds to start.
Is there any other Application server which I can integrate like this in the Main class which will start than the Web application inside the SWING Gui?
Many thanks
In general, putting a full-fledged JavaEE application inside of a desktop application is a bad idea. You have only one user working on a local machine, and the JavaEE platform is intended to be used in a concurrent environment to process multiple parallel requests coming from different clients over the Internet. A lot of facilities and trade-offs inside the JavaEE platform are implemented to support this. Using it to serve a single user on their local machine is like hammering nails with a microscope.
This is also a clear contradiction between your goal (quick startup of the desktop application) and trade-offs of a JavaEE application (the startup time doesn't really matter so much, as restarts happen rarely).
It's also worth to say that Tomcat is not a JavaEE server, as it doesn't provide the full JavaEE implementation. Although you definitely can run JSF applications on it by providing a JSF implementation inside the application itself.
If you really want to proceed, you could take a look at jetty as a somewhat faster alternative to Tomcat.
I am starting research on how to implement Node.js SOA (service oriented architecture) with JSON web-services.
As a small sub-question, I need an approach/framework/system to make universal configuration center for all companies web-services. So that we don't configure every application with exact address of other application, but just link to some central server to get that information.
(This should be very well worked-out topic for XML-based services, so some terminology/approaches/etc could/should be borrowed.)
Related to
RESTful JSON based SOA Registry
Service Oriented Architecture suggestions
UPDATE: This questions is about web-services configuration & orchestration.
GO for an active(having activity happening off late) framework with lean architecture.There's one called Geddy and another called Restify. If in doubt, Express can also be used for building webservices with JSON.
You can work on reading the centrally stored config from different app codebse when you use any of these.
Just started with NServiceBus and I am trying to understand how the bus fits into my VS solution.
Let's assume an existing application, that has an ASP.Net front end and a BLL. I am using Windsor for DI and my BLL has no knowledge of the container. I wire the container up in a separate project I call "MyNamespace.IOC", and only this project and my web project have knowledge of Windsor.
I need access to the bus in my BLL (since that is where I will be sending/publishing/handling messages). I need to configure NSB using Windsor, and (I think) pass an instance of my container to the Configure.With().CastleWindorBuilder() method at app startup.
It seems odd to have all three projects have reference to the NSB DLLs. How does one normally wire this all together?
If you do not want to reference NSB in your BLL / domain layer you could have a look at 'domain events'. The domain event handlers can sit in their own implementation layer leaving your domain ignorant of the handling of the events and, therefore, requiring no knowledge of the service bus. From there you could publish your esb messages. It may not seem like much of a difference but the domain event-handling layer is more isolated from the domain.
Just as a side-note: since you are starting out with a service bus you could also have a look at my FOSS project over at http://shuttle.codeplex.com/ --- any feedback would be appreciated :)
You can abstract bus behind some interface and provide the implementation only in IoC and Web projects.
Is there any way to override Win32 File API such as CreateFile()? I want my app to see a virtual file solely for my app, however, the virtual file does not exist actually.
There exist two approaches - with a kernel-mode driver (documented one) and without such driver (a hacky way).
With a kernel-mode driver you have two ways - (1) create a virtual filesystem driver (or take existing one) and (2) create a filesystem filter driver (or take existing one). Driver development = a year or so of work to do right and completely. Driver development is fully documented in MSDN.
Without a kernel-mode driver you need to employ API hooking. Libraries such as Detours, MadCodeHook and Boxedapp SDK do this (and let you do this as well).
Hooking an API topic is quite large to describe it here fully, but there's a good CodeProject article on this topic.
System-wide? Bad idea. If it's just your app, don't use the standard APIs and implement it yourself. But if the data must persist between sessions, you'll have to store the data somewhere (file, registry, etc.).
I am trying to write some simple Java web services so we can call Java code from .NET. So far, I got a proof-of-concept working under Glassfish. Pretty straightforward when the IDE does all the work.
Now I'm really bogging down on stuff in Java that should be really simple. For example, I want to externalize my configuration so I can change stuff like connection strings/usernames/application variables/etc without recompiling.
In .NET, you would just stick some strings in the web.config file in the root of the web site and use: ConfigurationManager.AppSettings["whateverIwant"];
I can get java.util.Properties to do what I want (from a standalone client), but I can't figure out where to put the .properties file and how to get the path to it from within the web service.
I need my approach to work within WebSphere Application Server as well. Thanks!
As others have mentioned, it greatly depends on the container, but almost always dynamic configurations are stored in a database instead of XML or .properties files.
As I see that this is just like a proof of concept, here's a quick and dirty solution: (don't do this for production code) use System Properties.
Disadvantage: with every change you need to reboot the container, but you don't need to recompile the app.
To use system properties in Glassfish you can go to the section "Configuration -> System Properties" and add properties there. Then from inside your application just call
String myValue = System.getProperty("myProperty");
To get the value. All java applications support these properties, but I don't know how to configure them in Websphere.
Alas, Java EE has a giant hole in the head when it comes to application configuration.
Your best bet is to either:
use JNDI to store config in the application server environment. This is hard to do portably, painful, and an absolute nightmare for the user to do any configuration. Configuration UI depends on which app server and version is in use and may be a command-line-only utility specific to that app server.
Use the Preferences API to store your configuration, and produce your own UI to edit it. This is OK ... except that you can't control when your settings are flushed and re-inited. Some app servers will do this when your app is re-deployed, which you probably don't want.
All in all, the situation absolutely stinks. There's no clean, sensible way for an app server to provide an app with a simple properties map and UI to edit it using the app server's admin tools.
I tried to work around this using web context parameters, but found that they too were buggy. Glassfish was ignoring more than the first web context parameter that was being set, and they were hard to access without having a servlet context so you couldn't really get to them easily across the whole app.
If anyone has a better answer I'd love to hear it, because the situation as it stands seems downright amazing for a spec that's been through several major iterations.
see also: Storing and editing configuration for Java EE applications
Application configuration is unfortunately container dependent. In general you access your configuration through JNDI. The approach I've recently used was the following:
Make a database available to your app (through JNDI, use the Glassfish database "wizard"). This is part is container dependent.
Create an entity bean that deserializes your settings from the database. The simple solution here is to have something like this:
#Entity
public class Setting {
#Id
private String name;
private String value;
...
}
Then it's a question of doing em.find(Setting.class, "whateveriwant").getValue(). Alternatively, you could create a single entity bean with all the settings as attributes.
Either way, this approach reduces the container dependency to a minimum.
The best solution I've found so far is "EAC4J (External Application Configuration For Java)". I've used successfully in many projects.
Put the following code in the contextInitialized method of a ServletContextListener:
ServletContext sc = sce.getServletContext();
Properties systemProps = System.getProperties();
String path = sc.getRealPath("WEB-INF/application.properties");
systemProps.load(new FileInputStream(path));
This reads from application.properties from the the WEB-INF folder of your web app when it starts. This will require a restart every time the configs change, but in my opinion, that is as it should be.