The need for transactions in the MicroProfile

[Michael Musgrove]

Our discussions on this group have touched upon the role that transactions may play in the MicroProfile. In traditional enterprise software it is commonly accepted that there exists a set of applications which are required to provide some degree of transactional guarantee - it has also been well argued that there exists a class of microservices which have a need to provide similar functionality (http://jbossts.blogspot.co.uk/2015/04/microservices-and-transactions-update.html). Until we define a proposed method for addressing these needs there is a likelihood that users will need to develop ad hoc approaches which may then leave them open to suffer unexpected data integrity issues if they do not address the myriad complex corner cases.

I would therefore like to kickstart a thread to get feedback on what the community expects to see in a proposal for adding transactions to the MicroProfile. When developing this proposal I think we should be open to the possibility that the best model to add transaction support for microservices on may not be a classic JTA model but may be based on one of the extended transaction models. 

[Tom Jenkinson]

One thing to consider is that there exists a multitude of transaction protocols which do not have to provide the same set of properties. 

We could support a fixed subset of coordination models or perhaps we should provide a framework upon which any model can be implemented (a la JSR 95 - J2EE Activity Service Specification), providing implementations of a couple of the more common ones. This option is nice for extensibility and may attract users that wish to provide new protocols.

Some technology which already exists that might provide the basis for a proposal:

- Existing transaction models:

  * JSR 95: J2EETM Activity Service for Extended Transactions (https://jcp.org/en/jsr/detail?id=95 )

  * Try, Confirm, Cancel (http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf)

  * JDI: https://developer.jboss.org/wiki/CompensatingRESTfulTransactions

  * REST-AT: http://narayana.io//docs/project/index.html#d0e15502

- Existing CDI annotations:

  * JTA annotations: https://javaee-spec.java.net/nonav/javadocs/javax/transaction/Transactional.html and https://javaee-spec.java.net/nonav/javadocs/javax/transaction/TransactionScoped.html

  * Narayana compensations API: (org.jboss.narayana.compensations) (http://narayana.io//docs/project/index.html#d0e17689)

  * STM annotations: http://narayana.io/docs/project/index.html#d0e16064   (http://narayana.io//docs/project/index.html#d0e17689)

[Werner Keil]

That's certainly an interesting and complex area.

I helped a customer that later joined the JCP, too with an attempt to get J2EE and CORBA transactions under the same hood. At least a year before JSR 95 headed towards Final, so it certainly could not be used (especially in banks and finance even until now) before it went Final.

It does not seem, JSR 95 was ever used by the Java EE platform. A follow-up when SOAP and XML were "The Microservices of its time" JSR 156 https://jcp.org/en/jsr/detail?id=156 was withdrawn.

Werner

[Mark Little]

As the original lead of 156 I can say that the reason we pulled it was it was simply too early to standardise. OASIS BTP was a standard for only a couple of years, OASIS WS-CAF didn't get there in the end, and OASIS WS-TX and friends standardised later but still before we pulled 156. Almost a decade later, it's a very different landscape.

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4e79d06f-a538-463a-9b68-5745e359e912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martijn Verburg]

Hi all,

I'm for supporting this but will also warn that there's an educational piece to this.  The uService's community at large is rabidly anti transactions (rightly or wrongly).  I think if we write up some concrete uService use cases around Mark's blog post, it will help counter the immediate naysayers.

I certainly know that some of my old Investment Banking customers would welcome transactional guarantees around this new paradigm.  It might be uncool to be ACID but you know that $5million trade had better be *saved* :-).

Cheers,
Martijn

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CA%2BfW9O427YpJ9Z5bQWHJdVLZrTaVpmYGYogTmuVv1Y%2BNTXi9hw%40mail.gmail.com.

[Werner Keil]

It was probably similar with JSR 350: https://jcp.org/en/jsr/detail?id=350

Which in fact started at EclipseCon 2010 where I motivated an Oracle speaker (could have been Jeff or a colleague) to consider standardizing some of the proprietary "skunk labs" project or product he told us about. And speak to other Eclipse or JCP contributors especially Mike Keith. So some of that not only led to JSR 350 but Mike pushing for thh first Config standard effort soon after JSR 350 was approved (which was August 2011, we had both spoken at GIDS that year)

Unfortunately both Oracle shifted its priorities, Spec Leads got other duties or left and except for IBM not too many EG members participated on a regular basis, so it failed the 2nd Renewal Ballot. Ironically "State Management" but with a different angle, more along the lines of Circuit Breakers and state of all services is high on Oracle's agenda for Java EE 9 again.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

[Werner Keil]

uService? At least Wikipedia doesn't know that one either https://en.wikipedia.org/wiki/Microframework (like the ultrafast Python based one that was just unveiled on Medium)

Banks do love transactions. Ideally everything including CORBA, external FinTecs or CoreBanking products often running on mainframe.

Cheers,
Werner

[Mark Little]

The transactions community is used to dealing with rabid anti-feelings ;)

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAP7YuART2tLowmQTG04D_Xng7_zwXksq%2BPrJic3OvZGLvr44OA%40mail.gmail.com.

[Mark Little]

I suggest that Tom and Mike take this as an action item for moving forward with a proposal. Anyone else who is interested should ping them.

Mark.

On 6 Feb 2017, at 17:32, Martijn Verburg <martijn...@gmail.com> wrote:

[Tom Jenkinson]

We will do that and get back to the list when we have something that we can get some more feedback on.

Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4e79d06f-a538-463a-9b68-5745e359e912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Michael Musgrove]

Transactions in Microprofile: Notes for Discussion

This note presents a number of use cases (with solutions) that motivate the need to provide varying levels of consistency guarantees in a microservice based architecture. The goal is to facilitate discussion of the requirement for a framework/API/set of annotations for transactions. If readers have alternative approaches to satisfying the use cases it is still our expectation that the code they are developing will be complex and could provide the basis for next generation transaction middleware libraries and/or services so all input on alternative solutions to these use cases or to propose new ones is encouraged. For example the event sourcing + CQRS approach [1] achieves eventual consistency in a different way from the conventional approaches presented below.

The first two use cases target users that have already bought into a SOA style solution and are using a Web Services coordination framework to provide transactional guarantees. To support this kind of user in a staged migration over to a MicroServices Architecture (MSA), perhaps using REST based protocols in place of WS protocols, we suggest that the MicroProfile ought to provide similar functionality:

Use case 1: Legacy WS-AT [2] based services

A company is already using web services and WS-AT and wants to re architect their app to use microservices instead. Phase 1 of the migration could be to map each web service onto a microservice but the user does not wish to redesign how they maintain consistency (ie they would like the MSA solution to have the same transactional semantics).

Use case 2: Legacy WS-BA [3] based services

A company is already using web services and WS-BA and wants to re architect their app to use microservices instead. Phase 1 of the migration could be to map each web service onto a microservice but the user does not wish to redesign how they maintain consistency (ie they would like the MSA solution to have the same transactional semantics).

Note that in WS-BA, at each step of the workflow, a compensating transaction is registered with a coordinator. If any of the steps fail then the compensations for previously completed steps are ran. It is an example of the Saga pattern:- a set of compensatable actions where the (idempotent) compensate actions are ran in the event of failure. The (business) actions are run at most once (0 or 1) and the compensations are ran at least once (1 or more). The state of the Saga is maintained in a durable distributed log so that recovery is possible on failure.

Other variants for achieving service coordination that business may be using include the TCC (Try-Cancel/Confirm) [4] model and a variation on the Routing Slip pattern [5]:

TCC has a slight nuance in the sense that the normal business activity (the TRY) is placed in a pending state (as opposed to a committed state) and only becomes final on receipt of the CONFIRM part of the model. The CANCEL signal is analogous to a compensation (in the Saga sense of the word) except that it is the pending state that is compensated rather than the committed state. A flight booking example would be: TRY reserves a seat whereas CANCEL/CONFIRM would mark the seat as available/booked. This nuance means that TCC can always return back to the initial state (contrast this with the Saga model where rewinding back to the initial state may not be feasible).

In the Routing Slip pattern the compensation actions are written down in a routing slip at each stage of the workflow. If a step in the workflow fails then that step is responsible for initiating the compensation actions - it invokes the last compensation on the slip whilst passing the slip back up the chain. In this way each service gets to run its own compensation. Logically, this model is similar to WS-BA, the difference being that there is no central coordinator (but there is still a need for a durable distributed log for use by a recovery monitor to handle failures).

Other more concrete use cases follow:

Use Case 3: ACID (Strong consistency)

This case can be illustrated using an order processing sequence of events:

1. create order
   
2. create invoice
   
3. create shipment 
   

In an environment where orders, invoices and shipments reside in different services this workflow might be modelled using classic flat transactions (2PC XA). Some people that are migrating to microservices, say from Web Services Atomic Transactions (WS-AT) as in Use Case 1, may find this a useful stepping stone to a more microprofile-centric approach:

• although not generally recommended, flat transactions are nevertheless potentially useful in scenarios where there is a sufficient level of trust amongst participants. 
  
• I can envisage cases where services could be composed into a group and deployed as a unit (it breaks the loose coupling characteristic but it is still a pattern some organisations will want to adopt). In this case classic 2PC could be a requirement.
  

Use Case 4: Saga (Eventual consistency)

Again we can use the order processing sequence of events as in Use Case 3: 

1. create order
   
2. create invoice
   
3. create shipment 
   

But now, to overcome the problems of maintaining strong consistency, we relax some of the ACID properties and use a saga instead. At step 1) a saga would be created which is then responsible for managing the remaining steps. Once the (business) transaction is complete (shipped item and paid invoice) the saga can be closed (or compensated if shipment or payment cannot be fulfilled).

Use Case 5: Sub-transactions

For example, booking a trip to the theatre in the West End (of London)

1. book flight to Stansted (from Newcastle)
   
2. book train to Kings Cross
   
3. book tube to Leicester Square
   
4. book the theatre ticket for the desired show 

If any of these steps fail there will be alternatives that still result in seeing the show (earlier or different flight, take a taxi to the West End, attend a later showing, etc).

A workable approach (though probably not most peoples first choice) to satisfying this use case is to use a nested transaction in which each step is a sub transaction:

• if I decide to call the whole trip off I cancel the top level transaction which aborts each sub transaction;
  
• if I decide to use a different flight then I just abort the flight sub transaction and start a new one with a different flight operator. Once each sub transaction has committed successfully the top level transaction can be committed.
  

This solution maintains ACID properties (and thus incurs any of the perceived drawbacks of Use Case 3).

[1] the MSDN site has a readable introduction to the topic: https://msdn.microsoft.com/en-us/library/jj554200.aspx

[2] WS-AtomicTransaction (http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec.html) is a specification for synchronizing an all or nothing task between two resources and is aimed at service calls that perform short lived operations. It provides ACID transactions for Web Services and guarantees strong data consistency (shared data is globally consistent)

[3] WS-Business Activity (http://docs.oasis-open.org/ws-tx/wsba/2006/06) is an instantiation of the Saga model and is aimed at service calls that perform long lived operations. It provides compensating transactions for Web Services and only guarantees a weaker form of data consistency (data is not necessarily consistent at a given snapshot in time but will eventually be seen to be consistent). We lose the A and I parts of ACID but get improved availability.

[4] https://www.atomikos.com/Blog/TransactionManagementAPIForRESTTCC

[5] http://www.enterpriseintegrationpatterns.com/patterns/messaging/RoutingTable.html

Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/4e79d06f-a538-463a-9b68-5745e359e912%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Mark Little]

Mike, despite the fact I’ve been involved in a lot of the WS-* standards and implementations over the years, I think we should ignore “traditional” Web Services, i.e., those using SOAP. Although we could make an argument for microservices interoperability via SOAP, that same argument could be made for communication using IIOP, and neither approach is likely to get much store from microservices developers. Now maybe I’m being too “new age” here and over thinking things, but I suspect that the majority of microservice deployments will be fine with HTTP (1 or 2), messaging protocols, and if not gRPC then probably something like it.

So with that in mind, and assuming you and others agree, what would that do to the notes below? Could you also restructure this in such a way that the conversation looks at the models available rather than specific implementations or standards? I know it tries to do that, but as soon as you launch into WS-AT, I think it turns off some readers because of the WS-* heritage. Perhaps if you start with ACID, in this example? Again, I know you do that later, so maybe it’s more a case of deleting some things and re-ordering others, but I’d much rather consider use cases from the application perspective first and foremost than kick off a discussion around existing protocols and standards.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f333db70-e454-4bd2-9b14-e6c13e48ab39%40googlegroups.com.

[Michael Musgrove]

I can do that but the intention was never to bring WS under the MicroProfile umbrella. The purpose of the discussion around WS is to identify an existing group of users who might wish to migrate from a WS platform over to a MicroProfile one. If MicroProfile provides transaction models that have similar semantics to WS-AT and WS-BA then the migration path for them will be less painful, and that is a valid use case. Also, having already referenced BA I use it to explain the concepts behind the more generic concept of a saga.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

[Mark Little]

Sure, but not everything that is possible in EE might make sense in a microservice/MicroProfile environment. There’s an argument that those users may be better of sticking with Java EE in the first place. I’d rather start with use cases that are specific to “enterprise microservices”, and see where we go from there. Maybe we end up in the same place but then again maybe we don’t. Perhaps one way of breaking it down is to look at brownfield scenarios and greenfield scenarios?

Mark.

[Werner Keil]

I am pretty sure, where optionality and flexibility allows to add aspects of Java EE you may simply use JTA, but not sure, if it makes sence and is worth the effort to "reinvent the wheel" in all of these areas.

Spring doesn't it uses everything from Dropwizard to Hystrix, Archaius and many Java EE standards (@Inject, Batch, Bean Validation you name them as well as older ones like Servlets and JSP) in a "Mix and Match" way.

Werner

[Michael Musgrove]

We cannot ask developers to leverage JEE for transactions because:

• straight JTA is local to the app server but MicroProfile needs to support propagating a transaction context when invoking other microservices and to use JEE for that he would need to pull in JTS which in turn would pull in EJBs and CORBA OTS
• JEE only supports ACID transactions but a microservice user will more likely need different (eventually consistent) semantics for whatever transaction model he chooses

Werner

[Michael Musgrove]

But we should not rule out using the annotations that Java EE has defined for transactions although they may not be rich enough for defining extended coordination models.

[Michael Musgrove]

I reworked the text and put it into a google doc: https://docs.google.com/document/d/1atVaXu7xCS75RnZSJ_u-rPwq7w9k3dN8BLI0jDWQxsg/edit?usp=sharing

It contains a single simple use case followed by a discussion of three approaches to solving it. What is the best way to move this forward, perhaps it would be an interesting exercise to sketch out how to solve the use case using existing implementations/APIs and see where that leads us.

[Danilo Cominotti Marques]

Michael,

Thanks for bringing up this topic. I mentioned the need to include transactional support a long time ago, when MicroProfile was at its very beginning, and it is nice to finally see some discussion happening around the subject.

Personally, I cannot conceive how the "uServices community" could be "rabidly anti transactions" as per Martijn's remark. Once RDBMS are used, [ACID] transactions need to be taken into consideration every time. Actually, every single architect/developer/stakeholder will need to at least think about ACID at some point, and this has nothing to do with special scenarios from the enterprise or banking contexts, but rather with common requirements that will show up in many domain models.

At the very least, I think that support for the semantics of @javax.transaction.Transactional should be added to the specification by all means. I think it is very surprising that concerns such as Fault Tolerance can be so far ahead of basic support for [ACID] Transactions in the specification.

Regards,

Danilo Cominotti Marques

[Tom Jenkinson]

Even while acknowledging that there can be a need for the addition of a non-ACID transaction API (e.g. Saga) to MicroProfile there are good use cases for JTA within the MicroProfile. 

One use case I was discussing recently with a group was the idea of that in microservices you may wish for your distributed transaction API to be compensation oriented, however at the service level then (and within the scope of that compensation oriented transaction) there can be use cases for updating multiple resources in a single transaction.

[Kenji HASUNUMA]

It's my thought, the transaction is earlier for the current MicroProfile.

Adapting MicroProfile to systems, the transactions needs is certainly, I believe. 

Distributed transactions is so complex that it's not easy to introduce to MicroProfile.

By change the view, is transaction truly need for MicroProfile?

Some cases is needed, but the others is not needed -- I think.

I think when to introduce transaction for MicroProfile is be careful, with it's really need or not.

I'm afraid MicroProfile may be too complex.

[mmus...@redhat.com]

I do hear your concerns but supporting some flavour of transactions does not need to be complicated. Perhaps you are focusing too narrowly on distributed JTA transactions.

There are other models such as sagas or the list of references that Tom Jenkinson posted in the first response on this thread. I have spent some time this week implementing one of the models he mentioned (namely JDI: https://developer.jboss.org/wiki/CompensatingRESTfulTransactions) to see how easy it would be to integrate into our MP demo app. If it is easy to use it to solve the use cases I mentioned in my Apr 4th post on this thread then I will share my experience here.

[Mark Little]

+1

[Michael Musgrove]

Over the past few weeks I have been implementing a PoC for how to do compensations/sagas in a microservices environment - it is based on the specification referenced at the bottom of this post and I have used it to validate that the use cases I posted earlier can be supported.

I believe that there is plenty of justification for the need for some form of compensation/saga support in MicroProfile and in the rest of this post I draw your attention to various of blogs, conference presentations, tools etc where people have been extolling the benefits of sagas for building microservices. I have just picked on one or two of the more well known people in the field but I think that that is sufficient. Assuming we can get some momentum behind this, as a next step we need to submit a proposal, initially based on the spec that I based my PoC on.

Conferences:

Caitie McCaffrey (Twitter) has presented on the topic at a number of well know conferences

- https://speakerdeck.com/caitiem20

- https://speakerdeck.com/caitiem20/distributed-sagas-a-protocol-for-coordinating-microservices

Tom Jenkinson and Mark Little are presenting at JavaOne 2017 on the topic "Transactions for microservices? Really?"

Chris Richardson (http://microservices.io/) has presented on sagas for microservices at conferences such as Devoxx and included a discussion of them in his book Microservice Patterns: - https://cfp.devoxx.co.uk/2017/talk/FSW-0358/Using_sagas_to_maintain_data_consistency_in_a_microservice_architecture_

Blogs:

Martin Fowler talks about "... explicit recognition that consistency may only be eventual consistency and problems are dealt with by compensating operations" (https://martinfowler.com/articles/microservices.html).

The idea is taken up by Jonas Boner (creator of Akka) (http://jonasboner.com/bla-bla-microservices-bla-bla/) where, in his list of microservice principles, he sumarizes the approach with "Guess. Apologize. Compensate.: If you can’t coordinate, and be certain about something, then take an educated guess, a bet that a condition will hold, and if you were wrong then apologize and perform a compensating action."

Mark Little has written extensively on the utility of transactions (in various flavours). One of his more recent takes on the topic is on his blog (http://jbossts.blogspot.co.uk/2015/04/microservices-and-transactions-update.html) 

Pat Helland, a well known writer in the field of distributed systems (http://dblp.uni-trier.de/pers/hd/h/Helland:Pat), wrote an excellant position paper on Life Beyond Distriubted Transactions (http://adrianmarriott.net/logosroot/papers/LifeBeyondTxns.pdf) where he tacitly introduces the idea of eventual consistency:

"To reach an agreement across entities, one entity has to ask another to accept some uncertainty. This is done by sending a message which requests a commitment but leaves open the possibility of cancellation. "

...

"Essential to a tentative operation, is the right to cancel. Sometimes, the entity that requested the tentative operation decides it is not going to proceed forward. That is a cancelling operation. When the right to cancel is released, that is a confirming operation. Every tentative operation eventually confirms or cancels. When an entity agrees to perform a tentative operation, it agrees to let another entity decide the

outcome. This is accepting uncertainty and adds to the general confusion experience by that entity. As confirmations and cancellations arrive, that decreases uncertainty"

Tools:

We also notice that a number of tools people are using to build microservices often include the option of including sagas in their solution:

- A popular choice for building microservices in .NET is to use the NServiceBus which supports sagas.

- http://www.axonframework.org/docs/2.0/sagas.html

- Lightbend discuss it in their "Reactive Microservices Architecture": Resilient transaction management with the SAGA pattern:

"The Saga Pattern is a scalable and resilient alternative to distributed transactions. It is a way to manage longrunning business transactions based on the discovery that longrunning business transactions often comprise multiple transactional steps in which overall consistency of the whole transaction can be achieved by grouping these steps into an overall distributed transac‐ tion. The technique is to pair every stage’s transaction with a com‐ pensating reversing transaction, so that the whole distributed transaction can be reversed (in reverse order) if one of the stage’s transactions fails."

Our proposal: Long Running Actions (LRA)

---------------------------------------------------------

https://developer.jboss.org/wiki/CompensatingRESTfulTransactions (the proposal also links to a PoC of the spec).

[Mark Little]

I suggest starting something up in the sandbox area.

Mark.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2b6eb4fa-d30d-468c-9293-55c5562f365e%40googlegroups.com.

[Michael Musgrove]

We have raised a pull request in the Eclipse sandbox (https://github.com/eclipse/microprofile-sandbox/pull/2) for this work. 

There is also a reference implementation of the proposal (https://github.com/jbosstm/narayana/tree/master/rts/lra).

And we have a quickstart showing services using the reference implementation. It runs on both WildFly Swarm (using the the Red Hat MicroProfile swarm fraction) and on OpenShift (a container application platform). It is available in our quickstart repo: https://github.com/jbosstm/quickstart/tree/master/rts/lra.

And finally, there was a talk and demo about the work at the recent JavaOne 2017

Mike

[John D. Ament]

Michael,

Very nice, and glad to see Narayana working on something like this.  Hopefully this implies it can stay standalone (e.g. not directly in swarm).

Ideally all source files would have a common license header.  https://github.com/eclipse/microprofile-jwt-auth/blob/master/spec/src/main/asciidoc/license-alv2.asciidoc can be used as an example.

One confusing thing from reading through the annotations, you mention that they're primarily for JAX-RS resources.  However, they're defined as CDI interceptors.  Should they just work on any CDI beans?

Also, we don't currently require JAX-B in MicroProfile.  Does it make sense to use JSON instead?

John

[Guillermo González de Agüero]

El vie., 20 oct. 2017 a las 4:36, John D. Ament (<john.d...@gmail.com>) escribió:

Michael,

Very nice, and glad to see Narayana working on something like this.  Hopefully this implies it can stay standalone (e.g. not directly in swarm).

Ideally all source files would have a common license header.  https://github.com/eclipse/microprofile-jwt-auth/blob/master/spec/src/main/asciidoc/license-alv2.asciidoc can be used as an example.

One confusing thing from reading through the annotations, you mention that they're primarily for JAX-RS resources.  However, they're defined as CDI interceptors.  Should they just work on any CDI beans?

I haven't take a look at the code (just read the proposed spec and it looked great!) but JAX-RS resources are not currently CDI beans unless you explicitly annotate them.

WildFly has some integration in place to make rest resources request scoped beans, but that's not standard.

CDI integration was lately discussed on the JAX-RS list but it was too late and the spec leads decided to postpone it.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ee88cd09-0e3e-40a1-8b00-1281fd35768a%40googlegroups.com.

[mmus...@redhat.com]

Thanks for you input John:

On Friday, 20 October 2017 03:36:42 UTC+1, John D. Ament wrote:

Michael,

Very nice, and glad to see Narayana working on something like this.  Hopefully this implies it can stay standalone (e.g. not directly in swarm).

The reference implementation needs Swarm or WildFly since the prerequisites are the narayana transaction manager plus a JAX-RS implementation. That said, the specification must be implementable inside any microprofile container.

 

Ideally all source files would have a common license header.  https://github.com/eclipse/microprofile-jwt-auth/blob/master/spec/src/main/asciidoc/license-alv2.asciidoc can be used as an example.

After getting agreement from all existing contributors I have replaced the copyright with the Eclipse EDL (https://www.eclipse.org/org/documents/edl-v10.php) (but note that I haven't raised the PR on the sandbox repo yet).

 

One confusing thing from reading through the annotations, you mention that they're primarily for JAX-RS resources.  However, they're defined as CDI interceptors.  Should they just work on any CDI beans?

The intention was for the spec to only work with JAX-RS resources. The reason for requiring JAX-RS for LRA participants is so that the implementation can automatically register the participant with the LRA coordinator via JAX-RS endpoints. Are you suggesting that we broaden the spec to allow the annotations on any CDI bean? If so then I could investigate removing the restriction (to JAX-RS) and leave it up to the spec implementation to decide how to fulfil the requirements of the model.

 

Also, we don't currently require JAX-B in MicroProfile.  Does it make sense to use JSON instead?

Can you indicate where I refer to JAX-B (the only place in the spec where I refer to JSON is in the examples where I use @Produces(MediaType.APPLICATION_JSON)?

Thanks,

Michael

[John D. Ament]

Hi Michael,

On Thursday, January 4, 2018 at 12:34:00 PM UTC-5, mmus...@redhat.com wrote:

Thanks for you input John:

On Friday, 20 October 2017 03:36:42 UTC+1, John D. Ament wrote:

Michael,

Very nice, and glad to see Narayana working on something like this.  Hopefully this implies it can stay standalone (e.g. not directly in swarm).

The reference implementation needs Swarm or WildFly since the prerequisites are the narayana transaction manager plus a JAX-RS implementation. That said, the specification must be implementable inside any microprofile container.

Last I recall, Naryana has a native CDI extension, right?  So that it can run outside of a container?

 

 

Ideally all source files would have a common license header.  https://github.com/eclipse/microprofile-jwt-auth/blob/master/spec/src/main/asciidoc/license-alv2.asciidoc can be used as an example.

After getting agreement from all existing contributors I have replaced the copyright with the Eclipse EDL (https://www.eclipse.org/org/documents/edl-v10.php) (but note that I haven't raised the PR on the sandbox repo yet).

 

One confusing thing from reading through the annotations, you mention that they're primarily for JAX-RS resources.  However, they're defined as CDI interceptors.  Should they just work on any CDI beans?

The intention was for the spec to only work with JAX-RS resources. The reason for requiring JAX-RS for LRA participants is so that the implementation can automatically register the participant with the LRA coordinator via JAX-RS endpoints. Are you suggesting that we broaden the spec to allow the annotations on any CDI bean? If so then I could investigate removing the restriction (to JAX-RS) and leave it up to the spec implementation to decide how to fulfil the requirements of the model.

I'm referring to https://github.com/jbosstm/microprofile-sandbox/blob/9bc84b2a878765880d5bf9348d6b95906f0c1861/proposals/0009-LRA/lra-annotations/src/main/java/org/eclipse/microprofile/lra/annotation/Compensate.java (and other classes of similar structure) which is a CDI interceptor.  There would be nothing blocking its use in other CDI beans.

If the goal is JAX-RS only, then we should define a JAX-RS interceptor behavior instead.

 

 

Also, we don't currently require JAX-B in MicroProfile.  Does it make sense to use JSON instead?

Can you indicate where I refer to JAX-B (the only place in the spec where I refer to JSON is in the examples where I use @Produces(MediaType.APPLICATION_JSON)?

https://github.com/jbosstm/microprofile-sandbox/blob/9bc84b2a878765880d5bf9348d6b95906f0c1861/proposals/0009-LRA/sra-annotations/src/main/java/org/eclipse/microprofile/sra/client/txstatusext/ObjectFactory.java is a JAX-B class.

[Kevin Sutter]

Hi Michael,
What's the scope of this effort from a MicroProfile perspective?  When I started to read your README, I got the impression that not only are you interested in providing CDI annotations and a Java API, but also provide interop with other languages?  MicroProfile has been focused on supporting Java, so I'm wondering if this proposal is going beyond that.  I'm also curious on whether you think the whole proposal would be required to be compliant?  Or, are there optional aspects of the proposal?

Re:  John's comments about Apache licensing in the headers...  MicroProfile is an Apache licensed project.  So, if we go forward with this proposal, we would need all of the source to be Apache licensed, not EPL or EDL.

To be consistent with the rest of the projects, I would also recommend the use of asciidoc instead of markdown for the README.

I also made a couple of minor updates in the README due to missing reference hashmarks...

Thanks for your efforts!  I will continue to dig into this to understand it better.
--  Kevin

[mmus...@redhat.com]

On Thursday, 4 January 2018 18:16:53 UTC, John D. Ament wrote:

Hi Michael,

On Thursday, January 4, 2018 at 12:34:00 PM UTC-5, mmus...@redhat.com wrote:

Thanks for you input John:

On Friday, 20 October 2017 03:36:42 UTC+1, John D. Ament wrote:

Michael,

Very nice, and glad to see Narayana working on something like this.  Hopefully this implies it can stay standalone (e.g. not directly in swarm).

The reference implementation needs Swarm or WildFly since the prerequisites are the narayana transaction manager plus a JAX-RS implementation. That said, the specification must be implementable inside any microprofile container.

Last I recall, Naryana has a native CDI extension, right?  So that it can run outside of a container?

Good point, we added CDI support for Java Transaction API 1.2 (JSR 907) compliance which added the @Transactional and @TransactionScoped annotations so we can support that standalone. But we still need to run inside a container that contains a JAX-RS implementation, ie it still won't run standalone.

 

 

Ideally all source files would have a common license header.  https://github.com/eclipse/microprofile-jwt-auth/blob/master/spec/src/main/asciidoc/license-alv2.asciidoc can be used as an example.

After getting agreement from all existing contributors I have replaced the copyright with the Eclipse EDL (https://www.eclipse.org/org/documents/edl-v10.php) (but note that I haven't raised the PR on the sandbox repo yet).

 

One confusing thing from reading through the annotations, you mention that they're primarily for JAX-RS resources.  However, they're defined as CDI interceptors.  Should they just work on any CDI beans?

The intention was for the spec to only work with JAX-RS resources. The reason for requiring JAX-RS for LRA participants is so that the implementation can automatically register the participant with the LRA coordinator via JAX-RS endpoints. Are you suggesting that we broaden the spec to allow the annotations on any CDI bean? If so then I could investigate removing the restriction (to JAX-RS) and leave it up to the spec implementation to decide how to fulfil the requirements of the model.

I'm referring to https://github.com/jbosstm/microprofile-sandbox/blob/9bc84b2a878765880d5bf9348d6b95906f0c1861/proposals/0009-LRA/lra-annotations/src/main/java/org/eclipse/microprofile/lra/annotation/Compensate.java (and other classes of similar structure) which is a CDI interceptor.  There would be nothing blocking its use in other CDI beans.

If the goal is JAX-RS only, then we should define a JAX-RS interceptor behavior instead.

I think the goal should be JAX-RS only since:

- it is available in all microprofile containers;

- service coordination needs the LRA context to be passed around and an HTTP header is the natural choice;

- the LRA protocol relies on network endpoints (where the microservice can be contacted) to drive participants to completion and, again, JAX-RS is the natural choice;

- it offers a simpler programming model since the heavy lifting can be achieved via JAX-RS filters

I will update the proposal to remove the @InterceptorBinding annotations (they don't need to be interceptors since a JAX-RS filter can be used to implement the protocol behaviour).

 

 

Also, we don't currently require JAX-B in MicroProfile.  Does it make sense to use JSON instead?

Can you indicate where I refer to JAX-B (the only place in the spec where I refer to JSON is in the examples where I use @Produces(MediaType.APPLICATION_JSON)?

https://github.com/jbosstm/microprofile-sandbox/blob/9bc84b2a878765880d5bf9348d6b95906f0c1861/proposals/0009-LRA/sra-annotations/src/main/java/org/eclipse/microprofile/sra/client/txstatusext/ObjectFactory.java is a JAX-B class.

Ah yes I forgot about the SRA (ShortRunningAction) optional part of the specification (an SRA is effectively a 2PC over the network). I will look at removing this dependency on JAX-B (well spotted).

Also I will raise a separate comment on this thread to verify that people are aware of this (2PC) addendum to the main proposal.

Michael

[mmus...@redhat.com]

On Thursday, 4 January 2018 22:49:32 UTC, Kevin Sutter wrote:

Hi Michael,
What's the scope of this effort from a MicroProfile perspective?  When I started to read your README, I got the impression that not only are you interested in providing CDI annotations and a Java API, but also provide interop with other languages?  MicroProfile has been focused on supporting Java, so I'm wondering if this proposal is going beyond that.  I'm also curious on whether you think the whole proposal would be required to be compliant?  Or, are there optional aspects of the proposal?

When I wrote the proposal I tried to conform to RFC 2119 ("Key words for use in RFCs to Indicate Requirement Levels") to indicate which parts are optional. I will go through it again to check that I am using the keywords throughout but broadly: the CDI annotations are mandatory and the sections covering the Java API, interoperability and Short Running Actions (SRAs) are optional.

I believe that the optional section on interoperability is essential if we want to build a wider community. Interoperability is based on REST endpoints and is kind of implicit already since the spec is mandating JAX-RS but drawing this out explicitly helps to formalise the protocol. What do other people think on this issue?

 

Re:  John's comments about Apache licensing in the headers...  MicroProfile is an Apache licensed project.  So, if we go forward with this proposal, we would need all of the source to be Apache licensed, not EPL or EDL.

Our reference implementation uses the Narayana transaction manager (http://narayana.io/) which uses the LGPL v2.1 license which I believe would preclude us from using the APIs that this proposal introduces if we were to propose it as an Apache licensed project.

 

 

To be consistent with the rest of the projects, I would also recommend the use of asciidoc instead of markdown for the README.

Agreed.

 

I also made a couple of minor updates in the README due to missing reference hashmarks...

Thanks,

Michael

[Mark Little]

I’m a little confused here because there are projects (aka “specs), which define APIs and friends, and then there are implementations of those “specs|. We don’t have the concept of RI in MicroProfile but each spec can/should link to conforming implementations (see some of the specs in 1.1, 1.2, for example). Now any of those implementations would clearly use the APIs defined in whichever specs to which they need to conform but those implementations do not need to be ASLv2 in order to do so.

Mark.

[Ian Robinson]

One of the challenges with participant registration in any distributed transaction model is how the (distributed) set of participants get access to the state they require to perform any action at the end of a transaction. They can't localize the state because that constrains clustering so that leaves key-based storage (where the key might be related to some combination of transaction id and participant id), at which point there needs to be specification details for interoperation purposes during the completion of the transaction.

The model in the proposed spec for distributing context to services that add compensators makes sense at a high level - its a well-used model (**). But there's an awful lot of detail that would be required to make this more generally implementable than just the existing JBoss LRA implementation.
I agree with previous comments that any MicroProfile work should focus (initially at least) on a purely CDI-based mechanism. That ought to help with eliminating the numerous "unspecified" aspects of the proposed spec, but I do think they would need to be eliminated before we really had something here, and with examples of how clustering of services is handled. (In both the WS-CAF LRA and the WS-AT/WS-BA models participant addressing uses SOAP-based WS-Addressing that essentially gives "identity" to the participants. Something similar could be specified over REST but stateful endpoints are not a good pattern for microservices). So I'm cautious about locking this into a specific release of MP before this sort of detail is considered.

(**) [On a historical front, there were some references in this thread to JSR 95 and various OASIS TCs. JSR 95 (the Java EE Activity Service) actually is implemented (contrary to the earlier statement) and in production in WebSphere and provides the underpinning of WebSphere's and BPM's WS-BA support. Since its an internal implementation detail, JSR 95 itself is not explicitly exposed to WebSphere applications but compensation APIs specific to WS-BA built on top of it are. Whether anything we do in MicroProfile is based on WS-BA or LRA really doesn't matter here, in my opinion, as much as coming up with something that has a simple CDI-annotation-based programming model and a scalable registration model that doesn't require applications to have to do any explicit registration or fiddling around with HTTP headers. ]

- Ian

[Emily Jiang]

+1 Mark! The APIs in MicroProfile repo should be licensed under Apache v2. It does not matter which license the implementor chooses to use for their implementations. By the way, MicroProfile specs do not have the RI concept but just plain implementations (to get rid of class system).

This proposal is about LRA while SRA is also considered. Should a better name be considered, e.g. atomic or something?

From my reading of this proposal, it geared up more towards JAX-RS rather than CDI. How well do this new annotations work with @Transactional etc?

Emily

On Friday, January 5, 2018 at 12:32:02 PM UTC, Mark Little wrote:

[Mark Little]

Yes, a different, more explicit (obvious?) naming should be considered for MicroProfile inclusion, If SRA are atomic then that might be more appropriate. If they're meant to be ACID then perhaps that instead, since atomic doesn't require ACID.

I also agree that a CDI-first approach should be considered.

Mark.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b75fd8a4-33aa-48a1-82fb-da700bcd8ab2%40googlegroups.com.

[Mark Little]

Hopefully the groups working on the proposal won't be confused that your reply has nothing to do with my licence confusion ;)

But on the general topic of this proposal, I do wonder if the group is trying to do too much too quickly. Several of us have worked on transaction standards over the years, Ian and I together on a few of them, and they take a long time to do because there's a lot to address. There are no edge cases with transactions - it's got to work reliably. It's complex enough with just ACID transactions but then throw in extended transactions (of which compensations are just one possible approach) then it goes up by orders of magnitude.

Putting aside some of the things which should be easy to address, such as the naming and CDI-first, I keep coming back to something I've said a few times on the subject of transactions in MicroProfile: focus on use cases, define a transaction protocol that works for that use case (or maybe several) and then move on to add a new transaction protocol for other use cases, if they exist. Yes, very much like what we attempted with XOTS and JSR 95. We shouldn't try to define an uber transaction protocol for MicroProfile that tries to work for all use cases and I think that's the intent of the team working on this but perhaps it's not clear enough to everyone giving input?

Mark.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/0203f888-4706-491f-bfd7-aee6e3918a7c%40googlegroups.com.

[Kevin Sutter]

+1, Mark.  Innovate, iterate, repeat...

[mmus...@redhat.com]

Okay so what I am hearing is that we are tying to be too all encompassing. What I propose then is to stick with CDI only plus the basic Java API (for users that do not want to use JAX-RS) and to drop the optional parts of the specification, namely interoperability and Short Running Actions (ACID 2PC) and perhaps revisit them in a future iteration of the spec. This should provide just enough specification to satisfy the two use cases that I have already provided to this list in my 04/04/2017 post (https://docs.google.com/document/d/1atVaXu7xCS75RnZSJ_u-rPwq7w9k3dN8BLI0jDWQxsg/edit).

I will respond to Ian's comments separately next.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[mmus...@redhat.com]

On Friday, 5 January 2018 14:45:04 UTC, Ian Robinson wrote:

One of the challenges with participant registration in any distributed transaction model is how the (distributed) set of participants get access to the state they require to perform any action at the end of a transaction. They can't localize the state because that constrains clustering so that leaves key-based storage (where the key might be related to some combination of transaction id and participant id), at which point there needs to be specification details for interoperation purposes during the completion of the transaction.

Participant registration includes the possibility to also register arbitrary data with the coordinator. At LRA close/cancel time the coordinator will include this data in the request to the participant to complete/compensate. I may have misunderstood your point but this mechanism means that participants do not need to localize state and the endpoints do not need to be stateful. 

 

The model in the proposed spec for distributing context to services that add compensators makes sense at a high level - its a well-used model (**). But there's an awful lot of detail that would be required to make this more generally implementable than just the existing JBoss LRA implementation.

Could you elaborate on which detail we are missing and which aspects we have underspecified.

 

Thanks,

Michael

[Mark Little]

Sounds good. The group can add new things into later releases.

Mark.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b1ec0370-fff0-4859-bf8f-44f9bfe32af8%40googlegroups.com.

[Ian Robinson]

On Sunday, January 7, 2018 at 10:04:19 AM UTC, mmus...@redhat.com wrote:

On Friday, 5 January 2018 14:45:04 UTC, Ian Robinson wrote:

One of the challenges with participant registration in any distributed transaction model is how the (distributed) set of participants get access to the state they require to perform any action at the end of a transaction. They can't localize the state because that constrains clustering so that leaves key-based storage (where the key might be related to some combination of transaction id and participant id), at which point there needs to be specification details for interoperation purposes during the completion of the transaction.

Participant registration includes the possibility to also register arbitrary data with the coordinator. At LRA close/cancel time the coordinator will include this data in the request to the participant to complete/compensate. I may have misunderstood your point but this mechanism means that participants do not need to localize state and the endpoints do not need to be stateful. 

For local Java compensators, that would be the CompensatorData string I assume. But I was thinking more of the distributed case where I have microservices isolated in their own container/JVM with REST as the communication protocol between them. serviceA calls serviceB over REST; serviceA and serviceB both have their own compensators but there are no shared serializable objects (which would be a tight-coupling antipattern) so there has to be some form of distributed transaction context between (clustered) serviceA and (clustered) serviceB with some notion of a generic-remote-participant (essentially subordinate local coordinator) registered as a compensator in serviceA's transaction whose compensationData would need to be sufficient to target the downstream transaction subordinate coordinator. My terminology here is borrowed from generic distributed transactions rather than LRA specifically. Both the remote registration and transaction completion protocol would need a portable REST API defined, along with the structure of the transaction context. All of which leads towards a RESTful version of something like WS-Coordination. That stuff all works and underpins WS-BA as well, but it would have to be REST-fied and deSOAPed and unWS=Addressed etc.  But that's quite a bit of definition required to make something portable. Am I way off the mark here?

 

The model in the proposed spec for distributing context to services that add compensators makes sense at a high level - its a well-used model (**). But there's an awful lot of detail that would be required to make this more generally implementable than just the existing JBoss LRA implementation.

Could you elaborate on which detail we are missing and which aspects we have underspecified.

Summarizing my response to the previous part above:
Defined context for remote propagation
REST APIs for Registration of remote participants or proxies for them
REST APIs for remoting the completion and recovery protocols
Plus the concrete state transitions and semantics of the specific transaction models. I may have missed the point of the difference between SRA and JTA but it seems to me that any initial focus would have a greater chance of success fixing upon one compensation-related transaction model rather than spend any time on SRA.
What's the concrete state model for LRA?  There is a state table in the referenced WS-CAF LRA document although I don't think it shows all the possible message flows. Would it be worth instead referencing the equivalent WS-BA transaction state model here - there's a full state-model and message flow diagram: http://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html#_Toc160445402 - I don't think there are significant differences between this and the LRA model - the spec here just followed through to final standard and would be a more stable reference. (There are two protocols defined by WS-BA - the second one is the one equivalent to LRA). 

- Ian

[Tom Jenkinson]

I would like to mention that Mike raised https://github.com/eclipse/microprofile-sandbox/pull/9 which was recently merged and should address the community feedback we have had.

I believe we are ready to move to the next step from https://wiki.eclipse.org/MicroProfile/FeatureInit if we have consensus?

[Ken Finnigan]

Tom,

I think it's a fair assessment that we can move to the next step.

Let's say if there hasn't been a reasonable objection to the proposal by Tuesday 20th that it can move to the next step?

Ken

--

You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/cbee1d87-5271-403e-80d6-a6c7ec98e2c4%40googlegroups.com.

[Michael Musgrove]

Thanks Ken,

For completeness regarding this thread the PR description included my resolution of the various comments raised on this thread:

To John:

I have updated the headers to use the ASLv2 license.

I have removed the CDI requirement (ie the spec now uses only standard Java annotations).

But note that the goal is JAX-RS only so the annotations only make sense for JAX-RS resources.

I have removed the section on Short Running Actions (SRA) which in turn removes the dependency on JAX-B.

To Kevin:

I am now using asciidoc (instead of markdown) for the README

You also asked "are there optional aspects of the proposal?"

I have removed the optional parts of the spec.

The responsibility of the implementer is now:

the Java annotations for controling the lifecycle of LRAs and participants

the Java client API

the Java registration API

BTW it is still debatable as to whether or not the client and registration APIs should be optional

To Mark, Kevin and Ian

You all voiced concerns about the interoperability section which has now been removed

I have included a state model diagram in the README

To Emilly:

You said "the proposal is geared up more towards JAX-RS rather than CDI"

Ans: agreed, I have removed the CDI references

You asked how the new annotations work with @transactional etc?

Ans: Since I deleted the Short Running Action (2PC/ACID) part of the specification there is now no relationship between them

On Friday, 16 March 2018 15:13:50 UTC, Ken Finnigan wrote:

Tom,

I think it's a fair assessment that we can move to the next step.

Let's say if there hasn't been a reasonable objection to the proposal by Tuesday 20th that it can move to the next step?

Ken

On Fri, Mar 16, 2018 at 10:11 AM, Tom Jenkinson <tom.je...@redhat.com> wrote:

I would like to mention that Mike raised https://github.com/eclipse/microprofile-sandbox/pull/9 which was recently merged and should address the community feedback we have had.

I believe we are ready to move to the next step from https://wiki.eclipse.org/MicroProfile/FeatureInit if we have consensus?

On Friday, February 3, 2017 at 4:03:29 PM UTC, Michael Musgrove wrote:

Our discussions on this group have touched upon the role that transactions may play in the MicroProfile. In traditional enterprise software it is commonly accepted that there exists a set of applications which are required to provide some degree of transactional guarantee - it has also been well argued that there exists a class of microservices which have a need to provide similar functionality (http://jbossts.blogspot.co.uk/2015/04/microservices-and-transactions-update.html). Until we define a proposed method for addressing these needs there is a likelihood that users will need to develop ad hoc approaches which may then leave them open to suffer unexpected data integrity issues if they do not address the myriad complex corner cases.

I would therefore like to kickstart a thread to get feedback on what the community expects to see in a proposal for adding transactions to the MicroProfile. When developing this proposal I think we should be open to the possibility that the best model to add transaction support for microservices on may not be a classic JTA model but may be based on one of the extended transaction models. 

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Michael Musgrove]

Ian,

Thanks for the feedback, I trust that my last response to the group and the PR have addressed some of your concerns. You have raised a number of points which are probably more pertinent to achieving interoperability and since we have dropped that aspect from proposal I think it would be best to discuss your feedback separately from this thread if and when we come to address interop but I am more than happy to discuss here if appropriate.