Exposing Enterprise Data - web services or SOAP?

DublinWriter · 22-07-2012 06:45PM #1

I have a client with a bespoke enterprise HRMS running on Oracle.

They want to expose basic HRM information to other systems in the organisation, basically other systems provide an employee ID and the HRM system supplies surname, firstname, location code, etc.

I know a view is a good way to do this, however I want to keep things as DBMS-independant as possible as the main HRMS uses Oracle and they have numerous MS SQL Server systems around the place.

I was thinking of recommending web services. Is this too M$ specific? Should I perhaps look at something along the lines of SOAP?

Colonel Panic · 22-07-2012 07:10PM

DublinWriter wrote: »

I have a client with a bespoke enterprise HRMS running on Oracle.

They want to expose basic HRM information to other systems in the organisation, basically other systems provide an employee ID and the HRM system supplies surname, firstname, location code, etc.

I know a view is a good way to do this, however I want to keep things as DBMS-independant as possible as the main HRMS uses Oracle and they have numerous MS SQL Server systems around the place.

I was thinking of recommending web services. Is this too M$ specific? Should I perhaps look at something along the lines of SOAP?

A REST api that spits out JSON makes most sense these days.

kayos · 23-07-2012 12:18PM

Web services are not m$ specific so don't worry about that. I am liking odata services but they are more m$ but have good support. They could be exactly what you want here. Long story short they are rest services but having some nice features e.g. query syntax for in the URI as part or the query string. PowerPivot also supports odata service feeds which might give you a nice feature for users.

But a straight forward set of rest services will do what you want with out issue.

Colonel Panic · 23-07-2012 02:15PM

Just as an aside, referring to Microsoft as M$ is pretty damned juvenile.

Giblet · 23-07-2012 03:52PM

Colonel Panic wrote: »

A REST api that spits out JSON makes most sense these days.

You would need something like WSDL2.0 or WADL especially if the consumer wants to generate code from it.

mwrf · 23-07-2012 08:31PM

Build RESTful web services. Simple.

For oracle, the apex listener makes it trivial to expose data.
Read here:

http://www.oracle.com/technetwork/developer-tools/apex-listener/documentation/apexlistenerdevguide1-1ea-177511.pdf

Boskowski · 24-07-2012 10:28PM

Stupid question but isn't SOAP and web services the same thing essentially?

stephenlane80 · 27-07-2012 10:13AM

SOAP is an XML message format, its used almost exclusively as the message format for Web Services, WSDL is the web service description that describes the message formats and how to invoke the web service

kyote00 · 27-07-2012 08:58PM

To be honest, this is a five minute activity using REST and JPU

Have a look at Netbeans (or eclipse), the IDE writes most of the code for you.

If you want to make the data play well into future, use JSON-LD

Boskowski · 28-07-2012 10:59PM

stephenlane80 wrote: »

SOAP is an XML message format, its used almost exclusively as the message format for Web Services, WSDL is the web service description that describes the message formats and how to invoke the web service

Simple Object Access Protocol

It's describing how objects make available data & functions (services) to remote clients. If I was going to be pedantic precise I would say SOAP is the protocol that realizes web services. For the purpose of this discussion I'd say the two are the same thing.

The Corinthian · 29-07-2012 08:37AM

Boskowski wrote: »

For the purpose of this discussion I'd say the two are the same thing.

Pretty much. Web Services, in many respects, is a term that is overused in much the same way as 'The Cloud' is; ultimately it's just an API for accessing data and services remotely between you and another party using an agreed protocol. When the term 'Web Service' first became popular, about twelve years ago, it was very much about being able to charge more per hour to develop it.

My own opinion is to develop your solution in such a way that you may easily add different ways to expose your data in the future, as the popularity of some 'Web Services' changes over time - new ones appear, one's that are presently not popular become so and one's that are presently popular become dinosaurs.

Writing your own custom one can also make sense as there's a lot of superfluous specifications in many of these protocols that simply serve to confuse people and add unnecessary load and complexity on both ends of the transaction.

I found in the past that you need to be flexible if you are opening up to third parties. Some have good technical resources and if you say to them WSDL, for example, they'll have no problem. Others will prefer something like REST. Others again will have some pigs ear of a legacy system at their end and request that they can FTP a CSV from you.

So I would do is pick up the phone and conduct a quick survey of your (potential) clients and ask them what they would prefer.

stephenlane80 · 31-07-2012 05:43PM

Boskowski wrote: »

Simple Object Access Protocol

It's describing how objects make available data & functions (services) to remote clients. ...

No its not, its an XML based format for exchanging messages, wsdl describes the functions and their associated types.

stephenlane80 · 31-07-2012 05:55PM

The Corinthian wrote: »

Pretty much. Web Services, in many respects, is a term that is overused in much the same way as 'The Cloud' is; ultimately it's just an API for accessing data and services remotely between you and another party using an agreed protocol.

'Web Services' as it is commonly used refers to the HTTP/SOAP/WDSL stack.

I'm not sure which other 'Web Services' you referring to, CORBA, REST, RMI etc.. there not called 'Web Services', sometimes REST services are called REST webservices but thats about it. These are all SOA enabling technologies but not web services, 'Web Services' specifically describes the HTTP/SOAP/WDSL stack with all their associated WS-* specifications such as WS-addressing, WS-discovery.....

Sorry, but it was just a bit misleading for the OP!

solarith · 01-08-2012 08:17AM

Out of curiosity, is there something wrong with:

- Sending request to PHP script
- PHP scripts are tailored to retrieval of specific information from SQL db, and return as XML
- Scanning the XML for results?

I'm not trying to hijack a thread - but this is what I've done for myself, it took about 10 minutes to set up and is it a no no, seeing as no one has mentioned it?

stephenlane80 · 01-08-2012 09:38AM

solarith wrote: »

Out of curiosity, is there something wrong with:

- Sending request to PHP script
- PHP scripts are tailored to retrieval of specific information from SQL db, and return as XML
- Scanning the XML for results?

I'm not trying to hijack a thread - but this is what I've done for myself, it took about 10 minutes to set up and is it a no no, seeing as no one has mentioned it?

Sounds like a RESTful service with XML messages, I would say that pattern is quite common/effective

The Corinthian · 01-08-2012 11:47AM

stephenlane80 wrote: »

'Web Services' as it is commonly used refers to the HTTP/SOAP/WDSL stack.

I'm not sure which other 'Web Services' you referring to, CORBA, REST, RMI etc.. there not called 'Web Services', sometimes REST services are called REST webservices but thats about it. These are all SOA enabling technologies but not web services, 'Web Services' specifically describes the HTTP/SOAP/WDSL stack with all their associated WS-* specifications such as WS-addressing, WS-discovery.....

Sorry, but it was just a bit misleading for the OP!

That was kind of my point, although perhaps I didn't explain myself clearly enough.

'Web Services' became a buzzword, much like the 'Cloud' is today, around 2000; building up from the hype that arose from XML a year or two earlier. That it has become an oft misused term, and that we can end up bogged down in arguments about the definitions of the terms used is in many respects a demonstration of this - especially, when you come down to it, it's not really that complicated an idea; or at least should not be.

All it is, is being able to access data and/or services on a remote server using an agreed protocol. This was already around long before, but tended to be developed on a case-by-case basis, often using other formats to wrap data, such as CSV.

I remember my boss wanting me to recode everything to output XML back in 1999, which made little sense to me and in the end did make little sense because it bloated the data and all of our customers were happy with what they already had and didn't really have the resources to recode at their end. But that was the hype at the time.

Then in 2002, I put together a Web Service for one of our products. No one used it as our market simply didn't have the resources in-house to integrate at their end. As such, we ended up writing much lighter, custom 'Web Services' (note the apostrophes) for them.

Ultimately, whatever way you do it has to make sense from a business perspective. This means it depends upon who you're doing business with, because they're the one's who are going to have to integrate it at their end. With large enterprise organizations, this should not be an issue much of the time, but even then, you'd be surprised how often it can be or they can simply prefer something simpler, which does not have the same overheads as a real Web Service. That can often be the difference between getting the business versus having beautiful, compliant code - and a bankrupt company.

So my advice to the OP is to survey his/her clients first and see what they ideally want. That's the bottom line, not if it's a 'Web Service' or a Web Service.

Exposing Enterprise Data - web services or SOAP?

Comments