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

Exposing Peoplesoft's Component Interface(CI) as Webservice

PeopleSoft’s Component Interface (CI) is a common way to abstract Peoplesoft’s Component by encapsulating data and implementation. Typically a CI exposes component properties and provides system defined and user defined methods. Peopletools IDE provides a nice framework to develop CIs. CIs can be used in App Message, any Peoplecode and App Engines. CIs are heavy weight objects carrying artifacts like validations. Though a more lightweight object model called Application Message (popularly called as AppMessage) is now-a-days more popular among Peoplecode developers, many of the legacy applications are still exposed as CIs. Moreover, it is easier to expose a Component as a CI.

Thus, exposing CIs as WebServices provides a quick way to expose existing PeopleCode based applications to SOA world. Though versions earlier to Peopletools 8.48 supported a basic mechanism to do the same, Peopletools 8.48 provides much easier and richer framework. In Pre-8.48 world, CI to WebService was via SOAPTOCI and exposed one method as a webservice.




Service Designer in Peopletools 8.48 is a web-based designer to discover, create, publish/consume, and monitor services. One can use the designer to expose CI as a webservice with select a CI by navigating to Integration Broker->Web Services ->CI-Based Service. Providing a webservice to an existing CI is as simple as selecting operations to be exposed and generating a service.

However, a WSDL for such service would have system generated names. These system-generated names may not be very intuitive. To overcome this issue, the designer provides a provision to give alias name for the service and operation names. These aliases are used in the generated WSDL as Service Name and Operation names. Similarly, one can use a message editor or routing parameters to provide some meaningful name like “CURRENCY_RECORD” instead of system generated names, which are typically like M7869912.V1. If you want to expose a different message shape then one can define a transformation in routing metadata for the operations.



If you consider CI as a proprietary Service Interface, then, Providing CI as a webservice is a classic example of Web Service to proprietary Service. It provides a nice abstraction.

Peopletool8.48

BPEL processes in PeopleSoft Applications using Peopletools 8.48 (and later)

In last few days, many customers, professional service engineers and integration specialists asked about using BPEL with PeopleSoft Applications. So I am giving some high level overview of Peopletools 8.48 functionalities for integrating with BPEL.

In 2005, when I was the Enterprise Architect of Peopletools (a development and runtime platform of Peoplesoft Applications), one of the important projects we did was to add many features to enable SOA in a better way. Peopletools 8.48 provided a better Service designer to consume or provide webservices. Many new features like WS-Addressing support, WS-SE, etc aligned Peopletools 8.48 to seamlessly work with BPEL. A much better than earlier version of Peopletools 8.46 and 8.47! (both these version are also certified with BPEL 10.1.2).

Many additional features like a support to WS-A headers & correlation id, security credentials, WSIL lookup, and others, allow PeopleSoft Applications and BPEL to discover each other’s services and invoke them other synchronously or asynchronously in a secured way.

We also added some features specifically for BPEL e.g. Partnerlinks in generated WSDLs, a utility Application classes, BPELUtil, IBUtil etc. With partnerlink support, the PeopleSoft Services are easier for BPEL to consume.

Using newly introduced BPELUtil, Peoplecode developers can directly launch a BPEL process. IBUtil class provides APIs to track the process. It also provides some more utility methods to get BPEL console URL, domain, etc. In fact, Peoplesoft CRM developed a process monitor for CRM processes using these APIs in release 9.0. Additionally, BPEL console can be launched within Peoplesoft portal without re-login.

Consuming a BPEL process was made very easy in Peopletools. One can consume the service by discovering from BPEL’s WSIL, UDDI, or directly importing using wsdl URL, or from a WSDL file. A copy of the WSDL is stored in WSDL repository table. Using the service designer, the developer can select port type, operations and messages. The developer can also add some handlers and routings.

Easy Coding: The consumed BPEL process can be launched (invoked) using a very few Peoplecode statements.

Creating a Message

&payload = CreateXmlDoc(&customer);

&msg = CreateMessage(Operation.PROCESS, %IntBroker_Request);

&msg.SetXmlDoc(&payload);

Invoking a BPEL process

&response = &bpelProcess.LaunchSyncBPELProcess(&OPERATION, &msg, "", "");

Processing a response

If All(&response) Then

&responseString = &response.GenXMLString();

WinMessage(&responseString);

Else

WinMessage("Error: No reply ");

Providing Services:

Peoplesoft Component Interfaces (CI)s and Peoplecode App Classes can be easily exposed as web services. The Service Designer helps to assemble the service by defining service operations and map them one or more CIs or App Classes or Peoplecode functions (handlers). Using the Schema designer one can design Peoplsoft’s rowset or non-rowset based message or import pure XML message as a schema. The service designer abstracts the internal names of handlers and messages allowing developers to give appropriate names. After assembling a service, the developer can publish the service as a WSDL to a WSIL or UDDI repository. The WSDL is also saved in an internal WSDL repository and available for query or export.

Routing and transformations:

Many times the external service may expect or send a message, which could be different than the internal message. The Service designer allows developing and using transformations of these messages using a graphical mapper.

Peopletools supports following Request Response Patterns:

1. One way notification (Fire and Forget)
2. Synchronous Request Response
3. Asynchronous Request Response

The Async Request response is supported using WS-Addressing headers. The external WS-Addressing headers, like correlation message id, propagated to Peoplecode based application (via IBInfo).

Security: In the world of integrations, Security is very important. Different framework handles security differently. PT8.48 implements a waterfall security model. A Username token and pass code token can be set at Service operation or Node or may have a default. It can be sent encrypted, digitally signed or text. An application programmer can override these using Security override API to provide a different token. This security credentials are sent via WS-SE.

Using the Integration framework, Enterprise Applications like CRM, HCM developed many Business Processes with BPEL.

SDO
JSR-235

(Peoplesoft is a Trademark of Oracle Corp. To differentiate with other ERP applications offered by Oracle, I am specifically using Peoplesoft name.)

JSR-311 Java API for REST approved ballot after a Mixed reactions from developers:

JSR proposal http://jcp.org/en/jsr/detail?id=311


JCP formed a JSR expert group to publish an API for RESTful services. JSR-311 is in ballot review period in this month (till Feb 26). Software companies like Apache, BEA, Google,JBoss and Sun Microsystems are on the board. Individuals like Jerom Louvel (RESTlet framework) and Douge Lea are also on board of it. However, according to others, Roy Fielding whose dissertations documented the REST pattern, seems to be unhappy about Sun using REST as a name.

According to this request, this JSR intends to provide a high level easy to use API for developers to write RESTful web services that would run on top of the Java EE or the Java SE platforms. The JSR would provide API with declarative style of programming using annotations for developers. It would also enable low level access in cases where needed by the application.

Sun's lead on this specification, Marc Hadley, outlined following conceptual model:

@UriTemplate("widgets/{widgetid}")
@ConsumeMime("application/widgets+xml")
@ProduceMime("application/widgets+xml")
public class Widget {

@HttpMethod(GET)
public Representation getWidget(@UriParam("widgetid") String id) {
String replyStr = getWidgetAsXml(id);
return new StringRepresentation(replyStr,
"application/widgets+xml");
}

@HttpMethod(PUT)
public void updateWidget(@UriParam("widgetid") String id,
Representation update) {
updateWidgetFromXml(id, update);
}

@LastModified
public Date getChangeDate(@UriParam("widgetid") String id) {
return getLastChanged(id);
}
}

Interestingly, the JSR furthers states " The specification will define
how RESTful services are deployed as JAX-WS (Java API for XML Web
Services) endpoints or Servlets."  The API will be packaged as javax.ws.rest.
I assume there could be WSDL representation of this using HTTP binding type defined in WSDL1.1 where
get,put, post etc can be captured as "verb" e.g. http:binding verb="GET

While REST based services may fit into a broader definition of webservices, a SOAP centric RPC styled
definition of Webservices is not suitable for RESTful services. Following page
compares SOAP and REST.
http://rest.blueoxen.net/cgi-bin/wiki.pl?HowSoapComparesToRest

Anyway, a comment suggesting a direction of using JAX-WS and a reference to "DL based on annotations" has stirred the developers
community. Particularly on a background where WS vs REST battle is still not yet completely
settled.

W3Consortium has published a presentation on reconciling Webservices and REST.
http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)



(Unofficial)Develoeprs Polls at
http://java.net/pub/pq/146 as of Feb 25th
Approve 126  34%
Disapprove 67  17%
no opinion 99  25%
wait and see 95 24%
other 7

Latest News: The JSR 
The Executive Committee for SE/EE has  approved this ballot.

http://jcp.org/en/jsr/results?id=4168

The next (tentative schedule)schedule:

February 2007	Expert group formed
June 2007	First expert draft
August 2007	Early Draft review
November 2007	Public Review
January 2008	Proposed final draft
March 2008	Final release.

Refereces:
1. JSR-311: http://jcp.org/en/jsr/detail?id=311
2. JAX-WS: http://java.sun.com/webservices/jaxws/
3. Restlest API: http://www.restlet.org/tutorial
4. Marc Hadley http://weblogs.java.net/blog/mhadley/
5. W3c on WS and REST: http://www.w3.org/2005/Talks/1115-hh-k-ecows/#(1)
6. SOAP and REST: http://rest.blueoxen.net/cgi-bin/wiki.pl?HowSoapComparesToRest

REST

JSR-311