I am not sure this is the correct place to ask this question but I could not see a forum link in spring-statemachine project(http://projects.spring.io/spring-statemachine/) to ask a question to the developers, I hope this is the correct way to do it.
For a while I wrote a blog,
Extremely Axajified Web Application
concerning about extremely asynchronous web applications, using Spring Webflow with those and the limitations of Spring Webflow for these sort of projects.
In my proposed solution, I used extensively state machine principles. At the timeframe that I wrote this blog there wasn't an out of the box State Machine that I can use, so I implemented my own version of it.
Now to my surprise, I just saw Spring Statemachine project and I considering to convert my sample application to use the Spring Statemachine framework.
I have two questions to ask before really starting investing effort to the subject. I checked the samples of the Spring Statemachine, it seems that the configuration of the State Machine is done via Java Code.
Is this only possible method, in my sample application, I am reading an UML Model (XMI) and create via Eclipse M2T a Spring configuration file to startup the application.
I find it is for practical uses to complex for the end user to configure a complex State Machine via Java code. For this purpose I used graphical user interfaces to create UML model of the State Machine and convert this to Spring application context, so it will be easier to understand for the end user.
Which you can see here.
UML Model (unfortunately Stack Overflow is not letting me post extra link so please use "#sm_model" at the end of the previous link)
Eclipse M2T UML Model conversion (see above "#m2t")
So is it possible to provide an XML file and configure Spring Statemachine with it? I can naturally create Java classes via M2T but I have a feeling end result will be nearly unreadable for end user for complex projects.
Second question I like to ask, can Spring Statemachine support "Nested Statemachines", I found in the project web site a hint about the possibility but in the existing sample project I could not find a concrete implementation.
Biggest hurdle for the usage of a State Machine in a practical web application is the "State Explosion" and best way to deal with it, is the "Nested Statemachines".
Does Spring Statemachine support this concept.
You can find more details about what I mean with "State Explosion" and "Nested StateMachines" in the following links.
State Explosion (see above "#stateexplosion")
Nested Statemachines (see above "#nested_sm")
I hope this was the correct place to ask these questions.
Thx for the answers
Sorry for late answer, I just noticed this tagged question.
We don't yet have any functionality to define machine config outside of annotation based config model(javaconfig). Xml config is in our roadmap and you can track its status in ticket https://github.com/spring-projects/spring-statemachine/issues/78.
For your second question, yes we support nested states and even orthogonal regions. Showcase example shows relatively complex scenarios how nested states and transitions between those can be used http://docs.spring.io/spring-statemachine/docs/1.0.0.RC1/reference/htmlsingle/#statemachine-examples-showcase.
Related
I am in the process of moving an application from c# to node.js. I am learning node.js as I go along, so I am a node.js newbie. I am reading the book, Patterns, Principles and Practices of Domain Driven Design and found a lot of great information my current project could benefit from.
For instance, in the book, there is a sample e-commerce application that contains three bounded contexts: sales, shipping and billing. Each bounded context is responsible for its own database and each bounded context is running in an instance of NServiceBus. This seems to be a great approach as everything is running under the same solution, but different projects. In translating this to node.js, I am having a few areas of confusion.
1) I am having a rough time finding good examples that incorporate node.js with ddd like the e-commerce example above? Some of the hurdle here is the difference in how OOP is handled.
2) If in the book sample code, each bounded context is in its own project and runs within NServiceBus, would this mean that in translating this to node.js, I am using vscode as GUI, that I would need to create a separate parent folder(bounded context) for each project and supply a different port for each bounded context to listen on if I want all of the bounded contexts to run on the same server until I need to scale accordingly?
3) NServiceBus allows messages and events to get passed back ad forth. For node.js, what service bus technology, preferably open source and can run on linux-based machine, exists that would provide the kind of functionality NServiceBus provides and reliably? Should I just look at using rabbitmq alone to provide this functionality including sending events?
You might be interested in wolkenkit, a CQRS and event-sourcing framework for Node.js and JavaScript that plays very well together with domain-driven design (DDD).
Besides the actual framework (which is deployed as npm module wolkenkit), there are a number of sample applications available that show how things work:
wolkenkit-todomvc is the classical TodoMVC application modeled using DDD
wolkenkit-boards is a team collaboration software similar to Trello
wolkenkit-nevercompletedgame is the wolkenkit version of the game at nevercompletedgame.com
wolkenkit-geocaching is an application to manage caches for geocaching
Apart from that you might want to take a look at the wolkenkit documentation, and there again especially at the brochure you can download which explains DDD, event-sourcing and CQRS, what they are, how they relate to each other, and so on…
PS: Please note that I am one of the authors of wolkenkit, so please take my answer with a grain of salt.
I would suggest going through the npm modules tagged with ddd:
https://www.npmjs.com/browse/keyword/ddd
and tagged with service bus:
https://www.npmjs.com/browse/keyword/servicebus
There is also a JavaScript Domain-Driven Design book by Philipp Fehre.
This post is a couple of years old, but for anyone still interested there's a DDD framework for Typescript/node at:
https://github.com/node-ts/ddd
As well as an NServiceBus inspired message bus at:
https://node-ts.github.io/bus/
They're designed to work together to build message driven DDD systems with node
We're starting a web application using DDD and CQRS (using the ncqrs framework) and before we get started writing our own infrastructure class library, i wanted to see if any are already available.
I'd think at least some basic interfaces and common implementations for writing to the file system, sending emails, etc could be used in any project.
Those types of services are sufficiently context dependent to be unyielding to common frameworks above the facilities provided by the .NET Framework. There may frameworks centered around specific tasks, such as emailing, however you're better of selecting a solution that fits the requirements, instead of the converse. Instead, consider reviewing some sample DDD projects as listed here.
I agree with what eulerfx stated earlier. I'd add that if you depend upon a framework for using DDD and CQRS, then you risk depending on the framework and not truly understanding what is happening. As a result, you may miss what DDD (and CQRS) is providing to you.
I will state that I started off learning about CQRS by using a framework (NCQRS in fact), but my DDD knowledge was based on Evans' book and I didn't look for a framework for modeling my domain. As each domain is unique to the problem, I think it's hard to truly have a framework that "helps" you implement DDD.
In retrospect, I wish I had not gone with NCQRS right from the start as I missed or passed over some of the subtleties of the CQRS pattern.
There are probably some DDD frameworks out there, but I'd recommend forgoing them and build your own. You'll thank yourself later.
Hope this helps. Good luck!
You can try my library CoreDdd, documentation here, blog posts about it here. It contains support for DDD (entities, aggregate roots) and CQRS (commands, queries). No support for writing file system or sending emails, use standard .net for this.
So, I have an web-based application that is using the Wicket 1.4 framework, and it uses Spring beans, the Java Persistence API (JPA), and the OpenSessionInView pattern. I'm hoping to find a security model that is declarative, but doesn't require gobs of XML configuration -- I'd prefer annotations.
Here are the options so far:
Spring Security (guide) - looks complete, but every guide I find that combines it with Wicket still calls it Acegi Security, which makes me think it must be old.
Wicket-Auth-Roles (guide 1 and guide 2) - Most guides recommend mixing this with Spring Security, and I love the declarative style of #Authorize("ROLE1","ROLE2",etc). I'm concerned about having to extend AuthenticatedWebApplication, since I'm already extending org.apache.wicket.protocol.http.WebApplication, and Spring is already proxying that behind org.apache.wicket.spring.SpringWebApplicationFactory.
SWARM / WASP (guide) - This looks the newest (though the main contributor passed away years ago), but I hate all of the JAAS-styled text files that declare permissions for principals. I also don't like the idea of making an Action class for every single thing a user might want to do. Secure models also aren't immediately obvious to me. Plus, there isn't an Authn example.
Additionally, it looks like lots of folks recommend mixing the first and second options. I can't tell what the best practice is at all, though.
I don't know if you saw this blog post so I'm adding it here as reference and I'll just quote the end:
Update 2009/03/12: those interested in securing Wicket
applications should also be aware that
there is an alternative to
Wicket-Security, called
wicket-auth-roles. This thread
will give you a good overview of the
status of the two frameworks.
Integrating wicket-auth-roles with
Spring Security is covered here.
One compelling feature of
wicket-auth-roles is the ability to
configure authorizations with Java
annotations. I find it somehow more
elegant than a centralized
configuration file. There is an
example here.
Based on the information above and the one your provided, and because I prefer annotations too, I'd go for Wicket-Auth-Roles with Spring Security (i.e. guide 2). Extending AuthenticatedWebApplication shouldn't be a problem as this class extends WebApplication. And pulling your application object out of spring context using SpringWebApplicationFactory should also just work.
And if your concerns are really big, this would be pretty easy and fast to confirm with a test IMO :)
We've been using Wicket-security for years now and we have used it together with jaas files and with annotatations. Defining jaas files is quite a hassle and maintaining them is near impossible...
With annotations one has to define actions and principals for every page. This is timeconsuming however it does allow you to let the user define roles and authorizations dynamically. It is also possible to test all the principals using the WicketTester.
Each of the 3 packages has it's (dis)advantages, it's a matter of taste and it also depends on the size of the application.
I have a Java\Spring\Hibernate application - complete with domain classes which are basically Hibernate POJOs
There is a piece of functionality that I think can be written well in Grails.
I wish to reuse the domain classes that I have created in the main Java app
What is the best way to do so ?
Should I write new domain classes extending the Java classes ? this sounds tacky
Or Can I 'generate' controllers off the Java domain classes ?
What are the best practices around reusing Java domain objects in Grails\Groovy
I am sure there must be others writing some pieces in grails\groovy
If you know about a tutorial which talks about such an integration- that would be awesome !!!
PS: I am quite a newbie in grails-groovy so may be missing the obvious. Thanks !!!
Knowing just how well Groovy and Grails excel at integrating with existing Java code, I think I might be a bit more optimistic than Michael about your options.
First thing is that you're already using Spring and Hibernate, and since your domain classes are already POJOs they should be easy to integrate with. Any Spring beans you might have can be specified in an XML file as usual (in grails-app/conf/spring/resources.xml) or much more simply using the Spring bean builder feature of Grails. They can then be accessed by name in any controller, view, service, etc. and worked with as usual.
Here are the options, as I see them, for integrating your domain classes and database schema:
Bypass GORM and load/save your domain objects exactly as you're already doing.
Grails doesn't force you to use GORM, so this should be quite straightforward: create a .jar of your Java code (if you haven't already) and drop it into the Grails app's lib directory. If your Java project is Mavenized, it's even easier: Grails 1.1 works with Maven, so you can create a pom.xml for your Grails app and add your Java project as a dependency as you would in any other (Java) project.
Either way you'll be able to import your classes (and any supporting classes) and proceed as usual. Because of Groovy's tight integration with Java, you'll be able to create objects, load them from the database, modify them, save them, validate them etc. exactly as you would in your Java project. You won't get all the conveniences of GORM this way, but you would have the advantage of working with your objects in a way that already makes sense to you (except maybe with a bit less code thanks to Groovy). You could always try this option first to get something working, then consider one of the other options later if it seems to make sense at that time.
One tip if you do try this option: abstract the actual persistence code into a Grails service (StorageService perhaps) and have your controllers call methods on it rather than handling persistence directly. This way you could replace that service with something else down the road if needed, and as long as you maintain the same interface your controllers won't be affected.
Create new Grails domain classes as subclasses of your existing Java classes.
This could be pretty straightforward if your classes are already written as proper beans, i.e. with getter/setter methods for all their properties. Grails will see these inherited properties as it would if they were written in the simpler Groovy style. You'll be able to specify how to validate each property, using either simple validation checks (not null, not blank, etc.) or with closures that do more complicated things, perhaps calling existing methods in their POJO superclasses.
You'll almost certainly need to tweak the mappings via the GORM mapping DSL to fit the realities of your existing database schema. Relationships would be where it might get tricky. For example, you might have some other solution where GORM expects a join table, though there may even be a way to work around differences such as these. I'd suggest learning as much as you can about GORM and its mapping DSL and then experiment with a few of your classes to see if this is a viable option.
Have Grails use your existing POJOs and Hibernate mappings directly.
I haven't tried this myself, but according to Grails's Hibernate Integration page this is supposed to be possible: "Grails also allows you to write your domain model in Java or re-use an existing domain model that has been mapped using Hibernate. All you have to do is place the necessary 'hibernate.cfg.xml' file and corresponding mappings files in the '%PROJECT_HOME%/grails-app/conf/hibernate' directory. You will still be able to call all of the dynamic persistent and query methods allowed in GORM!"
Googling "gorm legacy" turns up a number of helpful discussions and examples, for example this blog post by Glen Smith (co-author of the soon-to-be-released Grails in Action) where he shows a Hibernate mapping file used to integrate with "the legacy DB from Hell". Grails in Action has a chapter titled "Advanced GORM Kungfu" which promises a detailed discussion of this topic. I have a pre-release PDF of the book, and while I haven't gotten to that chapter yet, what I've read so far is very good, and the book covers many topics that aren't adequately discussed in other Grails books.
Sorry I can't offer any personal experience on this last option, but it does sound doable (and quite promising). Whichever option you choose, let us know how it turns out!
Do you really want/need to use Grails rather than just Groovy?
Grails really isn't something you can use to add a part to an existing web app. The whole "convention over configuration" approach means that you pretty much have to play by Grails' rules, otherwise there is no point in using it. And one of those rules is that domain objects are Groovy classes that are heavily "enhanced" by the Grails runtime.
It might be possible to have them extend existing Java classes, but I wouldn't bet on it - and all the Spring and Hibernate parts of your existing app would have to be discarded, or at least you'd have to spend a lot of effort to make them work in Grails. You'll be fighting the framework rather than profiting from it.
IMO you have two options:
Rewrite your app from scratch in Grails while reusing as much of the existing code as possible.
Keep your app as it is and add new stuff in Groovy, without using Grails.
The latter is probably better in your situation. Grails is meant to create new web apps very quickly, that's where it shines. Adding stuff to an existing app just isn't what it was made for.
EDIT:
Concerning the clarification in the comments: if you're planning to write basically a data entry/maintenance frontend for data used by another app and have the DB as the only communication channel between them, that might actually work quite well with Grails; it can certainly be configured to use an existing DB schema rather than creating its own from the domain classes (though the latter is less work).
This post provides some suggestions for using grails for wrapping existing Java classes in a web framework.
I just started getting into BizTalk at work and would love to keep using everything I've learned about DDD, TDD, etc. Is this even possible or am I always going to have to use the Visio like editors when creating things like pipelines and orchestrations?
You can certainly apply a lot of the concepts of TDD and DDD to BizTalk development.
You can design and develop around the concept of domain objects (although in BizTalk and integration development I often find interface objects or contract first design to be a more useful way of thinking - what messages get passed around at my interfaces). And you can also follow the 'Build the simplest possible thing that will work' and 'only build things that make tests pass' philosophies of TDD.
However, your question sounds like you are asking more about the code-centric sides of these design and development approaches.
Am I right that you would like to be able to follow the test driven development approach of first writing a unti test that exercises a requirement and fails, then writing a method that fulfils the requirement and causes the test to pass - all within a traditional programing language like C#?
For that, unfortunately, the answer is no. The majority of BizTalk artifacts (pipelines, maps, orchestrations...) can only really be built using the Visual Studio BizTalk plugins. There are ways of viewing the underlying c# code, but one would never want to try and directly develop this code.
There are two tools BizUnit and BizUnit Extensions that give some ability to control the execution of BizTalk applications and test them but this really only gets you to the point of performing more controled and more test driven integration tests.
The shapes that you drag onto the Orchestration design surface will largely just do their thing as one opaque unit of execution. And Orchestrations, pipelines, maps etc... all these things are largely intended to be executed (and tested) within an entire BizTalk solution.
Good design practices (taking pointers from approaches like TDD) will lead to breaking BizTalk solutions into smaller, more modular and testable chunks, and are there are ways of testing things like pipelines in isolation.
But the detailed specifics of TDD and DDD in code sadly don't translate.
For some related discussion that may be useful see this question:
Mocking WebService consumed by a Biztalk Request-Response port
If you often make use of pipelines and custom pipeline components in BizTalk, you might find my own PipelineTesting library useful. It allows you to use NUnit (or whatever other testing framework you prefer) to create automated tests for complete pipelines, specific pipeline components or even schemas (such as flat file schemas).
It's pretty useful if you use this kind of functionality, if I may say so myself (I make heavy use of it on my own projects).
You can find an introduction to the library here, and the full code on github. There's also some more detailed documentation on its wiki.
I agree with the comments by CKarras. Many people have cited that as their reason for not liking the BizUnit framework. But take a look at BizUnit 3.0. It has an object model that allows you to write the entire test step in C#/VB instead of XML. BizUnitExtensions is being upgraded to the new object model as well.
The advantages of the XML based system is that it is easier to generate test steps and there is no need to recompile when you update the steps. In my own Extensions library, I found the XmlPokeStep (inspired by NAnt) to be very useful. My team could update test step xml on the fly. For example, lets say we had to call a webservice that created a customer record and then checked a database for that same record. Now if the webservice returned the ID (dynamically generated), we could update the test step for the next step on the fly (not in the same xml file of course) and then use that to check the database.
From a coding perspective, the intellisense should be addressed now in BizUnit 3.0. The lack of an XSD did make things difficult in the past. I'm hoping to get an XSD out that will aid in the intellisense. There were some snippets as well for an old version of BizUnit but those havent been updated, maybe if theres time I'll give that a go.
But coming back to the TDD issue, if you take some of the intent behind TDD - the specification or behavior driven element, then you can apply it to some extent to Biztalk development as well because BizTalk is based heavily on contract driven development. So you can specify your interfaces first and create stub orchestrations etc to handle them and then build out the core. You could write the BizUnit tests at that time. I wish there were some tools that could automate this process but right now there arent.
Using frameworks such as the ESB guidance can also help give you a base platform to work off so you can implement the major use cases through your system iteratively.
Just a few thoughts. Hope this helps. I think its worth blogging about more extensively.
This is a good topic to discuss.Do ping me if you have any questions or we can always discuss more over here.
Rgds
Benjy
You could use BizUnit to create and reuse generic test cases both in code and excel(for functional scenarios)
http://www.codeplex.com/bizunit
BizTalk Server 2009 is expected to have more IDE integrated testability.
Cheers
Hemil.
BizUnit is really a pain to use because all the tests are written in XML instead of a programming language.
In our projects, we have "ported" parts of BizUnit to a plain old C# test framework. This allows us to use BizUnit's library of steps directly in C# NUnit/MSTest code. This makes tests that are easier to write (using VS Intellisense), more flexible, and most important, easier to debug in case of a test failure. The main drawback of this approach is that we have forked from the main BizUnit source.
Another interesting option I would consider for future projects is BooUnit, which is a Boo wrapper on top of BizUnit. It has advantages similar to our BizUnit "port", but also has the advantage of still using BizUnit instead of forking from it.