Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9

It should really be all or nothing.  All those specs are part of the SOAP web services support.  Either we support SOAP web services in Jakarta EE 9 or we don't.  I continue to believe that we should not include SOAP web services in Jakarta EE 9.

Perhaps those who feel a strong market need for SOAP web services should propose a SOAP profile as a superset of Jakarta EE 9 and add the SOAP support there?  While most existing Java EE vendors will continue to provide SOAP support in their Jakarta EE products, there really isn't much interest in evolving the SOAP-related specifications going forward.  Those who want to evolve SOAP specifications going forward should take on the burden of maintaining the specs, the TCKs, and at least one Compatible Implementation.


Kevin Sutter wrote on 11/25/19 6:16 AM:
Scott,
Can you clarify what you mean by treating the "whole set" as optional?  It's pretty clear you meant JAX-WS (JSR 224) and Enterprise Web Services (JSR 109).  But, did you also mean to lump in SAAJ (JSR 67) and Metadata (JSR 181)?  Or, would the latter two still be kept out of Jakarta EE 9 (per your proposal)?  Thanks.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        Scott Stark <starksm64@xxxxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        11/22/2019 08:57
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx




Here is some feedback I am getting from our various server leads with respect to these ballots:

JSR 109 - they would like this be retained as an optional specification. It defines behavior and has no actual API so the javax->jakarta transition is not relevant to as you said, but it's related to JAX-WS so treat the whole set the same and b) the platform TCK provides value to us.

On the addition of JAXB and JAF, It's either a No because we don't want any additions, or a No because we also want the WS specs added as optional since their dependency on JAXB/JAF creates the potential for inconsistent handling across vendors.



On Nov 22, 2019, at 8:28 AM, Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Hi Mohamed,
Those are fair questions/concerns.  We know there are many, many customers that use JAX-WS and SOAP.  The question at hand is whether these APIs are expected to evolve.  If these APIs will need to be updated in the future, then they will have to move to the jakarta.* namespace.  We can no longer evolve any of the javax.* APIs.  So, we're trying to figure out whether some of these APIs can be "capped" at their current level of functionality.


Application Servers can continue to provide solutions based on JAX-WS and SAAJ (SOAP), but they will be based on the current javax.* API.  They are not being proposed to move to the jakarta.* namespace.


Your other question about which APIs are actually being discussed is also valid.  We've had several discussions within IBM to ensure that we're all on the same page...  :-)
  • javax.xml.ws (JAX-WS), JSR 224
  • javax.xml.soap (SAAJ, SOAP), JSR 67
  • javax.jws (Metadata), JSR 181

Also, note that JSR 109, Enterprise Web Services, is currently part of Jakarta EE 8.  This Spec doesn't have a corresponding API, so there's no package name to point at.  This Spec is part of the discussion to prune/remove from Jakarta EE 9.


Hope this helps.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect

e-mail:  sutter@xxxxxxxxxx    Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        
"Mohamed M. El-Beltagy" <melbeltagy@xxxxxxxxx>
To:        
jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        
11/21/2019 18:31
Subject:        
[EXTERNAL] Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9
Sent by:        
jakartaee-platform-dev-bounces@xxxxxxxxxxx




Just for clarification, by saying JAX-WS to include/drop from Jakarta EE 9, we are actually talking about Jakarta XML Web Services (
https://projects.eclipse.org/projects/ee4j.jaxws)

Or, to be more specific, we are talking about dropping SOAP web services (as I keep reading that this is the dream)?


If SOAP is not being dropped, please accept my apology and skip the rest of this email.


If dropping SOAP is actually what we are talking about here, then:


Without going into much details that I am not allowed to talk about, I know for a fact that SOAP is heavily used in Middle East (Egypt, KSA, Oman, UAE and others). Most of those projects are monstrous systems (not just products) in place that took years to build using multiple products of multiple vendors and I doubt that they will go away anytime soon.
Since I do not have exact data, all I can do is ask a specific question targeting vendors with major clients in those areas. Based on the nature of the clients I am talking about, my question is targeting Oracle, IBM and SAP with the application servers and integration tools they provide (IBM WAS, BPM, IIB and SOA Suite to name a few).


You know, roughly, how many clients you have in those regions that still rely on SOAP heavily.
Based on that info, do you still think that dropping SOAP support from Jakarta EE will be the correct decision for those customers?


I am not talking from vendor's perspective. I am talking from end-users perspective.


And to be fair, most of those clients will follow what ever direction vendors tells them, some out of trust and other out of having no choice.
And yes, I meant vendors as they, unfortunately,  don't know about the community or the specs. They just care about the end product.


If you think that my question is irrelevant or stating wrong facts, please accept my apology for wasting your time.


Best regards,
Mohamed Elbeltagy



On Friday, November 22, 2019, 12:21:01 AM GMT+2, Ondro Mihályi <
ondrej.mihalyi@xxxxxxxxx> wrote:


If the consensus is that JAX-WS shouldn't be a required spec for JakartaEE 9, is there a problem to evolve JAX-WS as an optional spec? We can migrate JAX-WS to the jakarta namespace and still keep it outside of JakartaEE umbrella, am I wrong?


I think that way all the legacy solutions could adopt JakartaEE 9 and still support their current users/customers with JAX-WS, while at the same time new JakartaEE implementations wouldn't need to support it.


Ondro


Dňa št 21. 11. 2019, 15:11 Kevin Sutter <
sutter@xxxxxxxxxx> napísal(a):
Scott,
This is exactly what we're struggling with in our discussions at IBM.  We have many existing JAX-WS customers.  So, if we move JAXB to the jakarta namespace, but not JAX-WS, then we will have two different JAXB APIs to support.  But, we also recognize that JAX-WS is a legacy technology that probably shouldn't be part of the long term plans for Jakarta.

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail:  
sutter@xxxxxxxxxx   Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn:
https://www.linkedin.com/in/kevinwsutter



From:        
Scott Stark <starksm64@xxxxxxxxx>
To:        
jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        
11/21/2019 03:04
Subject:        
[EXTERNAL] Re: [jakartaee-platform-dev] VOTE: Specifications to add in Jakarta EE 9
Sent by:        
jakartaee-platform-dev-bounces@xxxxxxxxxxx




There still could be an update of JAX-WS to match the JAXB package changes without JAX-WS being an official part of EE 9 I suppose. JAX-WS is certainly a legacy tech that I would not expect customers to want to have to update their use for JAXB changes, but it could be beneficial to porting layers to have a JAX-WS release that allows for a runtime to make use of a single EE 9 based JAXB implementation.


> On Nov 20, 2019, at 1:58 PM, Bill Shannon <
bill.shannon@xxxxxxxxxx> wrote:
>
> If JAX-WS is not in EE 9, and a product that implements EE 9 wants to also support JAX-WS, that that product would need to satisfy the dependency on JAXB.  It could provide both javax.xml.bind and jakarta.xml.bind APIs, or it could use one of the backwards compatibility approaches to map javax.axml.bind APIs to jakarta.xml.bind APIs.
>
> But yes, having two implementations would make it hard to share binding classes.
>
> Andy McCright wrote on 11/20/19 11:19 AM:
>> Would this also require adding the JAX-WS APIs to the EE9 spec?
>>
>> The JAX-WS APIs that have been removed from the JDK currently have a dependency on JAXB.  If we evolve JAXB in EE9 (or just rename the packages), then we have some specs (like JAX-RS and maybe JPA, etc.) that depend on the jakarta.xml.bind.* packages while others (JAX-WS) that would depend on the javax.xml.bind.* packages. That would certainly make it difficult for EE9 applications to use both a JAX-RS and JAX-WS frontend that shares the same XML binding classes.
>>
>> Thanks, Andy

_______________________________________________
jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




_______________________________________________
jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev_______________________________________________
jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev



_______________________________________________
jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev




_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


Back to the top