Oracle Java Copyright is Dangerous to the Developer Community

The US Supreme Court has been urged to hear Google out in its long-running copyright battle with Oracle over the search giant’s use of Java technology in Android. A number of amicus briefs have been filed with the top court in support of Google, with Microsoft, Red Hat and Mozilla, along with the Python Software Foundation, Developers Alliance, and the EFF, backing the web titan against database-slinger Oracle.

These recount an earlier court ruling in Oracle's favor on the fair use of Java APIs – stating, as it stands, that it sets a dangerous precedent that breaks long-standing and well-understood rules on software development, risks confusing the community and will damage innovation.

Google insists it built the Android platform on the computer industry’s “long-accepted practice of re-using software interfaces” – and that Oracle is "trying to profit by changing the rules of software development after the fact."

The Developers Alliance also sought to emphasize the knock-on effects of the decisions. “The current case has implications that go far beyond the two litigants involved,” as written in this PDF...

Struts Framework Problem led to Equifax Data Breach

Hackers gained access to millions of credit report holders' information via a known Java Struts vulnerability.

The credit reporting agency Equifax announced on Sept. 7 that hackers stole records containing personal information on up to 143 million American consumers. The hackers behind the attack, the company said, “exploited a U.S. website application vulnerability to gain access to certain files.” That vulnerability, according to a report on the data breach by William Baird & Co., was in a popular open-source software package called Apache Struts, which is a programming framework for building web applications in Java. Two vulnerabilities in Struts have been discovered so far in 2017.

The breach details can be found here...

Read more...

"You keep using that word. I do not think it means what you think it means"

In keeping with what a great swordsman once uttered, using that word wrong doesn't make your web service work better. The Application Programming Interface (API) in Service Oriented Architecture (SOA) is a new catch phrase, we hear. This so-called 'REST API' is almost always just an 'HTTP interface' given a fancy name to make it sound better, more so than the integration strategy many consultants are offering up. In an organization with an e-commerce or web development team, this "programmer" view makes SOA seem cool.

REST stands for Representational State Transfer, as proposed in a doctorate dissertation. This approach uses the four HTTP methods GET, POST, PUT and DELETE to execute different operations, compared to SOAP, which creates new arbitrary commands (verbs) like getAccounts() or applyDiscount(). Thus, a REST API is a set of operations that can be invoked by means of any the four verbs, using the actual URI as parameters for a web service operation. For example, we might have a method to query all case management accounts which can be called from /accounts/all/ to invoke a HTTP GET and the 'all' parameter. This tell the web service that to return all accounts, probably in an XML stream annotated for the particular client (with CSS, for example, for a browser).

Here at Bluedog, our apps have always been built with the web tier against the same set of "APIs" as the mobile tier. The advantage of a Java/WebObjects framework is "out-of-the-box" support for a variety of clients. The Ajax framework in Project Wonder provides many of the features that Rails users have come to expect, but written in a style that fits well with "The WebObjects Way" of doing things. An attempt is made to avoid writing javascript whenever feasible, as well as providing as much support for component actions as possible.

The majority of Ajax framework is written without dependencies on ERExtensions (the core framework in Project Wonder). This means that for most Ajax capabilities (the JavaScript/CSS components that give sizzle to the browser), we can use a framework without making a Web Service or Application extend any classes. Advanced capabilities can be designed using supporting classes that are available in the ERExtensions framework or by extending the open source classes such as ERXSession in our foundation frameworks.

The rise of mobile has harkened back the older client/server model which emphasized rich client interfaces, first made popular with Swing and other attempts at native Java clients. With our "API-first" development model, the Java/WebObjects tier is the interface to the device -- or client. When you put a desktop browser client, mobile native app (Objective C for iPhone or iPad) or a desktop app in front of the app server you make a mobile-enabled stack is simple. And all is right, in the world of SOA.

JAva still important to cloud efforts

Cloud and SOA - Saving the Federal Government Big Bucks
— The U.S. government's Federal Trade Commission’s long list of responsibilities includes handling consumer fraud com-plaints, the National Do Not Call Registry for marketers and iden-tity theft cases. Until recently, the FTC's information technology systems handled these different types of complaints separately without communicating with one another. But that all changed when Bluedog, a systems integrator and software developer based in Dublin, Ireland, helped bring to fruition an SOA (service-oriented architecture) that modernized the FTC’s CIS (consumer information system). The $1.2 mil- lion upgrade involved bringing open standards and a Web-based architecture to the core system. Now, with cloud capabilities "baked in," the once-radical idea of SOA as a means to de-couple services from applications means big savings, for government and commercial.

Pay it forward, or your code will continue to accrue big debts

In undertaking performance re-engineering analysis for the US Department of Health and Human Services and another commercial client, I've come across several cases where code violates what would be considered good architectural practices -- resulting in something called "technical debt," a phrase gaining attention.

Fixing code -- especially Java -- costs a significant amount of money. In the cases I've been involved with lately, the applications were being slated to move to a cloud model, and so were being "bottom up" SOA enabled. APIs were identified to expose to the wider world, and, in some case because the existing code was just too broken, select processes were just being wrapped in new Java service layers.

Read more about the concept thought up by Ward Cunningham. No matter how important an application may be, the patches, cobbled-together fixes, and duct tape approach to keeping the lights on all add up to larger costs down the road. And maybe not too far down that road -- giving new meaning to "paying it forward" when your developers spend the effort to refractor code.