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
|
