ARCast.net - Someone Actually Doing SOA

Yeah, that guy can clearly talk about buzzwords - he probably invented most of them ! Seriously, I couldn't take more than few minutes of this guy.

Nothing against you Ron, I think you're doing great job running this show, but that was just something I couldn't leave without a comment.

TomS wrote:



Seriously, I couldn't take more than few minutes of this guy.

I took 31 minutes of it and think Ron did an adequate job of simplifying or digging deeper when Chris' answers sounded opaque or insubstantial. Some parts of this business involve a lot of new terminology, architecture and SOA being among them.

Hello Ron, Interesting show to say the least, it basically shows how inmature the concept of service bus and how experimental SOA applicability still is even today. By the way one of the oldest IEEE standards in electronics still in use today is the IEEE 488 standard also known as HPIB (Hewlet packard interface bus) or GPIB (General purpose Interface bus). This is a slow speed standard that allows test instruments of different brands to perform a test on a device (patient), test instruments are controled by a controller that handles the bus, and the controller communicates with a higher level language progam that actually describes the test to be performed. This standard was invented by HP many years ago, but we can draw from it many concepts about diversity of participating components, orchestration, and reasons of having a bus and a controller. Every single test instrument could be considered a web service that could serve in many different bus configurations (test), etc. I could go for ever on this topic but I just wanted to mention it to you because this standard has lasted for so long, and my guess that it is simply because it works, It has a clearly defined message handshake, interface messages, device messages, and local messages. Okay I will stop here for now Here are some comments drawn from my own experience on SOA. I have created coarse granular SOA in the pass for a travel agency: - availability services: one service per segment ((one for hotels, one for air, one for cars), - reservation services: onse service for all the segments: it handles booking, change, and cancel. Some components like the adapters to third party providers utilized during availability are also utilized here but as reutilized components and not as separate services. - Security services: handles what we call a user set, a user set can have many users in it: employees, business partners, and/or customers. One user in the user set is the principal user, a user set also has at least a target user that can be a target customer, target employee, or target partner, or a combination. A user set is very coarse granular since it contains multiple users, and a user in itself has many components: and identity component, an authorization component and a profile component. It works pretty good actually and it is very flexyble. - Data mapping services: it is a single service capable of providing dtat maping info for any adapter and also handles errors asynchronously, and data maping administration. - Credit Card Services: is a wraper service around a legacy credit card system and provides credit card functionality to any segment (hotels, air, car, etc.) - Message Logging services: allow for the centralized storage of error messages regardless of where the error physically happen - Notify now services: this one is capable of preteing up messages and sending the messages through different channels as required. - Work flow services: a service that behaves more like a visitor than an imposition in other services. - Content services - Master reference services - Pricing services - Etc. All these services are coarse in nature and they handle a set of data composed of multiple collections (tables) in other words their interface is not chaty at al, one set of data contains enough information for the consumer to have at it. and each service may handle large distributed transactions. Cordially, Luis G Gonzalez Architect Las Vegas

Thanks for the feedback guys... 

I didn't intend to keep things too vague or use buzzwords , but one thing I've found is that for SOA to work in a large company you have to get the various groups (IT, business, etc) to buy in. 

Highlighting the standard SOA benefits of agility, integration & reuse helps address the 'so what' factor, work to build support and guide our decisions.  

Technically the message I was intending to communicate is we're looking to build our SOA for business processes (not just IT utility services), and use it as a foundation for Composite Applications. 

In order to do so we've had to start understanding the business processes and then determine which activities should be created as services.  The interface or contract of these services is crucial (as everyone knows) so you need to put a lot of thought into it.

Thanks,
Chris