Applying SOA

G

guest2013-1

guest
Joined
Aug 22, 2003
Messages
19,800
Reaction score
13
So I'm pushing for a more SOA-based integration/component thing. And I've been asked the question:

How do you apply something like "pad this number with 0's to fill 20 characters" across multiple systems and still have 1 place you maintain it, as in a SOA architecture?

We run SQL Server DB's for all our systems, have 4 main systems that require this function etc.

How would you approach this? Should it be on the database level? The Client UI level? How do you maintain 1 object for this SOA "layer"?
 
I would not recommend using SOA at such a fine grained level. In my experience SOA works best if you have "chunky" services. You could consider a shared DLL for shared library functions like the one you mentioned, but doing that via SOA type remote calls would be a bad idea in my opinion.
 
SOA is not as simple as it sounds... You need a lot of governance and diligence around it. Unforeseen effects of changes on systems you didn't even KNOW we're subscribing to your services etc...
 
The reason why the padding of the numbers thing came up was that 1 of the systems we do have doesnt use it, so from a reporting perspective (since all the systems carries some related data), it makes it more difficult.

However, now that I think about it, that should actually be rectified on the ETL process for the data warehouse. Mmmm, I should start pushing hard for reporting ONLY off of the DW instead of direct pulls from all the systems
 
AcidRaZor said:
The reason why the padding of the numbers thing came up was that 1 of the systems we do have doesnt use it, so from a reporting perspective (since all the systems carries some related data), it makes it more difficult.

However, now that I think about it, that should actually be rectified on the ETL process for the data warehouse. Mmmm, I should start pushing hard for reporting ONLY off of the DW instead of direct pulls from all the systems
Click to expand...

Good luck with that, in all sincerity...
 
You would need to approach it like any other project. Start by defining the principles that would guide your decisions. One of the foundational steps would then be to ascertain the maturity of the system and whether is lends itself to SOA to begin with.

In some cases, the re-use of such fine-grained services makes sense, in others it leads to problems. Generally, the most benefit will come from re-using business-oriented services. But even so, you will hit a ceiling in terms of utility very quickly. A mediation layer will assist in later maturity levels, but way before that, governance will be a limiting factor.

SOA is one of those things that sounds so great in theory and on paper seems easy to implement. But it is not for the faint hearted.
 
AcidRaZor said:
So I'm pushing for a more SOA-based integration/component thing. And I've been asked the question:

How do you apply something like "pad this number with 0's to fill 20 characters" across multiple systems and still have 1 place you maintain it, as in a SOA architecture?

We run SQL Server DB's for all our systems, have 4 main systems that require this function etc.

How would you approach this? Should it be on the database level? The Client UI level? How do you maintain 1 object for this SOA "layer"?
Click to expand...

Honestly AcidRaZor, you need to understand what SOA really is, before asking these questions.
 
In the perfect world you would have a number of layers in your SOA architecture. A data-abstraction layer would make sure that the data is presented consistently across the consuming services irrespective from where the raw data originates. Sadly most "enterprise architects" equate SOA to writing a bunch of webservices or dropping messages onto queues to be consumed by an ESB.

In a purist SOA implementation it is really irrelevant if data comes from DW or transactional databases - the data layer would take care of it. If your main systems access your data-layer directly via SQL you are not doing SOA.
 
jeanres said:
Honestly AcidRaZor, you need to understand what SOA really is, before asking these questions.
Click to expand...

So SOA is NOT a collection of "services" (or modules if you will) that is re-usable and provides functionality to multiple systems so that, if there's a business change (to, for example, the padding of 0's to make 20 characters), that it would automatically propagate to all other systems using this module??

****, sorry dude. So what is SOA then?

MagicDude4Eva said:
In the perfect world you would have a number of layers in your SOA architecture. A data-abstraction layer would make sure that the data is presented consistently across the consuming services irrespective from where the raw data originates. Sadly most "enterprise architects" equate SOA to writing a bunch of webservices or dropping messages onto queues to be consumed by an ESB.

In a purist SOA implementation it is really irrelevant if data comes from DW or transactional databases - the data layer would take care of it. If your main systems access your data-layer directly via SQL you are not doing SOA.
Click to expand...

We're talking multiple systems here, not just one system. And I was pointing towards the idea that the DW would be the data-layer, since it's only important for reporting purposes, because 12345 is different to 00012345 when it comes to a join on those fields. We currently have 4 major systems, each tracking and monitoring 00012345 on it's own. All of which are written by 3rd party developers or in-house ones. So we do get that system 1 doesn't do 00012345 but system 2,3 and 4 does.

If there are anymore suggestions as to how padding a number with 0's (it may sound simplistic, but it's the primary thing we think of, especially when it comes to reporting), *where* would it live so that if dumbass-1 comes in with a new project, we force him to use XYZ to enforce standards. Because he will have his own database that would be an extension to whatever the **** it would be tracking.

I know that if any system accesses another system directly with SQL by-passing the data-layer, that it's not SOA. DUHR. I want to know in terms of a business-logic-layer (or module or collection or whatever you want to call it since I apparently don't know what SOA is), how can we enforce a simple ****ing function that pad's 0's infront of a 20 character number?

Do we do it on the column so that SQL Server does it (minding that we need to then change 5+ databases if we do decide to change, which IMO isn't SOA)
Do we have a UDF on a "SOA" database to do that, which we then force the dev's to use in writing stored procedures that communicates with their own DB's to use?


etc

Was looking for suggestions on how to approach this, not be told that I don't know what SOA is.

If you feel you'd like to "school" me, how about including your opinion on what it is?


And to end: **** you jeanres
 
I think it boils down to making a few principle decisions - like what that data-entity with the padded zeros is and how it is stored. Perhaps it is necessary to do a data-cleanup project first and not use SOA to hide what looks like a legacy mess from different developers. Perhaps as a start system1 and it's database need to change the way it stores the information (migration scripts and db triggers will sort this out if you need to shortcut it). Without putting a few principles down, you will have a hard time with discipline in the business. DWs are great but before you know it, there is a danger that your DW becomes a transactional DB.

For efficiency and performance you might need to make the principle decision that each application persists data in a certain way, duplicating formatting rules if need be.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X