Amazon Ads

Friday, July 27, 2012

SOAP-based Web Services in Java: A start-up Primer


I feel compelled to share a simple Web Service program in Java as I see this is quite an old technology that only advanced things are found everywhere - lot of generated code etc.. but the fundamentals are lost in the process...

1.     Create a SOAP-based Web Service
2.     Look at WSDL
3.     Generate Proxies
4.     Create a Web Services client

Pre-requisites:
1.     Eclipse installed with J2EE support

Not Required:
1.     Any web server as this is pure Java based


Basics:
The fundamental elements are to create:
1.     An interface
2.     An implementation class
3.     A webservice publisher

Here is the interface Definition:

package com.sai.ws;



import javax.jws.WebService;

import javax.jws.WebMethod;

import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.RPC)
public interface EchoServer {
     @WebMethod
     String echoMessage(String strMsg);
    
}

Here using annotations, we are declaring that this is a WebService Interface with SOAPBinding following the simple RPC style.

Now to the class that implements this interface:

@WebService(endpointInterface = "com.sai.ws.EchoServer")
public class EchoServerImpl implements EchoServer{

     @Override
     public String echoMessage(String strMsg) {
          String capitalizedMsg;
         
          System.out.println("Server: EchoMessage() invoked...");
          System.out.println("Server: Message> " + strMsg);
          capitalizedMsg = strMsg.toUpperCase();
          return capitalizedMsg;
     }

}




The implementation merely capitalizes the message and return he same. Note here that the annotation @WebService needs to declare that this is an implementation of the interface “com.sai.ws.EchoServer” which is the endpointInterface of the service.

Now we are done. Implemented the Service. We need to publish this service. We can publish it locally by the following:

public class EchoServerPublisher {

     public static void main(String args[]) {
          Endpoint.publish("http://localhost:9876/es",new EchoServerImpl());
     }
}

Now, you execute the above java program and your Webservice is running. Endpoint creates and publishes an endpoint for the specified implementor object (EchoServerImpl) at the given address (http://localhost:9876/es). The necessary server infrastructure will be created and configured by the JAX-WS internal implementation using some default configuration.

So far, we have created a webservice interface, implementation and published it.


Now you can view the WSDL generated by accessing the URL: http://localhost:9876/es?wsdl

This is a verbose WSDL that describes the message style, the interface consisting of the request-response style, the bindings of ‘how’ to acess the service and the ‘where’ to access it finally (the URL).

The various components of the WSDL may be summarized as follows:

How do you consume this from a client. Let us write a simple client project named “WebServiceCLientExample”. Create a class “SimpleServiceClient” in that project.

Here is the method to access the Service within the client:

     public static void main (String args[]) throws Exception{
         
          final URL url = new URL("http://localhost:9876/es");
         
          final QName name = new QName("http://ws.sai.com/", "EchoServerImplService");
         
          final Service service = Service.create(url, name);
         
          final EchoServer simple = service.getPort(EchoServer.class);
         
          System.out.println(simple.echoMessage("Hello Everyone!"));
         
     }

As you see, from the client we need to specify the URL to access the service: http://localhost:9876/es

Then we need to specify the qualified namespace that consists of two things:
  1. The URI is the value of the @namespace attribute in WSDL.
  2. The local part is the value of the service[@name] attribute at the bottom of WSDL.
As shown here:
final QName name = new QName("http://ws.sai.com/", "EchoServerImplService");

Then, we create the service as in:

          final Service service = Service.create(url, name);

Finally get our port:

final EchoServer simple = service.getPort(EchoServer.class);

Then, call the methods on that port:
simple.echoMessage("Hello Everyone!")

This completes a simple webservice and a client to the webservice in plain java. However, not that for the client to work in the above format (without any proxy generation), you will have to include the webservice project in the classpath of the client project. If not, service.getPort(EchoServer.class) will throw an error as EchoServer.class cannot be found in the path.

So, in reality, you will not have the server classes available on the client side as Webservices are for remote access of the service. In that case, you will have to download the WSDL from the URL http://localhost:9876/es?wsdl and include into into the client project. Then, right click the file and select ‘Web Services - > Generate Client’. You get this dialog box:






Select only Develop client. If you use the slider, it will generate a lot more which you can explore if you are interested.  Click ‘next’ and finish.

You will have the following files (proxies generated)




Now, you should be able to compile the client and use it remotely.

Hope this helps in your first step to SOAP-based web services.


Wednesday, May 25, 2011

OAuth - A Brief Introduction

Oauth is the rescue mechanism when you want to share some of your data with another site or software without sharing the credentials for accessing your data. For e.g. If you want to share your photos that are private on Picasa without sharing your Picasa credentials with a Photo Studio for printing, OAuth comes to your rescue.


OAuth allows this by handing out a token to the requesting site instead of sharing the login credentials itself.

The token itself can define access to which site for which specific resources and for a defined duration.

This requires implementation from the accessing site as well as the site having the resources to share with the accessing site along with the device being used for the access.


1. User logs in to the Resource Accessing site (Consumer) like a print studio’s site


2. User places an order for print of photos stored in another site (Service Provider Site).

3. The Consumer site redirects the user to the Service Provider site

4. At the 2nd site, the user signs into the account where the site questions if the user certainly wants to share the resources with the origin site. On agreeing, the service provider site creates a token with information on what resources can be accessed for how long and

5. Then the token is shared with the Consumer site

6. Based on the token provided, the Consumer site can access the resources from the Provider site.


So, in this whole process the user did not have to share the login credentials at any point of time with the consumer site. This is the biggest advantage of the OAuth mechanism and is widely used by all the major social networking sites currently.


This helps in reducing the problem of having sharing resources across sites without sharing the user credentials between them.

In the OAuth Parlance, the following jargon are equivalent:


1. User a.k.a. Resource Owner

2. Service Provider a.k.a Server

3. Consumer a.k.a Client

Monday, February 14, 2011

Developing Apps for iPhone and iPad

While both iPhone and iPad are from Apple and have the same underling OS and it is possible to run applications built for iPhone to be installed on iPad as well, porting iPhone apps to iPad is not a straight forward exercise.

In principle, the same app can run, however the user experience will not be great and will not meet the expectations of the use as the larger real estate on iPad will not be efficiently used.

Also, there are some fundamental differences between the two which have to be kept in mind while developing the applications:

Features
iPhone
iPad
Phone
Yes
No
Camera
Yes (2 for video conferencing in iPhone 4)
No
Screen Size
3.5 inch display
9.7 inch display
Resolution
960 x 480
1024 x 768
GPS
Yes
only on Wi-Fi supported Models
Sensors
Gyroscope
No Gyroscope

Every app needs to consider the Screen size and Resolution as the major difference. However apps that include phone features, GPS or Camera features will have to be rewritten for iPad. 

Also, the lack of gyroscope in iPad makes it not so very suitable for gaming apps.

Monday, February 7, 2011

Telnet on Windows 7

By default, telnet is not enabled on Windows 7 due to insecure connection security concern.


In order to enable and install Telnet in Windows 7, the steps are easy, and similar to procedures to turn on and enable Telnet in Windows Vista:

* Open Control Panel.
* Go to Programs or Programs and Features.
* Click Turn Windows features on or off.
* In the “Windows Features” dialog box, select (tick) the Telnet Client check box.

* Click OK.
* After installation is done, Telnet can be used and called immediately.

Friday, January 21, 2011

Enterprise Architect Vs. Solution Architect

There are a lot of Architects and types of Architectures that are spoken about leading to a dilution in the meaning and the responsibilities of each.

After going through the TOGAF literature on Enterprise Architecture, I was able to clearly distinguish between the roles and responsibilities of an Enterprise Architect and Solution Architect based on the work they are supposed to be doing.

Keeping in mind that Enterprise Architecture is to draw a Roadmap to align IT to Business by assessing the current state and understanding its gap from the target state, and Enterprise Architect is one who is able to come up with the transitional architectures that lead to various IT projects typically (sometimes even business projects).   EA would define the solution context along with the high level transition architectures and hand over to the 'Solution Architect' with the details of the analysis.

After this, the EA is involved only in Governance Procedures to ensure that the Solution in the project is being implemented on the suggested solution building blocks and adhering to the initially defined Architectural principles.  

It is at the point just before the roll out of projects or at the beginning of a roll out that a solution architect takes over from an EA and starts detailing the solution with the help of data, infrastructure and application architects (if required based on SMEs required). An SA would be answerable to an EA on any deviations required, justifications for the same etc.

Does this ring the bell? Is this the way the industry works? Any thoughts?

TOGAF and Zachman

There are quite a few Enterprise Architecture Frameworks like TOGAF, Zachman, DODAF, FEAF and many more.

However, the most often talked about are TOGAF and Zachman in the IT communities that I have interacted with. So, I thought, I will share my thoughts on what are the major differences between the two.

They have somethings in common but are widely different in terms of their coverage.

TOGAF is a methodology that includes a EA Process (The ADM) as well as the taxonomy and the required templates and guidelines for an enterprise architecture practice.

However, Zachman only provides only a taxonomy (pretty exhaustive) and is completely silent on the process, guidelines and techniques.

To draw parallels between the two, TOGAF suggests an Architecture Content Framework consisting of a Content Meta Model - Zachman's taxonomy maps to this part of the TOGAF specification.

Hence it is often claimed that TOGAF can work in conjunction with any other EA model like the Zachman Framework - since the taxonomy could be derived from Zachman while the process could be that of TOGAF.

What is Enterprise Architecture?

Here is my take on trying to define Enterprise Architecture:

It is a methodology
that provides a process, guidelines and techniques that help in developing an 'Enterprise Landscape' consisting of its Business Processes, its IT applications, its Data and its supporting Infrastructure (including their geographical spread)
thus enabling the enterprise to optimize and manage complexity, respond quickly to changes and align itself to the enterprise's Strategic Goal and Objectives
with clear transitional steps from the current state to the desired state, in the least disruptive way possible.

TOGAF 9 - A Brief Introduction

In the next few articles, I will be sharing my thoughts on TOGAF 9 as I am discovering it…

TOGAF 9, at the very outset is an Enterprise Architecture Methodology and a Framework. What does it mean? In simple terms, it provides the process to be followed as well as the content taxonomy along with some suggested techniques. It leds itself to tailoring for an enterprise's  specific needs.
However, it also seems like a  methodology that is very inclined towards the "IT nature" of an enterprise. I will write a separate blog article on why I feel so, with references to the TOGAF methodology.

Through its famous ADM (Architecture Development Method), it tells the various phases of a typical enterprise architecture iteration (as this needs to be done in iterations to be able to cover all the functions / verticals in an enterprise). 

I will briefly touch upon the 6 main parts that constitute TOGAF completely:
  1. The Architecture Development Method (ADM)
  2. ADM Guidelines and Techniques
  3. The Enterprise Continuum
  4. Architecture Content Framework
  5. TOGAF Reference Models
  6. The Architecture Capability Framework

A few words about what each of these mean:

ADM – This is a major component of TOGAF and provides guidance to the Enterprise Architecture group on the possible architecture development phases with each phase being described with details such as an objective, approach, inputs, steps, outputs. This is executed iteratively.

ADM Guidelines and Techniques – provides a large number of guidelines and techniques on how to apply ADM.  Guidelines help to adapt the ADM.  Techniques support specific tasks in ADM.

These I found to be basic, useful starting points and extensible.

The Enterprise Continuum – provides a model for structuring a virtual repository and provides methods for classifying architecture and solution artifacts. 

It helps in categorizing based on industry standards, architectural patterns etc. While TOGAF 8 just provided this, TOGAF 9 provides the below mentioned Architecture Content Framework which is one way of realizing the Enterprise Continuum.

Architecture Content Framework – provides a detailed model or meta model of architectural work products including deliverables, artifacts and the Architecture building blocks. This is one realization of the Enterprise Continuum.

This is very useful for creating taxonomy of enterprise architecture artifacts generated throughout the lifecycle of architectural work. Any repository to be maintained in the enterprise can get a starting point here.
The common thread across TOGAF is that every single bit is almost customizable to the context of one’s enterprise. 

TOGAF Reference Models – This provides one integration / interoperability reference model called the III-RM (Integrated Information Infrastructure Reference Model) and the TRM (Technical Reference Model).  

In my opinion, probably something known well in the industry and probably a bit archaic!

The Architecture Capability Framework – These are certain guidelines and resources to help an architect set up the architecture practice in an organization. 

This would be useful especially in the beginning of an EA practice.

Benefits of Enterprise Architecture

Of late, I have been wondering a lot about what tangible benefits would any Enterprise Architecture initiative bring to the Enterprise.
Or put in another way, when would an enterprise be driven to set up an Enterprise Architecture practice?


Here are a few reasons for starting an EA project.
  1. Rationalize / consolidate a large number of IT assets (data, application and infrastructure) that seem to have outgrown reasonable manageability (Reduce the complexity of IT Systems)
  2. Create a road-map on how IT will meet the business strategy in the years to come. ( Through performing a gap analysis after understanding the current and the target architectures)
  3. To enable an enterprise to be "agile". 
    • For the IT systems to be able to meet the changing business demands in very short cycles
  4. To enable an impact on the various layers of the organization (Business process, applications, infrastructure) due to a change in the Business Strategy or vision. Note: this is not easy for a large enterprise
  5. To bring about Process Optimization which could lead to lot of IT-related optimizations
  6. To bring about standardization across the organizations various sub-organizations
  7. To ensure the enterprise is compliant to regulatory requirements in a standard way across the organization

Monday, July 26, 2010

Multi-Tenant Architecture - First thoughts...

A Multi-Tenant Architecture:


Definition: A single instance of the application being able to serve various companies or tenants at once, providing the customized end-user experience, without having to write custom code for each tenant is said to be a multi-tenant architecture.

Benefits & Attributes:
  1. Highly Scalable
  2. Configurable
  3. Cost-effective or high ROI
  4. Multi-tenant efficient  
The Challenges:

  1. To be able to configure the application for a new tenant without incurring extra operational costs or development costs for each new set up
  2. Customization of the application can be in any of the following:
  • User Interface – Native language, time zone, keyboard input styles, UI validation rules, Truncation of strings
  • Storage of data in various languages – support Unicode character sets through all the layers of the application till data persistence
  • Business rules and workflow patterns
  • Authorization and security policies with compliance needs
  • Extensions to data models based on custom requirements of tenants
3. Providing data isolation and security between the tenants’ data


 Solution:


 “It has to be a highly METADATA driven architecture”

The solution has to consider the following aspects while being designed:

1. Data Management
  • a. Partitioning
  • b. Availability 
2. Tenant Management
  • a. Data Model
  • b. Subscription Management
  • c. Identity Management
  • d. Delegated administration
  • e. Identity Federation
3. Tenant Customization
  • a. Meta data services
  • b. Extending application data model
  • c. UI customization
  • d. Business process customization
4. Application and Data Security
  • a. Common authentication schemes
  • b. Single sign-on
  • c. Securing data transfer
  • d. Authorizations
  • e. Data isolation schemes
5. Instrumentation & Monitoring
  • a. Health
  • b. Availability
  • c. Business performance
6. Metering
  • a. Usage Models
  • b. Data model for metering
  • c. Usage tracking architectur
7. Configuration Management
8. Infrastructure Security
  • a. Provisioning (Infrastructure, Application, Tenants)
  • b. Disaster Recovery
  • c. Billing
  • d. Network operations
9. Programmable software Services
  • a. Software service lifecycle
  • b. Service versioning
  • c. Service certification, registration & publication

Thursday, June 3, 2010

Blogger Comment Notification

Hi,
Here was a small tip for which I browsed a lot but could not find help. So, finally when i discovered this tiny titbit, felt like sharing.
If you want to change the email address to which comments on your blog are to be notified ( assuming you are using blogspot), then, go to dashboard, settings, comments tab and towards the end you have a place to tell which email id should receive your comments. Type it in there or change it there  and you are done.

This may be trivial but of some help :)

Wednesday, April 14, 2010

JSF, JBoss Seam and EJB3

I just happened to explore this combination of technologies recently as it was required for a project. The first impression is that it is a providing a very impressive standards-based alternative to other frameworks which have become the de-facto standard in the Java World – Hibernate and spring.

The learnings of the community from various previous not-so-successful frameworks and some good frameworks which have been adopted by many have all been put together.

Also, there has been some out-of-the-box thinking w.r.t the way the layering has been handled. Standard JEE applications have been used to writing a lot of “glue” code for communication across the layers – presentation, business & data apart from others like integration etc. Some of the JEE patterns have been subtly built-in while some of them become redundant in this context – like a DAO or DTO or Business Delegate.

To put it crisply, here are the advantages of this combination of technologies and frameworks:

1. Provides a unified component model centered around EJB3

2. No tedious glue code to copy data back and forth between the layers

3. Supports dependency bijection – this is one of the main points that help us do away with glue code

4. Annotation driven data binding

5. Seam support JSF in such a seamless way that we do not have to have an extra layer of backing beans / managed beans – session beans itself can play the same role

6. Seam integrates hibernate validators even if we do not use Hibernate at the persistence layer. This allows for annotation-based integrated validation of data across the layers. Infact, this can do the front-end validation directly by annotating at the entity bean

7. Supports JPA lazy loading in JSF (open session in view) by default

8. Supports the use of JSF EL within EJB-QL. This makes it very clean and convenient

9. Seam support a lot many scopes as against the standard session scope. To name a few, it has – event, page, conversation, session, application, business process. This expands the horizon of how to manage state within an application and yet not have too many memory issues

10. Using Facelets as the View technology instead of JSP is the best thing that has happened. There have been many problems using JSP with JSF. Please read this article on Improving JSF by dumping JSP

11. Facelets provide templating, re-use and ease of development which have been some concerns with JSF.