Michael Blechar

What’s on my mind today is the Open Service Oriented Architecture (OSOA) specification on Service Component Architecture (SCA), "Assembly Model Specification Extensions for Event Processing and Pub/Sub" and the possible confusion concerning how this relates to design and assembly of software and data services from a service-oriented applications development (SODA) perspective. They are related, but have a slightly different focus.

The SCA Assembly Model includes (1) Event Processing, which is computing that performs operations on events, including creating, reading, transforming, and deleting events or event objects/representations and (2) Publication and Subscription (often shortened to Pub/Sub), which is a particular style of organizing the components which produce and consume events in which the producing components are decoupled from the consuming components. Not surprisingly, the Gartner analysts who cover primarily cover SCA are our gurus in service component assembly from an applications integration perspective. Note: for a better historical understanding of the origins and purpose of SCA see Jess Thompson’s research note entitled “Service Component Architecture Is a Winner in the Quest to Establish a Common Notation for SOA*”.

But what of those of us concerned with the design and implementation of software and data services as part of SODA and business process management (BPM)? Are these not the same objects, services and components being referred to as part of SCA? Well, both yes and no. The design of business-oriented software and data services as part of SODA needs to be primarily driven by the business rules and process/workflows identified by the business architects and analysts. The tasks and steps of those process/workflows need to be implemented “at the right level of granularity” by application architects/analysts to address the agility, understanding, reuse and governance of those services by business analysts and developers as part of an evolving application architecture. Those well-designed software and data services in turn need to be implemented as part of a SCA in physical ways which make sense for application integration purposes including transparency, security and performance factors. This requires the application architects/analysts to work closely with both the business architects/analysts and the integration architects/analysts.

So, IMO, SCA is an important standard for those focused on application integration and assembly of physical objects, components and services.  I see a slightly different focus of design used by application architects and analysts for software and data services which are more closely related to the assembly needs of the business analysts – while also collaborating with the integration analysts to get the best physical implementations of those services using SCA types of specifications.

For more information on architecture and developer collaboration issues see my blog on “Why Architects and Developers Need To Collaborate” or my research note with Dan Sholler on “Defining the Discipline of Application Architecture*”.

*Available to Gartner clients or for a fee

Submit a Comment »

Category: Uncategorized     Tags:

Share