1 of 1 people found this helpful
Whilst it's not using Docker directly, have you looked at WildFly-Swarm?
1 of 1 people found this helpful
another options is to use our JTS + JacORB Name Server images.They're still in my personal repo. But any input about what's missing in it would be great. narayana-docker/jts/transaction-service at master · gytis/narayana-docker · GitHub .
And the small quickstart is here: quickstart/jts-docker at master-JBTM-2296 · gytis/quickstart · GitHub.
So two separate Wildfly-Swarm images for two separate microservices with one transaction starting in one swarm image propogating to another swarm image then you could choose between remote EJBs or JAX-RS with REST-AT.
This does remove the need for a Transactions as Service though (since each microservices is hosting a transaction service)?
There is also RTS (REST-AT) as a docker image over here: narayana/rts-wildfly at master · jboss-dockerfiles/narayana · GitHub. It's worth pointing out that that RTS image uses the RTS standalone.xml from WildFly which does seem to start up the whole server too: wildfly/rts.xml at master · wildfly/wildfly · GitHub - as you probably know, WildFly launches incredibly quickly so the additional services shouldn't add too much overhead to the boot time but gytis - it might be worth trying to slim that rts.xml to just include the services that are required to fire up RTS itself?
Again ignoring Docker for the moment, you could deploy one WF-Swarm instance with some business logic and then have another instance(s) that uses the same transaction manager running within the first. Not sure if this is what you're after though.
Yes that will work if the the technology stack being used is Wildfly / Java EE.
So with WF-Swarm based microservices it is quite straightforward. If there is another microservice not based on WF-Swarm is where things break down.
I'll reply to gytis separately with the RTS based approach.
I've seen this forum post:
Quoting from this mmusgrov
We don't currently support automatically starting REST-AT transactions. We decided against that because the service that creates coordinators (aka begin a transaction) could reside anywhere on the network. - See more at: https://developer.jboss.org/thread/259022#sthash.VnbKQDki.dpuf
Granted anywhere on the network does cause problems, where things might become simpler is if the services are known by kubernetes, then service discovery can be mediated via kubernetes.
Then taking some inspiration from the fabric8 service injection work automatic REST-AT transaction might be possible:
Granted, there is an awful lot of detail missing from my suggestion.
The biggest problem is where the transaction log resides. Not a rocket-scientist problem, i.e., can be fixed. But given Kube requires immutable containers it means that we need to be sure the log is maintained away from the docker image that is the transaction manager.
I've just had a discussion with mmusgrov, and we think that we could implement automatic start of the REST-AT, if that feature is requested.
I don't know much about kubernetes, but what I suggest is to have a configurable field in standalone.xml with the URL of the transaction manager. By default it would be a locally running one, but it could be changed to the remote endpoint. Pretty much the same thing as is in XTS.
Would this work for your case?
Yes that sounds like it would definitely make using transactions for REST services even easier:
If I understand http://jbossts.blogspot.de/2013/04/simplified-xts-context-propagation.html correctly and applying it to rts then:
1) Invoke a rest endpoint hosted in a micro-service
2) the endpoint implementation establishes a JTA context via @Transactional
3) within this transaciton context some calls are made to REST endpoints hosted in a different micro-service (in a different container) but which support REST-AT.
4) the RTS subsystem present in the first micro-service would propagate the JTA context via the bridging mechanism to the second microservice.
In the docker/kube world the bridge could lookup in kube the transaction service URL.
So in Openshift v3 that could be a persistent storage mount ?
Looking at the rts bridge code it appears to be almost portable (I saw a dependency on RestEasy).
If it is portable then with an externalized transaction service it could/should be possible to use it in a Apache CXF REST endpoint?
i.e. I'm imagining the use case of a coordinating service hosted in a Wildfly instance which establishes a REST-AT transaction context which propgates to both a Wildfly hosted REST endpoint and a Apache CXF REST endpoint hosted in a different container. The transaction service being external to all three.
That article is talking about different improvement, which simplified WS-AT/WS-BA handlers configuration.
But your explanation of the workflow is correct. We would have to implement bridging from JTA to REST-AT. This will allow you to start the transaction with @Transactional in one microservice and then invoke rest endpoint in another. There is a JIRA for this, but nobody worked on it since it wasn't requested up to now [JBTM-1109] JTA -> REST-AT Bridge - JBoss Issue Tracker. I'll have to speak with my teammates if/when we can add it to our schedule.
We do test our REST-AT transaction manager in standalone environment. However, I have never tried to run the bridge outside of WildFly. I'm guessing that it would be possible, if all the libraries would be available, but some of them are not as straightforward. In any case, this sounds as an interesting thing to try.