Archive
Free SOA Service Design Cheat Sheet
This simple cheat sheet contains all the key goals, principals and design patterns that you should be aware of when designing SOA services and contains helpful links to places where you can find more in-depth information on each topic.
Implementing Entity Services using NoSQL – Part 3: CouchDB
Following on from part two of this series where I created and deployed the Product Entity Service using the SOA ‘contract-first’ technique, I’m now going to work on the NoSQL database aspects of the service implementation.
Creating Business Agility by Design.
Agile engineering practices are really good for ensuring that IT development priorities are responsive to business requirements, but they don’t necessarily deliver an agile business.
I define ‘business agility’ as ‘the ability to quickly harness what you already have to make the most of an emerging business opportunity‘.
Let’s explore that sentiment a little. How easy is it for your business to ‘harness what you already have’?
The most common problem that I see when I’m working with clients is brittle applications, applications that can’t be easily accessed, re-purposed or reused to respond to changing business demands. For example: inaccessible and intransigent fulfilment processes locked inside big ERP systems that prevent lucrative new channels from being offered to customers, or payment processes that don’t meet compliance targets but can’t be removed or replaced without breaking something important.
No matter how modern the system, or how many ‘best practices’ are used in its development, reuse often remains stubbornly elusive. Sadly agile project management practices can’t come to the rescue either. Agile development practices generally have no effect on the long-term reusability of an application one way or the other.
‘Business Agility’ = ‘Easy Reusability’
In the current climate, reuse is probably the most important non-functional requirement that you could possibly express. However, there are many competing techniques for achieving reuse in software systems so the key is to understand which techniques can really help you and which should be avoided.
I’d argue that ‘Easy Reusability’ is the result of careful interface design coupled with simple accessibility. The techniques that you use to build your software systems should reflect these goals.
Interface design should try to take into account the broadest requirements possible, with ‘future‘ use-cases given appropriate levels of consideration. Likewise, simple accessibility (or interoperability) can be achieved by choosing interface standards that will allow for easy access from a suitably wide variety of consumers.
SOA can provide a good solution.
In my experience, Service Oriented Architecture (SOA) is a good paradigm for delivering both easy reuse and business agility. What’s more, when you combine SOA with modelling techniques that encourage the identification of future reuse opportunities you can create a very powerful environment for delivering some serious business agility.
Contact me to find out more.
Ben Wilcock is a SOA Consultant working for SOA Growers Limited in the UK.
Book Review: RESTful Java Web Services
Introduction.
RESTful web services have been with us for a while now, and initially I, like many others, was put-off by the general lack of information on how to design and implement a RESTful web services correctly. However, a number of books are now available that attempt to guide the way by documenting the RESTful standard, its principals, and the Java implementation frameworks available to help.
Packt Publishing have teamed up with Jose Sandoval to publish their offering: “RESTful Java Web Services” — a short-format & developer-focused book that attempts to quickly tutor the reader on the RESTful standard and illustrate how to code RESTful services with a number of popular REST frameworks.
Review.
RESTful Java Web Services begins with a discussion on the principals of RESTful applications and how RESTful Web Services can play a part in a well designed Service Oriented Architecture (SOA). The core concept at the heart of REST is the provision of web-accessible ‘resources’ or entities that can be created, edited and deleted by users issuing standard HTTP requests. These resources are presented to users via ‘representations’ in the users chosen format (often with multiple format’s available for the same resource). This combination of existing technologies, flexible formats and fixed interaction types is attractive because of its simplicity and flexibility — something you don’t often hear when evaluating other SOA technologies.
Before moving on to discuss the details of RESTful service implementation with Java, the book first deals with how to successfully access a RESTful resource using a number of different HTTP client API’s such as Commons HTTP. It’s a useful introduction but unfortunately no TDD related RESTful client API’s or SOA testing tools are offered for consideration — an omission that you should be aware of if you buy the book.
The books core chapters cover the coding of RESTful services using four freely available Java based implementation frameworks; Jersey, RESTEasy, RESTlet and the Struts Rest plugin. Full source code is provided on the Packt website to support the text, and this allows the reader to get involved without too much effort. Download locations for each of the open source components are also provided at the start of each technical chapter.
The Jersey JAX-RS framework is first up, and the author uses this opportunity to create a simple 3-tier RESTful web service (a Twitter like Application Programming Interface or API) that’s based on a bunch of reusable Java classes for business logic and data storage. The service API and classes are re-used later on with all the other frameworks in order to keep coding to a minimum and to allow the reader to focus on the salient points of RESTful service development with each framework. Techniques for RESTful API analysis and design are illustrated, demystifying how to correctly select the ‘resources’ that the service API will manipulate and the format of the service’s endpoints that clients will call to communicate with the service. Representation formats are also covered, with the author opting for the commonplace XML/JSON over HTTP. The sample service is developed using the JAX-RS annotations implemented by Jersey, with the HTTP GET, PUT, DELETE and POST methods all being adequately documented and explained.
Because of the distance covered, this first section is quite meaty, but you are left with a sense of just how easy implementing RESTul services can be, especially when you acknowledge that the majority of the code samples given are for the supporting application tiers rather than the RESTful service implementation.
RESTlet is next to be used, with version 1.1 and version 2.0 both being covered at the same time. As the same sample Twitter-like service is being implemented each time, the common code is re-used allowing the focus to remain on the specifics of the RESTlet framework. Version 1.1 of RESTlet appears fairly old-school in its approach, requiring the overriding of methods, while version 2 adopts a more modern annotation based approach. For me, the code samples now started to get a bit repetitive, and experienced readers may find themselves skipping forwards as they start to grasp the basics of each framework. The reuse of the sample code does help, and the author’s highlighting of the relevant bits ensures you don’t miss something important.
The RESTEasy framework presents the author with a dilemma because it implements the same JAX-RS specification as the Jersey framework covered earlier. The result is that the sample code is practically identical to the earlier Jersey example. The author chooses to deal with this problem by simply getting through the required information quickly and sticking to the defined scope of the book. This may please most readers, but its another missed opportunity as more could have been said about RESTEasy’s additional features like its support for ATOM feeds or EJB’s.
The Struts Rest Plugin is the last framework discussed in the book, and its a bit of an odd man out. Implementing the sample service API as specified presents a challenge to Struts as it doesn’t cope quite so well with RESTful concepts like content-negotiation. It also restricts the HTTP methods available to GET and POST. Therefore, the author explains how to work around these issues so that you can still implement a workable RESTful API even when your framework choice is restricted to Struts.
Finally, some ideas are offered on how to create embedded RESTful web applications where the web service is bundled in such a way that it can be started without the need for extensive installations or large web application containers. Basic security and performance strategies are also discussed in order to give the reader some ideas on how requirements like these can be achieved using REST.
Conclusions.
I enjoyed this book very much and it definitely delivers on its promise. The standard of the writing is very high throughout, and the content is well thought out, accurate and coherent. As ever, Packt’s short book format works a treat and allows the reader to get a good quality high level overview of RESTful service implementation very quickly in a way that it accessible to most Java developers. I really liked the fast pace but I still felt like I had had a good introduction to the principals of RESTful applications and how they differ from other Web Services technologies like SOAP. It also helped me to better understand the role that RESTful services can play in the wider SOA marketplace.
I do have a few small criticisms. I was disappointed that no indication was given as to which framework the author prefers and why, or which frameworks are best for implementing web services that best conform to the constraints of RESTful applications. My personal conclusion would be that either of the two JAX-RS frameworks would be the best choice, but I’d have liked to have had the benefit of the author’s experience.
I was also disappointed that some features and tools that I think are important failed to get a mention in the book, even though most readers would probably have benefited from having them brought to their attention. For example, no mention was made of WADL (the Web Application Description Language), which can document RESTful services in a way that can be very useful for clients and developers. Testing tools like SoapUI were also left out in the cold even though they are particularly useful thanks to their ability to act as generic service clients and assure service quality. Jersey’s ability to automatically marshal and un-marshal XML or JSON into JAXB Java objectswould also have saved a great deal of coding effort and String concatenation had it been used in the sample.
These are fairly small gripes, and they didn’t spoil my enjoyment of the book. If you are new to REST, be sure to familiarise yourself with these tools and techniques once you have understood the basics. However, in order to get that initial understanding, RESTful Java Web Services comes highly recommended.
About the reviewer:
Ben Wilcock is a freelance SOA Architect with a reputation for delivering good quality Service Oriented Architectures. You can read his blog at http://benwilcock.wordpress.com/ or contact him via his website at http://www.benwilcock.net/“
RESTful service with HyperJaxb3 (Part 5 – CI with Mike)
I’m a big fan of CI (Continuous Integration) in the workplace but early on in my RESTful ‘Spike’ project I took the decision that I couldn’t be bothered creating a CI at home. From past experience I felt that the DIY-CI option takes up too much time and adds little value to a lone developer. What’s more, CI requires regular maintenance to remain effective.
However, as my project was coming to an end I remembered that my old colleagues at MikeCI.com have recently launched their hosted CI service that can automate Maven builds. Seeing as I was keen to avoid the hassle of CI, but appreciate the benefits it can bring – I thought I would give MikeCI a go.
Within minutes of using MikeCI, it became very apparent that it’s an astonishingly simple and very effective hosted service that can add a lot of value to any project, big or small.
Using Unfuddle as my SVN repository, within a few clicks I had MikeCI checking out my source code and completing simple builds. I needed a tiny bit of help from the guys at MikeCI.com to allow my build to access to some of the more obscure Maven repositories in my POM, but they handle these requests all the time and the service from the support team was top-notch.
Within a few hours (and very little effort on my part) I had a Maven build up and running and fully automated with a schedule.
Considering my project’s build includes starting and stopping an embedded Glassfish container and running SoapUI integration tests – I was amazed at just how easy it actually was!
Talking to the guys over at MikeCI, it sounds like the technical architecture behind the service is very cool. MikeCI uses Amazon’s EC2 elastic computing cloud to create a clean and secure virtual environment for every build, so there is no danger of them running out of infrastructure, or having multiple client’s builds interfere with each other.
If you’re looking to simplify your build infrastructure you should definitely evaluate MikeCI.com.
Glassfish’s future assured after Oracle/Sun takeover
Oracle have committed to a Glassfish roadmap that sees Glassfish gain additional features but remain free to use.
RESTful service with HyperJaxb3 (Part 4 – Architecture)
What does the basic architecture look like?
Architecture diagram
The service itself is a WAR packaged JEE6 deployable web application. The client can be anything. For the purposes of this project I used SoapUI as my client so that I could avoid messing about creating a custom UI. As I have already mentioned in other posts, the package only contains 8 or so files but delivers basic XML CRUD via a RESTful web-service.
The reason the package can be so light is because Glassfish, JavaDB, Jersey, JAXB and Eclipselink do most of the work. Deployment of the service is very fast – mere milliseconds on my PC.
