What can the cloud do for your business or your mobile presence?

The “cloud” is really not a new concept in the lower rungs of software development. For the most part, enterprise architecture has been pushing everything back to a server for many years, but in the consumer space, the cloud is indeed a bright and shiny new toy.

Several years ago, I embarked on the journey to get all of my data stored onto someone else’s server instead of having said data always on my laptop or on a backup drive. In the event of a catastrophe, I wanted to make sure everything was safe and sound just in case my laptop were to crash or get stolen. I enlisted the services of Mint, TurboTax, Google Docs, DropBox, etc., all are wonderful cloud-based services.

So what exactly does “cloud” mean? Simply, it is storing your data somewhere else via the internet. Let’s not get into Platform as a Service, Big Data, Cloud server distribution or all that other nomenclature other than to say that there are degrees by which you “buy into” the cloud. How does it benefit you as the consumer? It mostly means that your data is persisted somewhere you can always get back to it from any device whether it is mobile device, laptop computer or desktop PC. The major advantages are convenience and piece of mind that your data is safe. With this comes a trade off. Your data is no longer really your own. It is less secure by virtue of just being transmitted back and forth and available to millions of people who might be able to get at it in a worse case scenario.

From a mobile perspective, the cloud strategy makes perfect sense. In the purist sense a cloud strategy might involve a simple web-based user interface that supports all browsers on all platforms, but with the current “app craze”, it makes more sense to go beyond this and also provide native apps running directly on mobile devices to interact with these cloud services. The reasons to have a native mobile app go far beyond having and app just for the sake of having one. A native app gets you coverage in an app store whether it is the Apple or Chrome app store, so a side-effect is market presence. A native app gives a far richer user experience than any web-based app can offer. A native app means that you have the ability to function in an offline mode and still give the user a way to accomplish their tasks and sync up with the cloud later.

Creating a native app and interacting with the cloud is no different than interacting with the cloud via your web interface, or for that matter, a native desktop application that accesses your data via the same cloud services. Think about your user interfaces as you would a mask. You have a different mask every Halloween, but your face is still the same and really that is the important thing. After all, buying a new mask is far cheaper than paying a plastic surgeon for  a new face. In terms of cloud services, most businesses already have some infrastructure for supporting multiple interfaces back to the same services anyway, it is just a matter of exposing those as something that native apps can consume.

From the perspective of business, the cloud takes on a whole new meaning as opposed to how a consumer would see it. Corporations are switching to cloud-based services to offload their once internal applications to a software-as-a-service provider. Here are some good examples of how businesses have taken to the cloud, Github for source code control, Google Docs instead of Microsoft Office, Google Business Services instead of having a traditional “in-house” mail server like Microsoft Exchange and Sugar or Bullhorn for CRM Solutions. By utilizing these cloud services, companies that could not afford an IT presence, now have the tools much larger companies have enjoyed for years on a tighter budget. Also, if we go back to those degrees of cloudiness I mentioned, you see that even maintenance costs that were once incurred to you directly would be an inherent benefit if you chose a Platform as a Service (PAAS) in the cloud. PaaS allows you to forget worrying about scaling servers, managing backups, handling server security, blah, blah blah… the things that do not deal with your core application logic.

Now that more businesses have progressed into the cloud, not only have they reduced their costs, but they have also instantly enabled a mobile presence in their business. Businesses that use Google Docs, example or Google Business now have automatic access via several great mobile applications. Employees with these companies now can enjoy greater flexibility on where and when they can work using their mobile devices and the cloud enables that data to be available no matter what interface they sit down in front of or what internet connection they use. With more and more companies offering remote work, telecommuting and co-working opportunities to remain competitive, it has given validity to the cloud as a viable mechanism for enabling businesses to function.

Cloud-based service adoption has flourished among newer more agile companies and on the consumer front. The larger corporate machines are just starting to see the value and determining how they can make a go of it. While all this is going on cloud-based service companies and mobile tech leaders are reaping the rewards of such a fantastic approach to how we do business in this new age.

Services are the key to choosing an enterprise mobile developer

There are more gotchas in software than in professional politics unfortunately. Some are a lot more serious than others and some are downright unforgivable. I’ve found the lynchpin for mobile development to be not in the app itself, but in the supporting services.

Not all apps require services to communicate back to the server, but in a corporate environment 99% of the time they do. This is where the problems arise. Most mobile developers are so focused on user experience and they have blinders to anything that exists other than their app…. it’s the only thing in their ecosystem as far as their concerned. In reality, the mobile app is just the tip of the iceberg. It’s an old analogy but think about a corporate system being one large iceberg with many points that stick out of the water. At the surface, it could appear to be multiple icebergs moving freely, but underneath, it’s all the same mass.

The average mobile developer has discipline in only one thing… mobile user interface design. To develop a corporate app, it is important that you look at the complete package of a system from the perspective of an architect. This is where a background in software architecture and a lot of experience comes into play. The mobile developer is just another developer under the umbrella of software engineering, a cog in the machine. When starting a mobile project, it is important to hash out the supporting web services first, not to design the app and drive the services from the app. Services should be based on solid use cases and user stories and the app will come. A matter of fact, doing it this way makes it simpler to add on different mobile devices or web clients later on.

Over the past three years, I’ve seen a lot of examples of mobile projects that have failed. The failures came for a lot of reasons. The main reason was money. Most folks have an unrealistic expectation of what a mobile app should cost and there is the misconception that because it is smaller, it takes less code to accomplish a task or that since the app is simple, it should be easy. Simplicity on the front end doesn’t always equal less complexity on the backend. The second reason they fail is a lack of experience in overall system architecture. For example, a company hires a developer who has a nice shiny portfolio or self-contained apps with no backend in the app store with the intention of building a corporate app. The developer is immediately in over their head since they have no experience dealing with web services or complex corporate integrations. The developer is usually the cause of this failure because almost always the cost of the app is underestimated to the client at the beginning, this leading to problem #1.

There isn’t anything wrong with being an enthusiastic young developer and loving mobile and almost every mobile developer these days are in their early to late 20s and have no software experience outside of maybe web site design. Don’t get me wrong, I’d hire a smart mobile developer just like this in my enterprise, I just wouldn’t put them to designing an enterprise system of doing the requirements gathering and estimation all by themselves.

Here are some tips to help you choose a mobile developer if you plan on finding someone to do an end to end mobile solution for you.

  • Ask the mobile developer for a resume (Seems like a no brainer, but some people don’t ask)
  • Ask the mobile developer about apps they have done for corporate clients. (If they don’t have any, you might want to pass)
  • Ask them for examples or a demo of their current work. (In particular, apps that maybe resemble the types of functionality you want in yours, for example, offline capability, data storage and service communication)
  • Look at who they have done work for
  • Beware the gamers and 3D junkies. The type of developer that is focused on writing games and likes integrating 3D features in an app, usually isn’t the right fit for an enterprise application. This pairing usually ends in deep frustration.
  • Look at how many apps they have submitted to the app store and what each app does. If the body of work is mostly app store submissions with apps that don’t require an internet connection, then you might just have someone who may  not be a good fit for a doing enterprise level work.
  • Ask for timelines it took to develop some of their apps and then ask for a ball park estimate at a high level for what you want to do. If the number seems to good to be true… it is.
By no means are these tips absolute but they are good starters to get yourself acquainted with a candidate.

A good enterprise mobile design should be flexible. It should have the ability to interchange mobile interfaces or web interfaces without having to change the back end. This is the essence of interface-drive design. The backend code should be written by someone seasoned with plenty of experience in service design. Proper expectations should also be set from the start. Having a great mobile developer with a talent for interface design is important, but keep in mind, it is merely one of those little points of the iceberg sticking up out of the water.

Create a winning web services strategy with a hub

SOA Architecture and Enterprise Service Bus aren’t new concepts to IT but the drive to migrate to RESTful services over the past few years has made them more relevant than they once were. A good rule of thumb to follow to determine if you need an ESB is to analyze and visualize what your infrastructure looks like. Service bus architecture works best when your architecture looks like a wagon wheel or “hub” with spokes, multiple systems whether they be external and internal communicating with a central “brain” or repository of information.

Let’s look at some of the reasons an ESB implementation is a good idea.

  • An ESB provides a facade or interface on top of external systems that your applications need to interact with providing you with ability to replace those external systems at will without changing the in front of the ESB. Simple interface-driven design at it’s best.
  • An ESB provides a common home for your enterprise business logic, data transformations and hard core systems interactions.
  • User interfaces into the system can also be more readily shifted from one technology to another making you more agile. Also, multiple interfaces can run off the same ESB services, e.g. iPhone, iPad, Ajax framework UIs, etc.
  • An ESB gives you an external API for other business partnerships to integrate with you… Most often third-party integrations are an afterthought resulting in a reactionary measure to accommodate another system
  • An ESB encourages code reuse in your enterprise…
  • An ESB gives you a set of standards, SOAP, MTOM, REST, JSON, etc. Standards make integrations much simpler.
  • Developers are no longer accessing your databases directly with code. Control over performance is pushed back to the ESB tier.
  • An ESB is ideal in an environment where you need “translation”, multiple systems in .NET, JAVA, PHP, C++ and legacy
A lot of great reasons to use an ESB in your system architecture, but an ESB isn’t the catch all solution. It has a few drawbacks that need to be considered.
  • ESB implementations aren’t for the faint of heart. It takes some expertise to plan and execute a successful hub.
  • ESB-based systems have an increase in network chatter since all interactions are back to the ESB via the network.
  • There are not many open source solutions for ESB implementation. MuleESB is the leading one for Java. Commercially, BizTalk, webMethods and TIBCO are available but extremely expensive, but also feature rich..
  • In larger IT organizations, an ESB implementation is usually confined to a small group and other groups tend to ignore it’s existence and continue to write logic straight into their projects, creating a silo approach of small isolated projects with duplicated logic and code.
  • ESB can create a bottle neck in larger organizations that have many projects running in parallel. The ESB team has to grow to meet the demand by other groups and service their requests.
  • An ESB doesn’t make sense if you have a small number of system interactions. For example, a product company with a single product and database doesn’t need an ESB implementation. Again, it goes back to what your visualization looks like. In this example, the diagram one be a single spoke and we are looking for the wagon wheel…
ESB, HUB, SOA… whatever you want to call it, it is all about the same thing. Reducing complexity, reduce cost of ownership, increase agility and provide easy integrations to make your IT organization successful.

Make your Web Services simple with Apache CXF and Spring

Have you ever just wanted to make Java Web Services so easy that you can whip one out in a few minutes, well here is your shot. Apache CXF and Spring make creating a Web Service almost stupid simple. I’ll get right to it.

First you need to configure CXF in your web application by adding a few lines to the web.xml.

CXFServlet

org.apache.cxf.transport.servlet.CXFServlet

CXFServlet
/ws/*

All this is doing is setting it up so that all requests for /ws/* to get routed to CXF. Now we need to include a new xml file for Spring to load.

<beans xmlns="http://www.springframework.org/schema/beans&quot;
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance&#8221;
xmlns:context=”http://www.springframework.org/schema/context&#8221;
xmlns:cxf=”http://cxf.apache.org/core&#8221;
xmlns:jaxws=”http://cxf.apache.org/jaxws&#8221;
xsi:schemaLocation=”http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://cxf.apache.org/core
http://cxf.apache.org/schemas/core.xsd
http://cxf.apache.org/jaxws
http://cxf.apache.org/schemas/jaxws.xsd&#8221;
default-autowire=”byName”>


<bean id="aegisBean"
class=”org.apache.cxf.aegis.databinding.AegisDatabinding”
scope=”prototype”>

<bean id="jaxws-and-aegis-service-factory"
class=”org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean”
scope=”prototype”>

<jaxws:endpoint id="applicationWebService"
implementorClass=”com.domain.services.impl.ApplicationServiceImpl”
implementor=”#applicationService”
address=”/applicationService”>

Now, we are ready to write our service class. I typically create service classes to interact with my other backend services, databases, web services, etc. Here is an example.

@WebService(endpointInterface = “com.domain.services.IApplicationService”, name = “applicationService”, serviceName = “applicationService”, portName = “applicationPort”, targetNamespace = “http://services.domain.com/&#8221;)
@Service(name=”applicationService”)
public class ApplicationServiceImpl extends ServiceImpl implements
IApplicationService {

public String sayHello(){

return “Hello”;
}

And that is pretty much it. Start up your Web server and hit /ws/applicationService?wsdl and you should get a WSDL for the service automatically generated. You can use SoapUI as a testing tool to test out the services. You can also use SoapUI to generate any type of client that you want for the services, JAX-WS, JAX-RPC, Axis, you name it.

It doesn’t get much easier than that does it? I’ve only scratched the surface of CXF as well. It has many more features.

Spring and CXF make a truly versatile way to create an SOA architecture or an Enterprise Service Bus all on your own as well.

My Big String Store Web Service

A few weeks ago I was interviewing with a company in another city. After an “interesting” first phone call, I was told by the recruiter to expect a Brain Bench test. I normally refuse these tests because they really don’t gauge anything regarding skill, just route learning. I’ve got about 12 years of Java under my belt, I have passed all my certifications and those tests are much more difficult than Brain Bench.

Well the test never came…instead I got this request for a project.

—–> Email

Our company is no longer using BrainBench to gauge a candidate’s strengths and have asked that I send the following “puzzle” instead to potential candidates:

You need to build two simple web services:

1) A service that accepts an arbitrarily large string as POST data. If the service has seen this exact string before, it returns as response indicating that the string is a duplicate. Otherwise, it returns a response indicating that the string is not a duplicate.

2) A service that enumerates all strings that have ever been seen and returns them all as a list.

** Note: You only have a single machine to work on.
** Note: You have insufficient disk space to serve all of the requests and want to maximize the number of requests you can serve before running out of disk space.
** Note: There is no rhyme or reason to the distribution that governs the characteristics of the string data that you may encounter.
** Summarize a detailed design outlining your approach in no more than two pages, the tradeoffs you’ll make, any particular assumptions, etc.

Rather than prescribe a particular format for the puzzle above, we are interested to see how each candidate answers (i.e. they can use pseudo code, actual code or provide a narrative response).

We believe this change provides us a better way to gauge candidate ability instead of a standardized test like BrainBench.

<—— End emailAt first I refused to do this. I was working two jobs at the time and had no time to write someone else's code for them. Aside from this project being extremely vague and lacking in requirements that are necessary for proper planning and design,I just did not have the time. So, today I decided I'd whittle this little project out for the fun of it. The basic tools required to run this project are Spring, Hibernate, XFire, Junit, Unitils and some relational database. I used Oracle, but any would do. Below are the schema and classes you need to create.We will use a single table initially and use a varchar2, but we don't know if the strings will exceed the limit of 4000, so we may need to use a Clob later on. Since our data could exceed 4000, we won't index the string itself. Indexing with a clob can be tricky.
SQL> create table ASCII_STORE (ASCII_STRING_ID number not null primary key, ASCI
I_STRING varchar2(4000) not null);

Against my design rules, I created the table first and then I mapped a Hibernate class to it.


@Entity
@Hibernate //My own Annotation to denote a Hibernate mapped class
@Table(name="ASCII_STORE")
public class AsciiStore extends DataObject {

private Integer id;

@Override
@Id
@Column(name="ASCII_STRING_ID") //We need an id for quicker lookup
public Integer getId() {

return id;
}

@Override
public void setId(Integer id) {
this.id = id;

}

@Column(name="ASCII_STRING")
//@Index(name="IDX_ASCII_STRING") //A unique String value indexed.
//@Unique
public String getAsciiString() {
return asciiString;
}

public void setAsciiString(String asciiString) {
this.asciiString = asciiString;
}

private String asciiString;

}

Now we’ll create a DAO and a Service class that we will expose via XFire as a Web Service. XFire will dynamically generate our WSDL and we can let our Enterprise Service Bus or a client directly consume that.


//Our DAO
@Repository("asciiDAO")
public class AsciiStoreDAO extends GenericDAO {

protected AsciiStoreDAO() {
super(AsciiStore.class);

}

}

//Our Service Class
@Service("asciiStringService")
public class AsciiStringServiceImpl extends ServiceImpl implements IAsciiStringService {

private AsciiStoreDAO asciiStoreDAO;

@Autowired
public void setAsciiStringDAO(AsciiStoreDAO asciiStoreDAO) {
this.asciiStoreDAO = asciiStoreDAO;
setDAO(asciiStoreDAO);
}

public Collection recallStrings() {
return asciiStoreDAO.findAll();//OutOfMemoryException possible
}

public void saveString(AsciiStore store) {
asciiStoreDAO.save(store);

}

}

@Service
public interface IAsciiStringService extends IService {

@WebMethod //Expose as our Web Service, you must configure XFire to expose
public void saveString(AsciiStore store);

@WebMethod
public Collection recallStrings();

}

We have two methods we will expose on our Web Service. One is to store our really large strings, in this case up to 4000 characters. Remember, we need to use a Clob if they are going to be larger. We are also using the String objects hashCode method to generate our key for the table. The data index storage will be smaller if we use a number and we can store more strings before our disk space is exhausted than a design that indexes the string itself. Also, in my design the insert, update and delete operations will be faster because of the more efficient primary key index on a number. However, if we ever need to search by the string, we will have to index it, but I do not ever see this being needed since we can more quickly access the string from it’s hashCode(). I did this quick, but I could have easily used an Oracle sequence. There are too many ways to implement this without more specific requirements.

Now we write out test class using JUnit 4 and Unitils. We will test both methods that will be exposed as Web Services. The possibilities are endless for how we can store and retrieve these strings.

public class AsciiStringServiceTest extends MainTest {

@SpringBeanByName
IAsciiStringService asciiStringService;

@Test
public void randomStringStore(){

//while (true){

for (int i = 0; i < 100; i++){ Random random = new Random(); long r1 = random.nextLong(); long r2 = random.nextLong(); String hash1 = Long.toHexString(r1); String hash2 = Long.toHexString(r2); String hash = hash1 + hash2; AsciiStore store = new AsciiStore(); store.setAsciiString(hash); store.setId(hash.hashCode()); asciiStringService.saveString(store); } } @Test public void recallString() { //This will obviously not work as the table gets bigger, //but it's a requirement. Would work better streamed from // a file to a socket or attached to a Soap message via MTOM. Collection allStrings = asciiStringService.getAll();

for (AsciiStore asciiStore : allStrings) {

log.debug(asciiStore.getAsciiString());

}

}
}

I’m not writing the Web Service client code, because it is basically calling the same methods. Get the basic logic and design down and then worry about the SOAP footprint and performance from the front end.

Off hand, since I would be dealing with a Web Service, I might return the keys of the strings in the method where we retrieve all strings and let the user pick a certain key to get to the string. If you have a String,you really already have the key in the hashCode() method. The key here is making sure that hashCode() always returns the correct key, which in the case of a String object, it will.

Another problem here is storage and availability. As the requests scale up, so shall the Web Service application server. We’ll have to create clusters, cluster the database, start techniques by which we can partition the data. As this scales, we won’t be able to have a one machine requirement.

As far as the response indicating if it is a duplicate or not, I didn’t implement it. We could simply do this by changing the method to return a boolean flag indicating if it is a duplicate or not. In my design, an exception will bubble back to the Web Service indicating the duplicate, else, it just stores it.

One thing we may consider here on the Web Service would be if the String is exceptionally large, we could send it to the Web Service as an attachment using the Web Service MTOM specification and retrieve it in the same fashion.

I am assuming in my design that I am just going to let the Oracle tablespace that this table is in run wild initially and consume the machine. You’ll notice that the while(true) in my test method is commented. I let this run for a few minutes as my machine filled up the table and the tablespace started to grow. I was extremely satisfied by Oracle performance in a tight loop such as this.

A huge problem here is the second method and requirement. Returning and iterating over every String in the list is a little insane. We are definitely looking at running out of memory here unless we rewrite this to attach the data and pass it back through MTOM somehow or use something other than a Web Service like a socket where we can read and stream the data.

I could go on and on with these requirements hypothesizing about what we could do and couldn’t do, but in the end, these are poor requirements. However, even though the requirements are poor, the service is designed with very scalable and versatile concepts. Any change in requirements would be a very quick change to the design and not a rewrite.

So, this is my solution, if you can call it a solution. I consider this kind of exercise no different than a Brain Bench test. I say give me a “real world” problem and let me solve that or let me collaborate with a team to get some ideas. Don’t give me an imaginary problem that you pulled out of your..well….let’s use the word “head” shall we.

Inside the XFire – Making Web Services almost too easy

By Chris L Hardin
Sr. Software Architect
Have you ever just wanted to make Java Web Services so easy that you can whip one out in a few minutes, well here is your shot. Xfire and Spring make creating a Web Service almost stupid simple. I’ll get right to it.

First you need to configure XFire in your web application by adding a few lines to the web.xml

    
    xfire
    org.springframework.web.servlet.DispatcherServlet

    xfire
    /xfire/*

    

All this is doing is setting it up so that all requests for /xfire/* to get routed to xfire. Now we need to include a new xml file for Spring to load.

        class=”org.codehaus.xfire.annotations.AnnotationServiceFactory”>
                   
       
                   
       
                   
       
              class=”org.codehaus.xfire.annotations.jsr181.Jsr181WebAnnotations”>;  

Now, we are ready to write our service class. I typically create service classes to interact with my other backend services, databases, web services, etc. Here is an example.

@Service(name=”myService”)
public class MyServiceImpl implements IMyService {
   
   
    @WebMethod
    public String  sayHello(){
       
        return “Hello”;
    }

Now we need to mount our service in the xfire-servlet.xml that we added earlier.

   
       
           
               
                   
               
           

       
   
   
   
   
   
   
   
       
       
           
       
       
           
       
       
           
       
       
            IMyService
       
   
   

And that is pretty much it. Start up your Web server and hit /xfire/myService and you should get a WSDL for the service automatically generated.

It doesn’t get much easier than that does it? I’ve only scratched the surface of XFire as well. It has many more features. Did you know that you could also mount a Web Service as a Spring Bean and get a reference to it by simple dependency injection? I use it all the time. If you are working with Axis, just point Eclipse to the WSDL, tell it to create a client and then inject the Proxy it creates into another class and voila, you have a reference to your Web Service.

Spring and XFire make a truly versatile way to create an SOA architecture or an Enterprise Service Bus all on your own as well. Let me know when you have stood “inside the XFire”. Feel the burn baby.