JSR-313 for J2EE 6.0 received a setback (temporary)

An effort to standardize the next version of J2EE (6) as JSR-313 received a “temporary” setback at JCP, mainly due to licensing concerns. (Just to re-iterate my disclaimer: opinion/observations expressed in this blog are my own personal and does not necessarily reflect my employer’s views.)

A review ballot for JSR-313 was filed on April 3rd and was to be approved on April 16th. However, it was withdrawn on Friday the 13th!

From a sequence of events, I see interesting coincidences.

On April 10th, ASF sent an open letter to Sun over licensing issues related to J2SE 5.0. ASF has completed almost 95% compatible implementation and wanted to TCK license. However, the efforts failed to get mutually acceptable resolution. Hence, ASF went public with an open letter.

Though it is hard to establish the influence of the open letter on the fate of JSR-311. It might be more than a mere coincidence that ASF sent this open letter in the time window when this JSR was filled. More interesting coincidence is the comments concerning the licensing terms were expressed around the day when the letter went to a public. The letter created awareness and expressed the concerns of many others.

Anyway, since the next version on J2EE is an inevitable thing, I was told by the specifications leads that the JSR will be resubmitted after alienating the licensing concerns. J2EE6.0 would continue a Java's momentum to provide various SOA artifacts. This JSR specifically mentions that it would consider SCA artifacts. However did not mention JSR-235 or SDO. As you may know that JSR-235 was also withdrawn (by BEA and IBM) due to licensing issues. I understand that the SDO specification is also going to be resubmitted. I hope that it would also get added in this JSR.

The JSR proposes to include the following new JSRs:
* JSR-196 Java Authentication SPI for Containers
* JSR-236 Timer for Application Servers
* JSR-237 Work Manager for Application Servers
* JSR-299 Web Beans
* JSR-311 JAX-RS: Java API for RESTful Web Services

Other than these JSRs, there are some impacts on JAX-WS and JBI specifications too.

1. JSR-313 filing
http://jcp.org/en/jsr/detail?id=313

2. Comments and votes on JSR-313
http://jcp.org/en/jsr/results?id=4216

3. Open letter from ASF
http://www.apache.org/jcp/sunopenletter.html

4. ASF FAQ
http://www.apache.org/jcp/sunopenletterfaq.html

Announcements from WS standardizations world at OASIS

This month has been eventful for SOA related standardizations at OASIS, the international standards consortium. It has standardized WS-Trust, WS-Secure Conversation, WS-Context and WS-BPEL. The announcements came one after another… on March 27^th 2007 WS-Trust and Ws-Secure Communication, April 2^nd, WS-Context, and WS-BPEL on April 12^th. All these specifications took around 3 years of hectic joint efforts by their respective technical committees whose members came from various software vendors

WS-trust and WS-Secure Conversations provide additional building blocks on top of WS-Security. WS-Trust provides primitives and extensions for the issuance, exchange and validation of security tokens and dissemination of credentials within different trust domains. It will help to establish a programmatic trust for a secure communication between the communicating. The Web Services Secure Conversation Language defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts.

WS-Context is an outcome of an initiative called WS-CAF. The efforts began some time in December 2003. WS-Context provides a session construct in a decoupled SOA world. It is yet another but an important building block in WS architecture. Implementations of other runtimes e.g. WS-BPEL can leverage. Currently many implementations depend on features like Endpoint reference etc from WS-Addressing to represent some conversation or sessions in the WS world. As WS-Context provides a more generalized session model than WSA, WS-Context may find place in some of these usages. However, there is a competing standard WS-Coordination which is also OASIS specification. WS-Coordination is targetted to solve the similar problem and it has more momentum. It is interesting to note that it seems OASIS allows competing standards to be OASIS standards as long as they follow proper standardization process.

The OASIS also announced an initiative to standardize Service Component Architecture (SCA) as Open Composite Service Architecture. Considering the fact that SCA is fairly mature specification, I hope that it may take a little bit less to be the OASIS standard.

SpringOSGi M1 available for download...

This week SpringOSGI reached the first milestone. The availability to download it, added another OpenSource to OSGi(different than OGSI which is Open Grid Services Infrastructure) list of opensources.

http://sourceforge.net/project/showfiles.php?group_id=73357&package_id=227224

The list now goes on..Apache Felix, Equinox OSGi, KnopherFish OSGI, OXSA, Newton, and many others.

This year seems to be a good year to OSGI. Recently IBM and Cisco announced to develop Unified Communications and Collaboration(called UC2) platform based on OSGI. UC2 would not be an open source. So to increase the adoption by developers and industry, these companies would make UC2 freely available.

Anyway, coming back to OSGi which now has many mobile-telecom device vendors on its board. OSGIs start in 1999, it started with JSR-8 ( which was withdrawn). However, quite a few Mobile related JSRs like 232, 239, 246 (Mobile Specs) have come up based on works/concepts from OSGI ( and some JSRs like JSR 277 partially specified features thus became controversial) and some more are coming up JSR291 (Dynamic components) etc

Some of the concepts related to versioning, lifecycle managements, and various other services may find way beyond devices related to Web Services. Off-course, Webservices being stateless, there is already a debate whether 'lifecycle' management makes sense to Webservices or not. However, it all depends on what we makes sense as lifecycle management in the domain.

Parallelism and concurrency in WS-BPEL 2.0

WS-BPEL 2.0 has a better support to parallelism and concurrency.

For example, every iteration in a newly added "forEach" iterator can be run in "parallel". A scopes in a parallel flow can be "isolated" from each other so that they would not step on each other when they manipulates 'global variables'. Similarly, input / output variables of concurrent receive/reply pair can be associated using newly introduced "messageExchange" attribute.

Parallel branches in forEach
Each of the iteration in forEach can be run in parallel if forEach is marked as "parallel" as shown in following example.

<forEach parallel="yes" countername="lineItems">

<startCounterValue>1startCounterValue>

<finalCounterValue>count($order.lineItemss)finalCounterValue>

<scope>

.......

</ scope>

</ forEach>

Isolated scopes:
When activities in isolated scopes access shared variables, they are protected by serializing (completing all such activities in one scope at a time before other).

<process ...>

<variables>

<variable name="TotalAmount" element="..." />

variables>

<flow>

<scope name="Merchandize" isolated="yes">

<sequence>

...

<assign>

<copy>

<from>......from>

<to variable="TotalAmount" />

< /copy>

</assign>

...

</ sequence>

< scope>

< scope name="Shipping" isolated="yes">

< sequence>

...

<assign>

<copy>

<from>......from>

<to variable="TotalAmount" />

< /copy>

</ assign>

MessageExchange:
One to one relationship between inbound message variable to appropriate Concurrent Receive/Request pair can be established by uniquely assigning a messageExchange name as given in following example.

<process ...>

<messageExchanges>

<messageExchange name="supplier" />

<messageExchange name="manufacturer" />

messageExchanges>

...

<flow>

...

<receive messageExchange="supplier"

partnerLink="businessPartner"

portType="businessPT"

operation="updateInfo" />

...

<reply messageExchange="supplier"

partnerLink="businessPartner"

portType="businessPT"

operation="updateInfo"/>

...

<receive messageExchange="manufacturer"

partnerLink="businessPartner"

portType="businessPT"

operation="updateInfo" />

...

<reply messageExchange="manufacturer"

partnerLink="businessPartner"

portType="businessPT"

operation="updateInfo" />

...

</flow>

</process>