I recently started a side-project. It was supposed to be a virtual recipe-book with the capabilities to store and retrieve recipes (CRUD), rate them and search through them. This is nothing new, but i wanted to build it as a desktop application to learn more about databases, unit testing, UIs and so on. Now that the core domain is pretty much done (i use a DDD approach) and i implemented most of the CRUD Repositories, i want to make this a bit more extensible by hosting the core functionality online, so i am able to write multiple backends (desktop application, web application, web api, etc).
Service Oriented Architecture (or Microservices) sound like a good approach to me to do that. The problem i am facing is how to decide, which parts of my project belong into a separate service and how to name them.
Take the following parts of the project:
Core domain (Aggregates, Entities, Value Objects, Logic) -> Java
Persistence (DAOs, Repositories, multiple Database backend implementations) -> Java
Search (Search Services which use SQL queries on the persistence DB for searching) -> Java
Desktop Application -> JS (Electron) or JavaFX
Web Application -> Flask or Rails
Web API (Manage, Rate, Search for recipes using REST) -> ?
My initial approach would be to put the core domain, the persistence, the search and the web api into a single sub-project and host that whole stack on Heroku or something similar. That way my clients could consume the web interface. The Desktop and Web apps would be different projects on their own. The Dektop app could share the core domain if they are both written in Java.
Is this a valid approach, or should i split the first service into smaller parts? How do you name these services?
Eric Evans on GOTO 2015 conference ( https://youtu.be/yPvef9R3k-M) and I 100% agree with him, answered to your question. Microservice scope should be one or maybe more Bounded Context(s). Including its supporting classes for persistence, REST/HTTP API, etc.
As I understood, the microservice is deployment wrapper over Bounded Context, with adding the isolation, scaling and resilient aspects.
As you wrote, you didn't apply Strategic Design to define bounded context. So its time to check, before tearing the app to parts.
Related
I have been getting a bit lost in the creation of my program architecture and I want to take a step back to see if I'm approaching it correctly.
I am wondering if my setup makes sense. I'm starting to think it doesn't.
I am creating intranet applications (We were creating Internet applications, but now the scope has changed). We use an onsite Active Directory (Windows Server 2012 R2). We have a SQL Server Database.
I have been building Front End Angular applications and ASP.NET Web API's to push and pull data. I am now implementing Authentication with Auth0 and it's been a nightmare.
What kind of program architecture would you setup in this scenario?
Much Appreciated.
SQL Server + Asp.Net Web Api + Angular JS forms a perfect architecture for building Single Page Applications (SPAs). This architecture is useful for building desktop like web applications, i.e. apps that runs over web but works like desktop apps.
If you can be more specific about the problem you are facing, you will be able to get better recommendations from so.
This architecture is widely adopted in many scenarios such as SPAs. With it, you will be able to keep your front-end highly decoupled from your backend services being able to support multiple front-ends on the same set of services and run quite a few integration scenarios.
Some of the downsides of such an approach will be the extra layer of complexity added to the application (which might force you to write more tests and handle different failure scenarios that wouldn't happen otherwise, for an example) and authentication routines since you will need to authenticate two heterogeneous environments (the .NET/IIS one and the JS/Angular one).
As for the authentication pain, token-based auth schemes seem the current way to go (such as Auth0) since they let you keep and send an environment-agnostic token which will be used by different layers of your architecture.
In that sense, your architecture makes sense.
However, since you're feeling some pain in its implementation, you might want to ask yourself if you really needed all of these. When you choose an architecture, you do so trying to accomplish some specific goals (multiple front-ends? specific performance requirements? maintainability? auditability?) and the more goals you try to accommodate in your architecture the more complex will become up to a point where the pains start outweighing the benefits.
So, what were you trying to achieve in the first place?
I want to know the difference between multi-tenancy and single tenancy.
Is tomcat supporting mutli-tenancy .Can you explain both with an example.
I am asking this question in context to http-servers.
Definition
From Wiki definition
In a multitenancy environment, multiple customers share the same application, running on the same operating system, on the same hardware, with the same data-storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data.
So you can imagine that single tenancy is the other way around.
Example
Let's take JIRA as an example,
If you use OnDemand JIRA Service, it is multi-tenant, cloud-based service.
If you download JIRA Standalone and install it for you organisation. It is single tenancy case.
Designing multi-tenancy software
Designing multi-tenancy software is nothing to do with the hosting technology. It's actually about the way you architect the software.
Tomcat in your case, is absolutely suitable for multi-tenancy software.
I am trying to implement modular design in an asp.net project dividing the application into different modules like HR, Inventory Management System etc. Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Up till now I thought this as a common practice for developing Management systems and ERPs but I am searching the web for last three days but hardly found any help full stuff regarding developing modular applications. Most of what I found is mere theory explaining the concepts of cohesion and coupling but not real world scenarios. So I wonder
Is it the right approach of separating modules?
How the real world modular applications are developed?
How should the different modules communicate with each other yet they stay independent of each other.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
Any thoughts, links are warmly welcome.
This is a personal opinion and is debatable.
I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
Sounds like a total overkill. Abstraction over abstraction makes your application pain in the neck to maintain, support, and enhance. Is it that large that you need to separate modules into separate solutions?
Is it the right approach of separating modules?
No, I think it is a total over-engineering. I would suggest using projects to separate modules. And not separate solutions. The problem with solution is that it will require external dependencies management tool, which requires a lot of effort to bring in and later maintain.
How the real world modular applications are developed?
Using abstraction (interfaces and abstract classes) and separate projects.
How should the different modules communicate with each other yet they stay independent of each other.
By using interfaces, DI, IOC, TDD
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
Core does not communicate with modules. In fact it should ideally not depend on any other project/library. This makes it simple to reference and use in large solutions.
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I would highly recommend using a single copy from the Core project. See this questions for details of why.
This is one of those topics that is entirely subjective for the most part, but you may wish to consider a SOA (Service Oriented Architecture).
Using SOA, you can define a service (for this example, I'll stick to web services, though other service types exist depending on requirements) for each business area - an HR web service, a projects web service, a finance web service and so forth.
You can then bring all these together with a front end system that will communicate with and utilise these services, that would normally be your core application, though depending on your needs and requirements you may opt for multiple front end systems.
For the front end system I would recommend using ASP.NET MVC which has the concept of areas and will let you separate the front end into specific areas - an HR area, a projects area, a finance area and so forth that will contain the models and views for each specific area.
Doing this will let you build in a modular manner, you can build your first web service, say, the HR web service, that has methods for getting relevant HR data and so forth, and then build the HR area of your MVC application. Expanding then simply depends on building the web service, and creating the front end in the MVC application. There is nothing stopping say the HR area then accessing the finance web service if it needs finance information, but it still keeps everything in distinct independent modules.
Using this method can also be helpful in aiding future interoperability - it may be that other systems in the company will find it useful to interact with certain web services. For example, in a previous role it was useful for the companies engineering software to integrate with the projects team web service as it allowed for engineering related information to be linked to it's related project.
If the system grows in terms of resource requirements it should also be fairly scalable as it is trivial to say, offload the projects web service to another service if it starts eating a lot of system resources. It also allows you to switch modules out if need be - if you ever decided to move to say, a Linux/Java platform, you could trivially move by porting module by module with no real interruption of the overall system.
But of course, as I say, this is simply one such option and much of it depends on the specifics of your circumstances.
It is too late to answer but it seems interesting.
Since I am trying to keep different modules independent of each other, I separated these modules in such a way that each module is a separate Visual studio solution having UI, BLL, DAL and even a separate database schema.
It depends on your scale of application. If you create a very small-simple application with a little functionality, then it is safe to has a combined assembly. Or if you want, just separate the UI with other module. At least it can help you to emphasize SOC. Keep in mind that loading multiple assembly can be slower than a single assembly.
Is it the right approach of separating modules?
Module separation always has a drawback, that it is require mapping. It means slower performance in general (maybe negligible, but still there is), and slower development time. If your application will be large and complex enough, it is worth it, since you can create modular unit tests for each module.
How the real world modular applications are developed?
No exact practice though, every problem needs a solution. You won't need a heavy multi-threading or dependency injection architecture for a simple calculator application.
How should the different modules communicate with each other yet they stay independent of each other.
Using interface. You can make the implementation different later on. Example is, you currently use C# Winform for your application, communicate to the BLL using interface. Later on, you want to migrate to ASP.Net, then you just change the implementation, but keep the interface to communicate with the BLL the same.
I think there should be a core application which makes use of these modules, how should the core application communicate with these modules?
There is some data, entities , objects which are common to each module, should I put them in the core modules in order for other modules to use them (I think this will make the modules coupled to core) or should every modules maintain its own copy of data + define those object, (which I think voilates DRY)
I assume it is an enterprise level application which share the same modules / data such as employee. If it is really need to behave uniformly, then you should provide the very basic logic at the core Level. At the application / implementation level, you may has different implementation to fulfill each requirement.
Do not force to uniform all of the business logic to the core. If a specific application need a different implementation, it is hard to make the core configurable.
What is Oracle ADF?
On the Internet I found the following definition:
ADF integrates a mix of subframeworks to provide the key functions for
object-relational mapping and other forms of service access, data
bindings, and user interface, along with the functional glue to hold
it all together. ADF stands for 'Applications Development Framework'
and it's developed by Oracle. ADF is a framework and it'll help you
build your applications easily as many of the redundant things that we
do while we develop our applications are taken care by the framework.
But I still have a couple of questions with respect to understanding ADF:
ADF is an extension to the Java EE Framework, and can things that can be done using ADF (including SOA Development) be done by normal Java EE programming? (Please correct me if I am wrong.)
Is it mandatory to learn ADF for doing SOA applications?
It is a web development framework based on JSF. But heavier!!
If you plan doing web development with this, be warned that this framework is not very flexible. It feels like developing web software as in the 1999 with Visual Studio!!
You build everything in the Oracle IDE JDeveloper (incuding UI!) drag and dropping UI widget already made... If you can live with the default look and feel and do not want to include popular JavaScript libraries (jQUery) you should be fine. For example, building intranet applications could be OK. But if you want to do a public web application (Internet) I would not recommend this framework!
ADF is actually 4 "parts":
ADF Business Components is a declarative, meta-data based object relational mapping solution. It provides robust database read/write/update capabilities without the developer having to use Java (hence declarative) though the framework scan be extended with Java to add custom behavior.
ADF Model is a binding layer to bind the UI (ADF Faces based on JSF) without tight coupling UI components to the back end data model.
ADFController implements task flows, an advance on JSF page flows that allow you to break your application up into reusable sets of pages, called task flows, declarative transaction management.
ADF Faces is based on JSF and built on top of Trinidad, an open source JSF framework.
Yes, you can do almost everything ADF provides (not ADF C) in custom Java EE code. But it's a framework - it handles a lot of the repetitive, predictable, redundant code. Also, one can argue that once learned, you can be more productive in ADF than hand coding Java EE applications.
Oracle adf allows you to develop mvc applications that can support enterprise needs mainly.
There are few specific things that you must consider here:
entity objects
These are the core elements of database interaction. They correspond with model layer and business services.
I.e.business logic is implemented here.
view objects
These are the elements that are considered as display elements.
View objects can be updatable or read only.
Updatable view objects are derived from entity objects as any changes in the view objects will reflect in entity object and then reflect in database.
Read only view objects can be developed using standard SQL queries.
application module
These are the core parts of any adf application as they include the view objects those need to be displayed.
Any view that needs to be displayed must be added to application module.
It can also be used for testing the business services as business services need to be validated for correct results before attaching them in the view part.
SOA (Service oriented architecture)
This helps you to develop web services using BPEL language and java .
These web services contain business processes which can be used in adf application which further describe any enterprise application.
Pros:
you can develop enterprise applications really fast as all the operations on the database tables are provided to you in data models itself.
rich set of UI components which can interact in various ways.eg. panel splitter, panel tabbed, decorative box etc.
web services can be consumed within adf easily.
it makes the development faster.
Cons :
heavier compared to other alternatives.
cannot use popular JavaScript libraries like jQuery, Ajax etc.
UI components look too old compared to latest frameworks like Bootstrap,jQuery etc.
ADF just makes development easier.
Yes, you can still develop what you need using the regular Java EE framework
It is not mandatory but it might make your life easier and your development time shorter
Please read http://www.oracle.com/technetwork/developer-tools/adf/overview/index.html
There's also an ADF overview video which may help you understand this technology better.
Oracle ADF (framework) + Oracle Jdeveloper(IDE) make web application very easy and in rapid way.
1.Oracle ADF is a framework on top of JEE stack.
2.it's not required.but if you want to work with oracle SOA suite yes it's required
You can think of ADF as an enhancement to standard Java EE. It has enhancements to multiple layers including data access, business logic and user interface.
SOA is more like a concept and you can implement it with or without ADF.
For your query on Oracle ADF,
In layman terms this is what it means...: ADF provides a commercial Java framework for building enterprise applications. It provides visual and declarative approaches to Java EE development. It supports rapid application development based on ready-to-use design patterns, metadata-driven and visual tools.
1) It is possible to develop by normal Java EE programming, but the complexitity is reduced with ADF (Using jDeveloper IDE) as it follows an MVC architecture.
2) No, ADF knowledge is not that mandatory for SOA.
ADF is a framework to create complex enterprise application based on the JSF framework at easier pace. for some coding sample look at my blog below
adf-webcenter.blogspot.com
Oracle ADF is an end-to-end Java EE framework to make in a simple way the application development using out-of-the-box infrastructure services.
As relevant information:
Use MVC pattern.
Developed (an easily) integrated with Java EE applications.
Some of the out of the box functionality doesn't need codification.
Similar to a BPM tool with TaskFlows
And about your questions:
ADF is an extension to the Java EE Framework, and can things that can be done using ADF (including SOA Development) be done by normal Java EE programming? Yes, you're right, also you can work with JavaEE 7 and JavaEE 6.
Is it mandatory to learn ADF for doing SOA applications? A user action or other activity in an Oracle ADF web application needs to invoke a SOA composite. The invocation is asynchronous and does not require a response. Inside the SOA composite, an Oracle Mediator component can provide routing and transformation, a BPEL component can provide business process orchestration, a human task service can provide workflows, and a decision service can provide complex business rules based decision making.
The Oracle ADF is a 4th Generation Language. In the sense one can create a full fledged Java Web Application in few seconds.
Everything is drag-drop behavior right from database table to modelling views in the pages.
The strong part of ADF is task flows. With task flows we can actually organize thousands of fragments in a single page/flow.
One no need to be an expert in any technology to build an application using jDeveloper/ADF. That will make any Web Developers work simple and easy.
I have a few projects coming up that have a number of endpoints or clients that can hit the same data. For instance a site might have...
A asp.net MVC based end user facing website
A web based adminitration back end that can allow specific, limited updates from some users in situatiosn where a full client isn't useful (mobile web etc)
A full on rich client for administration so we can use touch and other techniques to really make the user experience for content management shine - these may be silverlight or full on WPF apps, as needed
The question is... whats the best way to connect all that? Right now I use a multiple project split for the MVC.
ProjectName.Core - this project has all the common models, all the repository classes and all the helper classes
ProjectName.Web - an MVC project that references the Core to pull in the repositories and models it needs
ProjectName.Admin.Web - another MVC project dedicated to the admin interface that references the Core to pull in the repositories and models it needs
(which will ultimately live on a seperate subdomain from the end user facing site)
Then the story peters out int he sense of clear guidance. When the time comes to build a WPF / Silverlight project to hit the data I can do one of the following to the best of my understanding now...
Convert the "Core" to provide a RIA style DomainService, and attempt to alter the MVC projects to make use of it. However there is little guidance on using MVC with RIA, RIA is in its infancy AND the WPF to RIA story is also still only thinly documented
Do the same as above, but using WCF. However WCF prings with it async complexity that I really want RIA to hide for me.
Fall back 20 yards and just bolt plain old web services onto the Core on top of the Repositories and Models I already have. This seems... old school :)
Any thoughs and input are welcome including pointers to examples and documentation. I want to make the best decisions I can now, and am coming up to speed fast on RIA and WCF so I can but community input is always helpful.
Thanks!
Take a look at ADO.NET Data Services (formerly known as Project “Astoria”).
On my way to work today I was listening to a .NET Rocks! podcast, "Stephen Forte on Data Access Options", and they very excited about this, especially for scenarios like the one you describe.
It's interesting stuff, and something I would check out sometime very soon.
I think there's something to be said about plain old WCF services, these can make use of your domain services and repositories and expose a model more appropriate for services. Too often I've found that simply exposing the domain model on the wire ends up with a duplication of logic on both the client and the server.
My advice would be for some sort of service layer, this has the logic of shaping your domain model into appropriate types for the wire. \
Ideally I'd like to be able to share my Domain Services between the client (WPF / Silverlight) and the server (ASP.NET MVC) and have different underlaying repositories (Linq to NHibernate / Astoria). Difficult with the asynchonous nature of Silverlight.
For the curious, it certainly looks like RIA Services is the win here. Build a single DomainService then consume it everywhere. Brad Abrams covers a lot of this ground at bit.ly/94fFx - it really helped.