Easy Web Service And Test in 5 Minutes

This post will show how to quickly make a web service and test it in less than 5 minutes.

Tools you will need:

NetBeans 6.8 (choose to install GlassFish with the IDE)
SOAPUI 3.5


First, make your NetBeans project. Make it a Web App.



Choose defaults for the deployment options:






Right-click the source package and choose to add a new Web Service:



Give the Web Service a name. My examples often deal with the game of bowling.....



Put the cursor in the body of the Web Service class and right click. Choose to 'Insert new code', make it a Web Service, and add the method signature you want.







Add some logic for your method. When you're done, right-click the Application in the Applications tab and choose 'Clean and Build', then 'Deploy' (after you've cleaned up any compile errors, if there are any.)



Now choose the 'Services' tab. You need to go get the WSDL for your Web Service so you can test it....



Choose 'View Endpoint'....



Click the link for your WSDL, and copy it into your clipboard. You'll be using it in a few seconds....




Now to test the Web Service! Fire up SOAPUI, and start a new Project. Paste your WSDL URL (from the address you got after clicking the 'view WSDL' link a bit above).




Now alter the sample SOAP message SOAPUI has kindly provided you. In my screenshots, I'll check to see if a nine count makes a strike. (It does not, of course.)





That's it! A couple of very important points:

This is a 'Bottom-up' Web Service. (One where you start with code, not start from WSDL). These are easy to develop, but may not fit well in your 'Production' environment.

There are other ways to test your Web Service, including facilities within NetBeans itself. I wanted to use SOAPUI, though, because it's a great tool that's very versatile.

Happy Coding!

SOA Best Practice: Start with the schemas

We've been doing some deep-dive evaluations on SOA tool suites at work, so I've had some recent exposure to a variety of toolsets. We've been investigating both proprietary and open source suites and components, so I've been able to work with a variety of SOA IDEs.

One thing I've noticed: In many cases, your life is much easier if you start with your schemas that represent the messages being shuffled from component to component.

A short while back, this would've caused me a little distress. I've had bad feelings about XML, based on memories of pain filled hours spent hand-editing XML files. Namespaces, the order things have to appear in XML files (Mule 1.4 config, anyone?), and others tripped me up time and again. I imagine this is common, else bottom-up web service development wouldn't be so popular.

Well, I'm pleased to announce that XML tooling has matured to the point where I found myself not dreading working in a top-down (XML schema first) manner. I've recently worked with both proprietary and open source tools that effectively hid the underlying complexity of the XML from me.

Most of the tools have nifty 'Design View' panels that let you visualize (drag and drop) the XML document you want to write. They'll have property tabs that allow you to add the syntactic elements, and a way to change views to see the underlying XML document if you want to. After a short while, I started really liking this way of working with XML.

So back to the SOA storyline-- because of these nifty visual editors, I found it totally natural to work in a top-down (contract first) manner. The SOA toolkits liked this much better, as they are able to provide meaningful dialogues that let me choose which data bits should be marshalled, transformed, whatever. I got to see the other side of the coin, too. Most of the tools let you design in a schema-less way (dragging components onto a BPEL canvas without specifying the schema, for example), but these efforts turned out to be much more difficult than starting with the schemas. (Or so it seems to me.)

So I'd have to call this one a triumph for technology. What used to be hard is now easier, and it leads to one of my personal best practices for SOA: Start with the schemas.

Coming Soon: Review of 'OpenX' Ad Server book

I'm anticipating reviewing Packt Publishing's soon to be published "OpenX Ad Server: Beginner's Guide".

The book's description (found here) promises to instruct any reader with an understanding of IT basics on how to use OpenX. OpenX is an "Ad Server", or a platform to help you run advertising campaigns. It's supposed to help you display ads, find which ads are most effective, utilize GeoTargeting, provide metrics to help you judge your effectiveness, and more.

I have to be honest, this appeals to me. I use Google Analytics to track readership of this blog and I've become addicted to the statistics it provides. If I had a similar package that would help me serve a few relevant ads, track reader interest in these ads and maybe even make a few bucks in the process somehow, that would be really cool!

The book is slated for print soon, watch these pages for a review.

'Till then,

Happy Coding!

A shortcut from Junior Programmer -> Journeyman

Programmers generally have 2 transitions they can go through in their career lifespan:
-From Junior Programmer to Journeyman
-From Journeyman to Heavy Hitter

Some programmers don't make the transition to Journeyman. Mostly these are folks that just aren't suited to the profession for one reason or another and quit within the first 3 years or so. Very rarely, you'll find a 10 year Junior Programmer, but these are a rare breed.

Most programmers stay at the Journeyman level for the duration of their career. There's nothing bad about this-- these folks make up the bulk of the workforce and get most of the work done. These are people who prioritize their life in such a way that they spend a 'fair' amount of time on their career, but don't go out of their way to constantly study IT in the off-time. These are the people everybody depends on to carry out their orders and keep things moving.

A small percentage of programmers make it to the 'Heavy Hitter' level. Every organization has them-- the folks who set new directions and establish development processes. These guys can't afford to stagnate (because they are relied upon to bring new ideas) so they're always studying.

This column deals with that first transition. If you're a Junior programmer today and are looking for a way to make it to the next level, read on.

I know of a technique that can be used to accelerate the first phase and move you to the second one as quickly as possible. This is important for two reasons:
- It brings more responsible assignments (and with them more pay and geeky prestige)
- It starts your 'time in grade' in the Journeyman level, which is a necessary prerequisite towards advancing to the 'Heavy Hitter' level, if that's your ambition

To use this shortcut, you'll require 3 things:
- A solid, working plan of self-improvement
- A reliable pipeline of work assignments, at least 4 or 5 months worth
- A viable alternative place of work that is hiring

1) A solid working plan of self-improvement
You need to conduct yourself in such a way that your boss realises you are on the way to more responsible work assignments. Back when I was a junior programmer (in the stone ages), this meant reading IBM manuals and workshop binders, and taking home thick mainframe greenbar compile listings. Today, this means studying things on the web and on your home computer, and studying your company's business artefacts in your off time. If you aren't willing to part with the time to devote to these activities, stop reading now because this shortcut won't work for you.

2) A reliable pipeline of work assignments
You need to have a steady stream of assignments in your near future, tasks you know your boss is going to assign to you. Some of these will be things that you are best suited for based on your skill sets. Some can be tasks you volunteer for because nobody else wants to do them. Either way, you want to position things so that your boss considers you the go-to person for a bunch of work that's slated to happen in the near future.

3) A viable alternative place of work that's hiring
Of the 3 requirements, this is the only one that requires something other than disciplined hard work. What it does require is a little research and a healthy dose of 'guts'. You need to look inside your company and out for a job posting that's for a programming job at the Journeyman level. They aren't hard to find-- if it's not paying at the guru pay scale and if it doesn't say 'Junior Programmer', then that's your target. Make sure it's someplace you actually would consider working for and make sure you're reasonably qualified for the posting (albeit at the low end).

The Plan:
After making absolutely certain you have your 3 requirements met, make an appointment to talk to your boss. In your conversation, say something like this:
"I've been working hard on advancing my career, and I think I'm ready for more responsible tasks. I really like what I'm doing here, and think I'm making a difference, but I'm tempted to look into this position I see at (name your third Requirement). Can you help me get promoted here so I can advance my career, but still stay here?

If your boss acts like mine did, he will immediately adapt a defensive position in which he hurriedly explains why you can't just ask for a promotion and it's not your time yet. This is fine-- his job is to keep expenses low and to maintain stability in personnel matters. What he really needs is a little time to think things over, because you really are bringing him a good business proposal. Your response should be something like "Well, I'll keep working and learning, but please give it a little thought. How about if we follow up in a week?"

That should give your boss plenty of time to really consider things. If you've done a good job with your prerequisites, your boss should be thinking thoughts like these:
- If I don't keep (insert your name here), I have to train somebody else to do all this stuff. It'll take forever to get a Junior programmer to that level again.
- (Your name) has already been taking on some mid-level assignments. It's a little early, but that promotion will come soon anyway.
- Crap! Where am I going to get someone to handle that stream of work I've got lined up for the next 4 months?
- (Your name) is being a little ambitious here, but I respect that he wants to advance his career.

Then in your follow-up, there are a few things that might result:
- You get the promotion. In that case, congratulate yourself and send me a nice thank you note.
- You are told you're still a little green, but you can work on your development plan and perhaps get your promotion soon. If this happens, BE SURE TO ASK ABOUT TIMELINES. It's up to you to decide how much emphasis to put on the 'viable alternative place to work' at this point. (Do NOT over-emphasize this, as your position really isn't that strong. The purpose of that requirement was to lend a matter of urgency for your request-- the "Why now?" factor). NO MATTER WHAT, YOUR CAREER IS YOUR RESPONSIBILITY, SO SECURE SOME COMMITMENT TO A TIMEFRAME FOR YOUR ADVANCEMENT. Think of it as a project deliverable-- you need to establish a timeline.
- You are flatly denied. In this case, you will have been given some valuable feedback in some form or other-- think about what it means.

Remember, your boss is a business manager, and as such is going to respect the business aspects of your proposal. If you've been diplomatic (and not a ham-handed extortionist) you should not have angered your boss. If anything, your boss will have a newfound respect for your professionalism. (And if not, again-- you have some valuable feedback.) To get to be your boss, this person has had to have gone through a few promotions, too. They know what it's like to want to move ahead.

This plan worked for me 18 years ago. If you choose to try it, I hope it works for you, too. Good luck, and Happy Coding!

"PHP 5 e-commerce" by Packt

I've just finished reading "PHP 5 e-commerce" published by Packt Publishing and wanted to provide a review.



Make no mistake about it, this book is all about writing an e-commerce web site and little about teaching the reader PHP 5. That's ok for us hard-core developers, though, as the included PHP is so clean and so simple it won't be a problem for PHP novices.

The core of the book is about writing a web site to sell things. Early on the author introduces the handful of patterns that will be used (MVC, Registry, Singleton) then immediately provides a runnable skeleton MVC framework that handles only Products and Categories. After that, it's an incremental build chapter by chapter as the author adds features to the web site.

Without question, one of the book's strong suits is the author's knowledge of e-commerce features. The book covers all the features you're going to want (Search, Payment, Discounts and Vouchers, Recommendations, User Reviews, etc. etc.). Each of these is given adequate coverage and a clear implementation, chapter by chapter. The book ends with some tiny chapters on odds and ends like password recovery, calling out to other commerce sites, etc.

If you're looking for a PHP book, this isn't the title you want. There's simply nothing here (besides plenty of good, well commented source code) to teach you the language. But if you're looking to learn how to write an MVC application, there is value here.

I'd recommend this book to anyone that's building an e-commerce site. The author's care in enumerating the many features you'll want is valuable advice you can leverage.

PHP 5 e-commerce can be found here.

SOA's beginning to feel a lot like CORBA

If you ever visit my garage, you'll find a couple of book shelves out there. On the shelves are an array of computer books, on all sorts of topics. I'll sometimes buy books at garage sales, at the GoodWill store, or especially off Amazon from the 'used' section. Most of the books I buy are cheap-- I'll buy 2 or 3 books off Amazon for a few bucks each plus shipping. I like books better than online reading because I can mark them up and take them with me wherever I go. (Sorry, a Kindle just doesn't seem the same. I ease my conscience by telling myself I'm buying used, so I'm not really causing any new trees to be felled.) A few of the books I've bought this way are terrible, but most have at least a few good chapters and a couple have been really good. I'm able to get more perspectives on a topic by buying in quantity rather than spending more money for quality. (By the way, I keep a few books inside the house-- any 'high dollar' new books, or any books that have my name inside them for some reason. By keeping only a subset of my books inside the house, I've found my married life is much happier!) Among my 'outside' books you'll find a couple of volumes on CORBA.

We still use CORBA in places where I work. Mostly we make use of the 'Naming Service' and the data-marshalling capabilities (which we find to be very performant, BTW). The 'Naming Service' is a sort of registry for CORBA services. When my service comes up, it uses a well-known (that is, hard-coded and shared by other services) address to reach out to the Naming Service. My service then registers itself with the Naming Service by supplying a name for itself and the address of the machine it's running on. (So my service might pick the name /Persistence/Sharding/ShardLocator.) Then whenever a client wants to use my ShardLocator service, it uses the same well-known address to get to the Naming Service, and it asks it where it can find /Persistence/Sharding/ShardLocator. The Naming Service will pick either my service or another machine that hosts this service and tells the client that's where the service can be found. When my service shuts down, it is obligated to un-register with the Naming Service so the registry in theory contains only 'live' service instances. (Note to newbies: This is done so clients don't have to hard-code the location of servers they need to talk to. Then when a machine fails or you add a new server instance, it's easier.)

If I look through one of my ancient CORBA books, I see great tales of what CORBA should be used for. There are distributed transactions, mechanisms for dynamically finding and invoking methods, a query mechanism, etc. etc. But as I said, we make use of only a few simple services. I think this is common-- I bet most people that still use CORBA only use a few parts of the whole spec.

Lately, I've been working on a team charged with architecting a sizeable new greenfield application. We're considering different SOA components to use-- an ESB, an orchestration engine, maybe some other parts. If you look at SOA suites offered by big vendors, you'll see quite a laundry list of components-- Governance helpers, Business Rules Engines, Complex event processing, etc. (By the way, the open source guys offer these too.) But I'm not sure we'll be using all that stuff, probably just the parts we really need. The whole thing is beginning to feel vaguely like CORBA.

CORBA and SOA are also similar in that they were largely spec-driven efforts that tried to answer all the problems the industry was trying to solve. I think it's widely accepted that the reason they didn't realise full potential was that the specs grew too complicated (WS-* anyone?) and the vendor implementations didn't really interoperate.

It's been over a year now since a prominent industry analyst proclaimed "SOA is Dead". (Google that one, you'll find plenty.) So it looks to me like SOA has roughly followed the same lifecycle CORBA did:

CORBA was lively from roughly 1990 - 2000
SOA was lively from roughly 2000 - 2010

Cloud, to me, is a lot like SOA re-packaged with some machine requisition thrown in.

I'm left pondering a few questions:
- How will we look back at SOA a few years from now?
- Will we have another tech stack arise for the next decade? What will it be?

Thanks for reading, and Happy Coding!