Do you know the way to SOA?

OK, the title is a little tacky, but if you’re humming a tune about San Jose California then you get the joke. In response to a posting to the U2 User’s list I decided to post some comments here about Service Oriented Architecture.

The question from Rudy Cooper was:
Does anyone have any insight into UV and SOA ? I’ve just started my research into finding out what SOA is, and whatever it is can it be used with UV. Even tho it’s all over the net, I haven’t come across anything that gives me a real world example. Is anyone currently using the technology with UV ? If so could you enlighten me ? Things like why your using that technology, how is different from the way you used to do things, etc, or if anyone knows of a link that gives a working example I’d really appreciate it.

Have a look at my articles on "Web Services and .NET".

It introduces some of the SOA concepts. It’s slightly dated in that it was written at a time when most people had no idea what Web Services were, what SOA meant, or how .NET was related to any of these things.

Here are some simple examples of SOA related to Web Services:

• Consider your internal contact list which might be kept in a MultiValue DBMS file. People use Access to list it, the web master needs current info for people on the website, trading partners need to know who to contact for various needs. You can publish a Web Service which allows specific people to get specific data they need in a format that they can use.
• What if you have a dynamic product list, list of books and other documents at a publishing company, or prices that fluctuate with the economy. You can publish a web service that internal programs and external trading partners can use, so that you don’t have a custom handler for everyone that needs the same data.
• Rather than customers calling for accounting or shipping information you can publish the data via a Web Service.

But SOA is much deeper than one-off Web Services, and linking these topics exclusively is viewed these days as being too narrow minded. These days SOA goes further to providing full applications over the internet. You can create a series of interfaces which provide very specific functions, then expose those for consumption by trading partners or by anyone who is willing to pay for your service. Look at it like a business application without the user interface. Most GUI development these days is focused on getting away from the green screen character interface, and migrating to "something else". But should you use thick client or thin? Java or .NET? PHP or Perl? Open Source or Proprietary? Microsoft-centric or open for Linux clients too? Picking any one UI technology is bound to disenfranchise someone who disagrees with your technical decisions, which is a shame because that has nothing to do with the features of your application. Rather than directly linking an app to business rules, separate them through an API. The API controls all business logic and can be exposed as yet another interface via SOA for people that want to choose their own front-end development tools – or for those who want UI-less system-to-system interfaces. Then if you want your own UI, you’re free to use whatever one or more technologies you want.

Combining these things, your application can be a aggregation of features which are made available by many other software providers. Your interface can provide data that’s generated from calls you make to other services. Your clients don’t know or care who your supplier of data or rules is. As you can see, this architecture is oriented entirely around services, hence SOA.

How can MV developers take part in this?

Exchange notes about what modules you support. Create interfaces to specific features and barter for services – no one needs to reveal their source code, but everyone does need to maintain a reliable network infrastructure. Create optional interfaces to services offered by other companies and sell those as options on your own apps.

How can MV end-users make use of SOA?

Review the policies you have for exchanging data with your trading partners, whether via fax, phone, mail, EDI, etc. Find out what data they provide which you process into results for them, and make those processes available so that they can use them remotely without asking you about it. If they’re running SAP or Oracle Financials or other packages, they might have some SOA integration that you might be interested in as well.

For larger sites with applications running on several systems, your MV system will have more value if it can integrate with other systems via SOA. Your company might want to trash the MV environment, but with 20 years of rules defined it would be hard to do so. Rather than migrating to another environment, integrate your current rules with some new system that is brought in. Your company might want a new distribution system, though you’re completely happy with your manufacturing and accounting functions. With SOA, people using a green screen can still use the existing apps plus a new distribution package without knowing that they’re working in a different system.

Summary

As you see, SOA started as Web Services but now it’s extended to providing more complete functionality over the internet. We’re starting to see entire applications produced by Google, Yahoo, Microsoft, and others, where the end-user has nothing but a GUI, no installed application, and all functions are controlled by a remote server. For those of you who recognize this as the Service Bureau of a couple decades ago, yup, what goes around comes around. But these days the client has more UI options, and even the service provider can be consuming services from somewhere else.

Nebula Research and Development can help to implement an SOA solution for your MV environment. Our products of choice include mv.NET for all communications with MV DBMS applications, and DesignBais for front-end graphical user interfaces.