Thursday, December 11, 2014

What is next for JAX-RS 2.1

Hi everyone, it's been awhile I know, but JAX-RS 2.1 is now getting shape and below are the tasks planned for this next version.

 * Adding support for SSE.
 * Improving integration with CDI.
 * Exploring support for non-blocking I/O in providers (filters, interceptors, etc.).
 * Evaluating ways in which declarative security can be supported either directly in this JSR or by leveraging other EE-platform JSRs.
 * Making JAXB conditional on runtimes where it is available.
 * Providing integration with JSON-B.
 * Building upon the hypermedia API added in version 2.0.
 * Investigating the reactive programming paradigm as a way to improve the JAX-RS asynchronous client API.
 * Evaluating any requirements necessary to support the use of JAX-RS resource classes as controllers in the MVC 1.0 JSR.

There is already a discussion around hypermedia and the challenges of supporting structural links in JAX-RS. Looking forward for a good way to deal with hypermedia and create better / intelligent APIs.

That is about it, let's see how it goes from now!

See ya!

Thursday, March 13, 2014

How the Java Community Process (JCP) works and how to contribute? #adoptajsr


The purpose of this article is to show more clearly through a workflow, how the JCP works and what actions can be taken by the community to assist in this process. The following figure shows how the process works, and instructions on how you can help. These are some ways to contribute, although there must be others that were not mentioned.




As you can see the process has several steps, and some encourage participation and collaboration of the community. Following you can understand what is done in each of these steps and how much time they take to be completed.

JSR Submission
The process starts with the submission of a new JSR through a JCP Member.

JSR Review (2 to 4 weeks)
The next step, after submission, is the JSR Review.  During this period the public can review and comment on a proposed new JSR before the JSR Approval Ballot.

Approval Ballot and Expert Group Formation (14 days)
The JSR Review é followed by JSR Arpproval Ballot, when the Executive Committee votes to approve or reject the proposal.

Early Draft Review (30 to 90 days)
Once a JSR is approved, a group of experts is formed to develop a first draft of the specification that both the community and the Executive Committee review. Members who have signed a JSPA and wish to nominate an Expert to serve on one or more of the Expert groups can do so by submitting a nomination request. When an Expert Group completes the first draft of their specification, they will make it available to the public for Early Draft Review. The Expert Group uses the feedback from the review to revise and refine the draft.

Public Review (30 to 90 days)
Next, the JSR draft goes for public review and anyone with internet connection can read and comment. 

Public Review Ballot (14 days)
At the end of the review, the Executive Committee will decide if the draft shall go to the next step.

Proposed Final Draft (Undetermined)
The Expert Group uses the public feedback to further revise the document into a Proposed Final Draft.

Final Approval Ballot (14 days)
The leader of the Expert Group then sees that the reference implementation and its associated Technology Compatibility Kit are completed before sending the specification to the Executive Committee for final approval.

Final Release (Undetermined)
Once approved, the final specification, reference implementation and Technology Compatibility Kit are published.

Maintenance Review (30 days)
A period of at least 30 days prior to finalization of a Maintenance Release when Members and the public consider and comment on the change the Maintenance Lead proposes to include in the release, as identified in the associated Issue List.

Maintenance Review Ballot (7 days)
The Executive Committee votes to approve all proposed changes to a specification to be carried out immediately or reject the changes and thus either require the Maintenance Lead to submit a revised list of changes, or defer the changes until the specification can be revised by an expert group in a new JSR. Challenges to one or more tests in a specification's Technology Compatibility Kit are ultimately decided by the Executive Committee if they cannot be otherwise resolved.

Once you understand how each step works, the question that must be popping up is: How to give feedback?
To give feedback to the JCP you can use the members@adoptajsr.java.net mailing list or if it is specifically about a spec, you can use the mailing lists of the specification itself that you will find on jcp.org.


Glossary

Executive Committee (EC)
The Members who guide the evolution of the Java technologies. The EC represents a cross-section of both major stakeholders and other Members of the Java community. EC members are appointed in an annual election process.

Expert Group (EG)

The group of Experts who develop or make significant revisions to a Specification. 

Java Specification Participation Agreement (JSPA)
A one-year renewable agreement between Oracle America and a company, organization or individual that allows the latter entities to participate in the Java Community Process.

I hope this post had contributed to a better understanding of the JCP, share if you like and let other people have access to this information. My twitter is @ivanjunckes if you want to talk about it!

See you soon!


Source: https://jcp.org/en/home/index

Thursday, October 10, 2013

Getting started with SOA

An important matter when we are thinking of SOA adoption is to know how to get started. At this stage many questions come to our minds and if we don't have someone with experience to show us the way, could be a big challange to understand the whole concept of SOA and apply it in real life. This article aims to give you a overall guideline showing how you can quickly get started.

The transition to SOA can be addressed in many different ways, it all depends on how mature is your company's IT, as well as the reasons for adopting SOA. A SOA adoption can be thought of as continuum with four broad levels, and each level you reach will bring you better business value.
  1. Implementing individual web services. In this level companies create web services from tasks in existing or new applications.
  2. Service oriented integration of business functions. In this level, companies integrate two or more applications using web services or other service oriented architectures.
  3. Enterprise wide IT transformation. In this level, companies can use SOA as their standard for exposing application functions; companies are able to use SOA to integrate to any application.
  4. On demand business transformation. In this level, companies are able to change their software and partners quickly in order to meet the changing needs of the business.
 Let's now detail each of the previous levels, showing ways of putting them in practice:

Level 1
  • Exposing functions of an existing application as web services.
  • Creating a new application using web services from another application.
  • Creating a new application that contains web services and uses those web services. 
Level 2
  • Analyzing two applications in order to determine what services are needed.
  • Choose SOA infrastructure and tools, creating standards, and so forth
At this level governance is becoming important.

Level 3 and 4 

When starting with enterprise wide IT transformation or on demand business transformation, governance and executive buy-in are critical. Starting at this level is usually part of a strategic transformation of business that involves analyzing the company's current state, the company's strategy, the company's IT systems, the trends in the company's industry, and technology trends.

Transitions that start at these top two levels frequently involve many steps and include steps to verify assumptions and validate decisions made in previous steps. These verifications can include reviews by experts, as well as testable prototypes for measuring quality of service factors such as performance and usability.

That's all folks, hope this article can help you to get started with SOA in your company!

Bye!


Source:
VW003 - Introducing the Value and Governance Model of Service-Oriented Architecture, IBM Corporation, 2007.


Friday, September 27, 2013

JAX-RS 2.0 Client API Generic Type Response Entity

Hi folks!

The last POST we learned how to use the new JAX-RS 2.0 Jersey API, you can read the introduction there. Today we will talk about the detail that was missing for reading JSON responses that uses a generic type.

The code below shows how to setup the WebTarget with the URI you want to request and then it is executed when you call the get() method. Note that this is not different from the first example.
 
Client orderClient = ClientBuilder.newClient();

WebTarget target = orderClient.target("http://localhost:8082/rest-client-api-example/resources/orders");
Response response = target
.request(MediaType.APPLICATION_JSON)
.get();
So, now we will see what really makes the difference using generics. The following line shows how a generic type should be read.

 List<order> orders = response.readEntity(new GenericType<List<Order>>() {});

It doesn't look good, but this anonymous class will do the trick. Remember that you need all the dependencies listed at my github to make this work properly.

This is it, I hope it helped!

Thursday, August 29, 2013

REST JAX-RS 2.0 Jersey Client API

Hello, everyone!

This post will show an example of how can you use the new JAX-RS 2.0 Client API from Jersey.

For this project we will use JBOSS AS 7.1 (Port 8082) with Maven and our plan is to consume a REST service asking for an "Order" passing an id as a parameter.

So let's get started!

This first line of code will give you a new instance of the client.
Client orderClient = ClientBuilder.newClient();

The next step is to make a GET request to a WebTarget (A resource target identified by the resource URI) asking for the "Order".
         WebTarget target  = orderClient
                                .target("http://localhost:8082/rest-client-api-example/resources/orders/{id}");
         Response response = target
                                .resolveTemplate("id", 1) // Resolves the {id} template
                                .request(MediaType.APPLICATION_JSON)
                                .get();
Note that you also could use another http method like post(), put() or any other you choose. After that you just have to check if the response is OK (Status code 200) and read the entity, if you are trying to read a List<Order> it will be a bit tricky  and I will be writing a post just for this case (The code for this is under github, check that out).
        
  if(response.getStatus() == Status.OK.getStatusCode()){
   Order order = (Order) response.readEntity(Order.class);
   
   System.out.println("Id: " + order.getId());
   System.out.println("Name: " + order.getName());
   System.out.println("Price: " + order.getPrice());
  }else{
   System.out.println(response.getStatus() + " " + response.getStatusInfo());
  }
So if the service is running and everything is ok, you will get the Order correctly from the server and it will be printed in the console.

The full example with maven configuration and code is under https://github.com/ivanjunckes/rest-client-api-example repository, be free to fork it. There you also will find the REST service and the client implementation.

See you next time! Thanks.

Tuesday, July 30, 2013

SOA Life Cycle


Hello everyone, this article will show how SOA Life Cycle works and what happens in each one of the stages.

Model

The first step in a service-oriented architecture project has little to do with technology and everything to do with your business. The first step is to establish what these business activities or processes actually are.

In the model phase you start by gathering business requirements and then you design and optimize their desired business process.

By simulating, or modeling, your business processes before you write a line of code, you gain a much deeper understanding of them before looking for trying to build software that helps you carry them out.
 
Assemble

After business processes are modeled and optimized, developers can implement them by building new services or by reusing existing services, and then assembling them to form composite applications. The assemble phase is about finding functionality that already exists and service-enabling it.

Deploy

When they are modeled and assembled, the assets that make up your SOA are deployed into a secure and integrated environment. The deployment needs to meet the performance and availability needs of your business.

Manage

The deployed system must be managed and monitored, both from an IT and business perspective. Information gathered during the manage step is used to gain real-time insight into business processes, enabling better business decisions and feeding information back into the life cycle for continuous process improvement. You deal with issues such as quality of service, security, and general system administration.

In this step, you monitor and optimize the system, finding and correcting inefficiencies and problems.
Because SOA is an iterative process, the completion of this step is the start of a new model phase.


Source:
http://pic.dhe.ibm.com/infocenter/esbsoa/wesbv7r5/index.jsp?topic=%2Fcom.ibm.websphere.wbpm.scenarios.esb1.doc%2Ftopics%2Fcwesb_security.html
VW003 - Introducing the Value and Governance Model of Service-Oriented Architecture, IBM Corporation, 2007.

Monday, July 22, 2013

What is Service Oriented Architecture (SOA)?

This article will give you an introduction about what is Service Oriented Architecture (SOA) and the different roles that interact with this.

Let's start, describing a Service:

From a business view, a service is what is needed to support the business process. Think about what your company does on a day to day basis and break those business processes up into repeatable business tasks or components.

What is a Service?

A repeatable business task.


A service is an application component deployed on a network-accessible platform hosted by the service provider. Its interface is described by a service description to be invoked by or to interact with a service requester.

Services are functions or operations accessible across a network with:
  • Well-defined interfaces.
  • Well-defined quality of service capabilities.
  • Well-known endpoints. An endpoint is a destination on the network that receives service requests.
Service providers
  • Offer services with published interfaces, policies and endpoints.
Service consumers
  • Use services and access them securely and reliably.
Service mediators, handlers and intermediaries
  • Provide extensible discovery, selection, metering, monitoring, logging, and more qualities of service.

Describing the SOA architectural style

You can adopt the architectural style that SOA supports by:
  • Breaking business processes up into repeatable business tasks or components.
  • Assembling the solution by snapping components together.
  • Becoming service-oriented.

What is a Service Orientation?

Building on the definition of a service, service orientation is a way of integrating your business as linked services and, more importantly, the outcomes that they bring.

What is SOA?


SOA is the IT architectural style that supports the service orientation thought process and makes it a reality.

Services are repeatable business tasks. Business processes are a series of services snapped together like building blocks. SOA is an architectural style that makes this possible.

SOA helps make building and adjusting composite applications fast and easy.


SOA in different Roles

Business Managers

SOA provides business managers with capabilities to expose a set of services to clients and partner organizations.

Business Architects

SOA is an architectural style that requires a service provider, requester, and a service description. It addresses characteristics such as loose coupling, reuse, and simple and composite implementations.

Implementation

SOA is a programming model complete with standards, tools, methods, and technologies such as Web Services.

Operations

SOA is a set of agreements among service requesters and service providers that specify the quality of service and identify key business IT metrics.

In the next articles we will continue to talk about SOA.



Source: VW003 - Introducing the Value and Governance Model of Service-Oriented Architecture, IBM Corporation, 2007.