Recently I read Sam Newman’s “Building Microservices” , at ~280 pages its a fairly quick read. The reviews on this book overall are mixed and I can see where readers are coming from. By the title of this book one might expect some coverage of some of the microservices frameworks out there, concrete examples, maybe some actual code… but you won’t really find that here. Instead you will find a pretty good overview of various architectural approaches to modern application design in today’s world; covering general topics such a proper separation of concerns, unit-testing, continuous integration, automation, infrastructure management, service discovery, fault tolerance, high-availability and security etc.
In reality, none of the principles covered in this book are the exclusive domain of “microservice” application architectures, but rather can (and should be) applied to any application you are considering deploying; whether its a “monolithic” application or a suite of microservices interacting as parts of a larger functioning application.
In that right I think this book is definitely a good read and worth a look, if for nothing more than to ensure your team gets a refresher on good design principles and how they can be materialized with some of the newer frameworks and tool sets that have come out of our community in recent years. The material presented is sound.
Hoping this will be useful for others out there, I’ve posted some code that could to serve as a lower level component/building block in a node.js application who has a need to mediate interaction with command line programs on the back-end. (i.e. bash shells, powershell etc.)
This is node.js module for executing os commands against a pool of stateful child processes such as bash or powershell via stdout and stderr streams. It is important to note, that despite the use-case described below for this project’s origination, this node module can be used for proxying long-lived bash process (or any shell really) in addition to powershell etc. It works and has been tested on both *nix, osx and windows hosts running the latest version of node.
This project originated out of the need to execute various Powershell commands (at fairly high volume and frequency) against services within Office365/Azure bridged via a custom node.js implemented REST API; this was due to the lack of certain features in the REST GraphAPI for Azure/o365, that are available only in Powershell (and can maintain persistent connections over remote sessions)
If you have done any work with Powershell and o365, then you know that there is considerable overhead in both establishing a remote session and importing and downloading various needed cmdlets. This is an expensive operation and there is a lot of value in being able to keep this remote session open for longer periods of time rather than repeating this entire process for every single command that needs to be executed and then tearing everything down.
Simply doing an child_process.exec per command to launch an external process, run the command, and then killing the process is not really an option under such scenarios, as it is expensive and very singular in nature; no state can be maintained if need be. We also tried using edge.js with powershell and this simply would not work with o365 exchange commands and heavy session cmdlet imports (the entire node.js process would crash). Using this module gives you full un-fettered access to the externally connected child_process, with no restrictions other than what uid/gid (permissions) the spawned process is running under (which you really have to consider from security standpoint!)
The diagram below should conceptually give you an idea of what this module does: process pooling, custom init/destroy commands, process auto-invalidation configuration and command history retention etc. See here for full details: https://github.com/bitsofinfo/stateful-process-command-proxy
Obviously this module can expose you to some insecure situations depending on how you use it… you are providing a gateway to an external process via Node on your host os! (likely a shell in most use-cases). Here are some tips; ultimately its your responsibility to secure your system.
- Ensure that the node process is running as a user with very limited rights
- Make use of the uid/gid configuration appropriately to further limit the processes
- Never expose calls to this module directly, instead you should write a wrapper layer around StatefulProcessCommandProxy that protects, analyzes and sanitizes external input that can materialize in a
- All commands you pass to
executeshould be sanitized to protect from injection attacks
- Make use of the whitelist and blacklist command features of this module
- WRAP this service via additional code that sanitizes all arguments to protect from command injection
Hopefully this will help others out there who have a similar need: https://github.com/bitsofinfo/stateful-process-command-proxy
NOTE: I’ve since abandoned this avenue to generate pojos for the GraphAPI service. The Restlet Generator simply has too many issues in the resulting output (i.e. not handling package names properly, generics issues, not dealing with Edm.[types] etc). However this still may be of use to someone who wants to explore it further
Recently had to write some code to talk to the Azure AD Graph API. This is a REST based API that exchanges data via typical JSON payloads. For those having to a Java client to talk to this, a good starting point is taking a look at this sample API application to get your feet wet. However to those familiar in Java, this code is less that desirable; however it has no dependencies which is nice.
When coding something against a REST service its often nice to have a set of classes that you can marshal to/from the JSON payloads to you are interacting with. Behind the scenes it appears that this Azure Graph API is an OData app, which does present “$metadata” about itself… cool! So now we can generate some classes…..
So what can we use to generate some Java classes against this? Lets use the Restlet OData Extension. This Restlet extension can generate code off OData schema documents. You will want to follow these instructions as well for the code generation.
IMPORTANT: You will also need a fork/version of Restlet that incorporates this pull request fix for a NullPointer that you will encounter with the code generation. (The bug exists in Restlet 2.2.1)
The command I ran to generate the Java classes for all the Graph API entities was as follows (run this from WITHIN the lib/ directory in the extracted Restlet zip/tarball you downloaded). In the command below, do NOT specify “$metadata” in the Generator URI as the tool appends that automatically.
java -cp org.restlet.jar:org.restlet.ext.xml.jar:org.restlet.ext.atom.jar:org.restlet.ext.freemarker.jar:org.restlet.ext.odata.jar:org.freemarker_2.3/org.freemarker.jar org.restlet.ext.odata.Generator https://graph.windows.net/YOUR_TENANT_DOMAIN/ ~/path/to/your/target/output/dir
- If you run the command and get the error “Content is not allowed in prolog.” (which I did). There might be some extra characters that are being prepended to the starting “<edmx:Edmx” in the “$metadata” schema document that this endpoint is returning. If this is the case do the following:
- Download the source XML $metadata document to your hard-drive
- Open it up in a editor and REMOVE the “<?xml version=”1.0″ encoding=”utf-8″?>” that precedes the first “<edmx…” element
- Next, just to ensure there are no more hidden chars at the start of the document, open up a hex editor on the document to get rid of any other hidden chars that precede the first “<edmx…” element.
- Save the changes locally, and fire-up a local webserver (or a webserver that lives anywhere) and set it up so that http://yourwebserver/whatever/$metadata will serve up that XML file.
- Then proceed to alter the Restlet Generator command above to reference this modified URI as appropriate. Remember that you do NOT specify “$metadata” in the Generator URI as the tool appends that automatically.
To sum it up; Dropwizard rocks.
I’ve done quite a bit of WS development both the on client side and server side; interacting with both SOAP, REST and variants of XML/JSON RPC hybrid services. For my latest project I need to expose a set of REST services to a myriad of clients: phones, fat JS clients etc. This application also needs to talk to other nodes or “agents” that are also doing work in a distributed cloud environment. The core engine of this application really has no need for a bloated higher level MVC/gui supporting stack and bringing that into this library would just be a pain. I’ve always like the simplicity of being able to skip the whole JEE/Spring/Tomcat based container stack and just do a plain old “java -jar”… run my application…. but the reality of being able to do that has been lacking… until now.
In looking at the available options for picking the framework to use (such as Restlet, Spring-MVC REST, Spring Data REST etc and others), I immediately became discouraged when looking at examples for setting them up; they are full of complexity and lots of configuration and generally require a full application server container to run within, which just adds further complexity to your setup.
Then I stumbled across Dropwizard by the folks at Yammer. I encourage everyone reading this to just try the simple Hello World example they have on their site. If you have any experience in this space and an appreciation and vision for decoupling; you will immediately recognize the beauty of this little framework and the power it can bring to the table from a deployment standpoint. Build your core app engine back-end library as you normally would, toss in Dropwizard, expose some REST services to extend your interfaces to the outside world; throw it up on a server and “java -jar myapp server myconfig.yml” and you are ready to rock. (they make this possible by in-lining Jetty). Create a few little JS/HTML files for a fat JS client, (i’d recommend Angular) and hook into your REST services and you will have an awesome little decoupled application.
This is a review of the book Java SOA Cookbook by Eben Hewitt
Not having much experience with “SOA”, other than a horrible experience with Apache Axis years ago, I figured it would be good to pick up a book that covers the latest and greatest in this field. “Java SOA Cookbook” is quite the publication. My impression was that this book covered just about everything someone would need to be exposed to, to either get started in the SOA world, or if you are already up to your neck in it and want a good desk reference. This book appears to be it. From SAAJ to JAX-WS, BPEL, ESBs, etc etc, this covers it all. From the very high level 50,000 architecture view (i.e modeling, governance), all the way down to the minutia of various XML Schema design patterns, vendor specific HOWTOs, and details of using TCPMon to monitor SOAP traffic, this book literally appears to cover all the bases.
In the traditional Orielly cookbook model, the book takes a problem solution approach. One of my favorite “problems” presented in the book, which is quite representative of what developers face when approaching the giant world of SOA, is worded as follows, and is VERY relateable!
“You need to start developing the web services for your SOA solution, but there are so many different pieces to put in place that you are not sure where to begin. You need to determine what has to be written by hand and what doesn’t.”
No **it… I loved this book!
Weighing in at ~700 pages, after reading this book I felt like I walked away with two things. First an overwhelming impression that the world of SOA is one of enormous complexity; and secondly, as with anything, when broken down to its smallest parts, anything can be accomplished and understood. This book does just that, and I highly recommend it to anyone who wants to get a solid understanding of SOA and secondly it would likely serve as a great desk reference for anyone who works in the SOA universe on a daily basis.
Side note, this book is heavily oriented to the traditional “big web-services” world (SOAP, WSDL, JAX-WS etc), however the author does give a good treatment to REST with a full chapter on it.
Skill level: Intermediate to advanced Java developers. I think this book would be beneficial to BOTH sides of the fence in the SOA world, those with little to no experience, all the way to those who build services on a daily basis.
For those of you out there who would like to get Restlet 2.0 (currently the M5) release up integrated with your existing Spring application, hopefully this post will be of some help. I recently had to do this and unfortunately the documentation related to Spring integration on the Restlet site is scattered across various docs and some of it appears out of date. What I am describing below worked with source code straight from the Restlet SVN trunk just before the M5 release so you should be good to go if you use the M5 release (JEE edition)
First off, I am assuming you have an existing web application with a web.xml file and are using Spring. Secondly I am just trying to give you some working web.xml and the corresponding Spring configuration to get up and running. I am not explaining the details of how Restlet works as you can find that on the Restlet site.
First you will want to make sure you have the Restlet JEE 2.0 M5 edition. Make sure you grab the JEE version and not the JSE version as the latter does not include the Spring integration extension. Once downloaded extract the ZIP to a location on your drive. The JEE zip package contains a ton of Restlet Jar files. The three we care about are
org.restlet.jar, org.restlet.ext.spring.jar, org.restlet.ext.servlet.jar
If you are using Maven you can add the following repository and dependencies to your POM by using the repository instructions on the Restlet site. NOTE as of today: the Restlet repository currently does NOT have the M5 release up there so you are going to manually have to add the M5 jar to your repository by doing the following for each of the 3 jars.
mvn install:install-file -Dfile=/PATH/TO/RESTLET-m5-ZIP-EXTRACT-DIR/lib/org.restlet.jar -DgroupId=org.restlet -DartifactId=org.restlet -Dversion=2.0-SNAPSHOT-M5 -Dpackaging=jar
mvn install:install-file -Dfile=/PATH/TO/RESTLET-m5-ZIP-EXTRACT-DIR/lib/org.restlet.ext.spring.jar -DgroupId=org.restlet -DartifactId=org.restlet.ext.spring -Dversion=2.0-SNAPSHOT-M5 -Dpackaging=jar
mvn install:install-file -Dfile=/PATH/TO/RESTLET-m5-ZIP-EXTRACT-DIR/lib/org.restlet.ext.servlet.jar -DgroupId=org.restlet -DartifactId=org.restlet.ext.servlet -Dversion=2.0-SNAPSHOT-M5 -Dpackaging=jar
The above 3 commands will manually install the three Jars into your Maven repository. Next you can configure your POM to add the official Maven repository plus the dependencies to the 3 Jars you installed above. Note that the repository entry is sort of meaningless at this point because you manually installed the jars above. It is IMPORTANT that the
elements in your dependencies below MATCH exactly the versions you specified in the commands above!
<repository> <id>maven-restlet</id> <name>Public online Restlet repository</name> <url>http://maven.restlet.org</url> </repository> <dependency> <groupId>org.restlet</groupId> <artifactId>org.restlet</artifactId> <version>2.0-SNAPSHOT-M5</version> </dependency> <dependency> <groupId>org.restlet</groupId> <artifactId>org.restlet.ext.spring</artifactId> <version>2.0-SNAPSHOT-M5</version> </dependency> <dependency> <groupId>org.restlet</groupId> <artifactId>org.restlet.ext.servlet</artifactId> <version>2.0-SNAPSHOT-M5</version> </dependency>
Ok, great. Next we need to configure your
web.xml, open it up and add the following entries in the appropriate spots:
<servlet> <servlet-name>myRESTApi</servlet-name> <servlet-class>org.restlet.ext.spring.SpringServerServlet</servlet-class> <init-param> <param-name>org.restlet.component</param-name> <!-- this value must match the bean id of the Restlet component you will configure in Spring (below) --> <param-value>restletComponent</param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>myRESTApi</servlet-name> <url-pattern>/my/REST/api/*</url-pattern> </servlet-mapping>
Now your web.xml is configured to take all requests to
/my/REST/api/* and send those to a Restlet Component which you will wire up in your Spring configuration. So... bring up your applicationContext.xml or whatever you have it named and add the following entries:
<!-- our SpringComponent which binds us to the Restlet servlet configured above --> <bean id="restletComponent" class="org.restlet.ext.spring.SpringComponent"> <!-- the defaultTarget for this component is our Restlet Application --> <property name="defaultTarget" ref="myRestletApplication" /> </bean> <!-- your Restlet application. This class extends "org.restlet.Application" --> <bean id="myRestletApplication" class="my.restlet.MyRestletApplication"> <!-- all requests to this Application will be sent to myPath2BeanRouter --> <property name="root" ref="myPath2BeanRouter"/> </bean> <!-- This router automagically routes requests to beans that extend org.restlet.resource.ServerResource or org.restlet.Restlet who's name starts with a "/" slash which matches the request--> <bean name="myPath2BeanRouter" class="org.restlet.ext.spring.SpringBeanRouter"/> <!-- This extension of org.restlet.resource.ServerResource bean will handle all requests to made to /my/REST/api/myResource (GET/POST/PUT etc) This class extends "org.restlet.Restlet" or "org.restlet.resource.ServerResource" --> <bean name="/myResource" autowire="byName" scope="prototype" class="my.restlet.package.resources.MyResourceBean"> <property name="somePropertyOfMine" ref="someOtherSpringBean"/> </bean>
Ok, well if you were having trouble trying to get Spring working with Restlet I hope this helped get you rolling. Restlet is a cool project that works great and can get a REST API up and running pretty quickly (granted you are good at crawling through somewhat scattered documentation) Here are a few other links which you may want to reference:
Also, I am posting the following error messages that troubled me when trying to get this to work. The configuration I show above was the result of getting beyond the below errors by using the correct fixed releases. To AVOID the errors below, ENSURE you are using Restlet 2.0 M5 or a custom build from the trunk. Prior to 9/25/09 people were getting the errors below.
No target class was defined for this finder
Complete Message org.restlet.ext.spring.SpringFinder $$ EnhancerByCGLIB
This is a book review for “RESTful Web Services” by Leonard Richardson and Sam Ruby
If you want to get under the hood and really understand how to properly implement a RESTful web service then this book is for you. The treatment of the topic is excellent. After reading this book, I feel that so many folks out there writing “REST” apis, myself included, have written variants of a REST-RPC hybrid, versus a true REST implementation. REST after all in its true form is really a total change of mindset when it comes to creating a web-service and this book helps you get there. The author does not turn this into a REST vs. SOAP discussion but rather preps the reader quite well by exploring the history of web-services and very clearly explaining the differences between all the different approaches, and positives/negatives of each (RPC, REST-RPC, SOAP, WS-*, etc) Secondly the author give a primer on the basic tools used to implement REST clients in various languages by covering the various popular HTTP client libs out there (cURL, Apache HttpClient, rest-open-uri, libcurl etc). The author also presents a discussion and explanation of “Resource Oriented Architecture” and walks the reader through several example implementations (both Read-only and read-write) as well as the RESTful thought process behind the design. The author gives excellent treatment to the differences between when to use a PUT vs. POST and explains the rules around making that decision, which, can be difficult to understand which to use in the real world. The book also shows various ways of implementing a REST service when some of the HTTP methods simply are not available (primarily PUT/DELETE) due to your HTTP server setup. Lastly the book covers some server-side frameworks that are available and the one I found the most interesting, which I hope to work with soon, is the Java project called Restlet.
Readers will also find the HTTP status code and headers reference very valuable, as for each status code/header, the author gives very clear descriptions of their meaning in a RESTful web-service. Very valuable!
Recommeded? Yes, go get it today.
Skills: Java/Ruby/Python – intermediate to advanced.