What on Earth is SCA?

Links to thoughts on SCA

Service Component Architecture (SCA) is not the sexiest sounding standard out there but it will be an important part of the next release of Oracle SOA Suite, providing a framework for describing the inter-relationships between components.  I thought that Edwin K did a great job of positioning it in a recent blog entry - it takes SCA out of the ethereal and plants it firmly in the real world.  I like to think of SCA as a wiring diagram for SOA components - Dave Chappell (Oracle) added his own thoughts in this blog entry.

The Laundry Model for SOA

A common analogy for SOA is to describe it as lego blocks.  At one level that works reasonably well, but the same analogy holds for object orientation or structured programming, so there must be something more.  The CBDI site suggested the analogy of laundry, and I have to confess I really like this model and have used it with several customers as well as internal people here at Oracle.  Let me expand on the laundry model.

SOA is about Services

It might seem obvious but service orientation is about changing your thinking (orienting yourself) to think about IT systems as a collection of well defined collaborating components (services).  A service has some sort of contract implying that the consumer of the service will provide X and in return will get Y.  A laundry is a great example of this.  A laundry defines an interface, I prefer to think of it as a basket, that says you give me a basket of dirty laundry and some money and I will give you a basket of clean laundry.

The Service Interface

The basket interface, defines that laundry is passed in a basket or a bag, and has various options (lets call them parameters) that allow the client to specify if they want stain removal on particular items, or if they want their laundry starched, or repaired or any of a number of different options.  Note that these parameters specify what is to be delivered, not how it is to be done.  In SOA we may use WSDL and XSDs to define the interfaces.

Composite Services

Our laundry service provider may decide to sub-contract part of the work to other companies, for example sending velvet clothing to a specialist velvet cleaning service that employs gnomes to pick out the dirt from the fabric.  This use of other services makes our laundry a composite service, because it is built out of other services.  The client of the laundry service is unable to tell that the service provider uses other services, hence there is no difference between composite services and atomic services.  Often BPEL will be used to create composite services from existing services.

Virtualising the Service Interface

We may want to change our laundry provider, and as long as they provide the same service we don't really care who does it.  We may change the provider based on cost, or service level.  In any case we don't want to have to change the way we work with the laundry service just because it is a different provider.  Many companies provide their employees with a laundry drop off service.  The employee (client of the service) does not care who actually provides the service, he just drops off his dirty washing at the drop-off point and picks up the clean washing later.  This virtualisation of the location of the service makes it easy for the service provider to be swapped out without changing the clients using the service.
In the SOA world we may use an ESB to virtualise the endpoint by providing a fixed address for the service.  In addition to providing a fixed address we may also compensate for slight differences in the interface by using a mediator to map between the format the client wants to use and the format the new laundry service uses.

Personalising the Service

If we are a regular customer then the laundry may decide to offer us better rates or some other additional service.  This type of customisation may need to be accessed from several different places, for example the laundry may automatically iron shirts for premium customers, this impacts both the process of processing the laundry (the process flow) and also the billing engine, which should not charge for certain services based on the value of the customer.  Within a service oriented architecture a rules service will enable us to centralise common business rules, such as the free ironing service.  Centralising business rules in a rules service allows them to be applied consistently across an organisation, and managed in a single location, making changing them much easier.  In the SOA world a rules engine can provide this.

Finding a Laundry

Where to find a good laundry.  One option is to look in yellow pages for a laundry convenient to yourself.  The equivalent in the SOA world is to look it up in a service registry.

Protecting Your Smalls

An obvious concern is that you don't want your personal clothing stolen on the way to the laundry or tampered with in any way.  You expect the transport mechanisms and the procedures at the laundry to be such that your privacy will be protected and your smalls kept private.  You don't view this as part of the service interface but as a more fundamental attribute of the service.
In the SOA world we can use declarative security to confirm who is sending the message, and also to encrypt all or part of the message to prevent tampering with it.  Within the Oracle stack this functionality can be provided by the Web Services Manager.

A Clean Solution

I hope the suggestions above show why I like the laundry model and why I feel it relates better to SOA than does the lego model.  If you have other suggestions for extending the model please let me know.  Similarly if you have better models then let me know as well.
In the meantime may your whites stay clean and starched.

Patterns & Methods

Thought I would share some thoughts on Oracle SOA Methodologies and SOA patterns.  These are by no means complete, I just wanted to put down some ways in which SOA Suite can encourage good practise.

Methodologies

The Oracle SOA Success Methodology is a methodology with a small 'm'. 
It is best viewed as a set of tools of techniques that can be applied
within the context of a more proscriptive methodology.  That said it
works best with iterative methodologies.

The SOA Success Methodology is currently used with a restricted number
of Oracle customers prior to a full release.

Within the context of the SOA Success methodology is extensive
modelling of the business in terms of services.  Oracle BPA Suite can
be used to drive this iterative modelling process.

BPA encourages a focus on the abstract modelling side of the SOA
success methodology.  As the model becomes more reified then composite
services and processes may be made available to JDeveloper through a
shared repository.

Oracle is currently using BPA Suite to perform high level modelling in Fusion Applications development.

BPA Suite supports roundtripping to allow regeneration of processes
without loss of reifications applied to earlier versions, encouraging
an iterative cycle between business analyst and process developers.

SOA Patterns

Best source for SOA patterns in the Oracle space specifically is the BPEL cookbook
which covers a lot of common patterns and techniques.  Both the latest
release of Oracle SOA Suite 10g, and 11g currently in beta, encourages
these best practises in a number of ways, including but not limited to
the following.

• Rules abstraction for
• True Business Rules - tight integration of rules and BPEL
  encourage business process developers to abstract business logic into
  the rules engine - this is also available in 10g
  
  
• Routing Rules - tight integration of rules and Mediator encourage developers to abstract routing decisions into the rules engine
• Service Abstraction
  
  
• Encourages service level location abstraction by making it easy
  to hide physical endpoint of service - in 11g all BPEL processes are
  automatically packaged up in the same SCA assembly used to describe
  service deployments
• Encourages service level interface abstraction by encouraging
  use of mediator to transform between canonical and physical
  implementation formats
• Process Abstraction
• Definition of processes allows for lower level processes to be treated as services
• Capturing of process flows in code allows for simulation and modelling based on real world data
• Human workflow captures common best practise human interactions into re-usable templates
• Process Migration
• Champion/challenger processes - two versions of same process
  can run in parallel and be compared to see which yields best results
  based on concurrent versioning capabilities of BPEL process manager.
• Managed process migration - ability to run multiple versions of
  same process allows controlled introduction of new process versions
  whilst existing instance continue to execute.
  
  
• Service Discovery
• Service promotion - use of a registry allows services to be
  promoted from dev to test to production in a managed way, encouraging
  best practise.
• Service catalogue - use of UDDI allows such a catalogue to be
  maintained to encourage re-use by simplifying service discovery process
  
  

There is lots more but this was a quick brain dump.  Let me know which important ones I have missed.

License to Use or Tracking Service Usage

I was on a training course this week around an Oracle SOA Reference Architecture.  This led to an interesting conversation about what is a service.  There was a difference in opinion on some of the characteristics of a service, most noticeably does a service have to be re-used to be a service.  There was however, general agreement that the definition of a service presented was a good one so I thought I would share it with you.  The service definition had four parts

1. Service Contract – the requirements document for the service in terms of what does the service do and what promises does it provide in terms of response time, scalability, availability.
2. Service Interface – the formal definition of operations and data formats provided by the service.
3. Service Implementation – the physical endpoint and code that provides the service.
4. Service Usage Agreement – the contract between the client and the service.

The one that may not be immediately obvious is the fourth one, service usage agreement.  This indicates the expected level of use of the service by the client, number of requests per time period, message size and concurrency for example.  This is important because SOA is about using services in place, sharing not just the service code, but also its implementation resources such as network bandwidth, memory and cpu resources.  Usage by one client may impact another and so it is important to set expectations of how a given client may use the service.  Service usage agreements may be realised by policies within a service bus that enforce some of the constraints agreed within the usage agreement.

So all told I think a very useful way to think about services and I will certainly be making sure I do a better job of formalising the service usage agreement in future.

Design Patterns

Last week I received a heavy parcel through the post from Amazon containing Thomas Erls new book SOA Design Patterns.  I have been interested in design patterns for many years and still regularly refer to my copy of the gang of four (Design Patterns: Elements of Reusable Object-Oriented Software).  For those of you unaware of them, patterns provide a proven solution to a problem.  The gang of four book identifies four essential elements in a pattern (from section 1.1 What is a Design Pattern?).

1. A pattern name that extends our vocabularly when talking with colleagues, witness the common use of facade as a shorthand for the design principles of the facade pattern.
2. A problem that is addressed by the pattern.
3. A solution that describes an abstract design to solve the problem.
4. The consequences of applying the pattern, its results and its impacts both positive and negative.

It is worth noting that patterns are not created, they are discovered.  An important aspect of a pattern is that it should have been used in more than one solution.  The gang of four identified and documented 23 design patterns focused on object oriented languages.  The Thomas Erl book focuses as the name suggests on service oriented patterns.  Some of these patterns are service oriented forms of the gang of four patterns.  For example the service facade is an example of the facade pattern.  However Thomas explains how the service facade works in a a SOA and gives detailed explanations of its trade offs and benefits all closely related to SOA, providing a lot of added value even to people already familiar with the facade pattern.  The facade pattern in the gang of four covers 9 pages, in Thomas’ book it covers 12 pages but also includes a case study and is focused purely on SOA.

Think of the SOA Design Patterns as a cookbook of possibilities.  They cover lots of different patterns, many of them contributed by other SOA gurus such as Oracles David Chappell.  Use it as a reference book to see if there is a proven design approach that can solve some of your problems.  Remember that is a guide to good design, not a guarantor.

Well worth adding to your library!

Online SOA Readiness Assessment

Oracle have just made available an online SOA Readiness Assessment,  It asks you a few questions focused around the 8 areas in Oracles SOA maturity model and then provides a report.  The assessment is obviously very lightweight, but it is worth taking for several reasons.

• It gives you some reasonable suggestions about what steps to take next.
• It provides an initial SOA maturity assessment and compares it to your peers.
• It provides links to a number of helpful resources inside and outside Oracle.

The picture shows the type of high level maturity assessment generated.,  The 8 areas in the Oracle SOA Model with their definitions are

• Business & Strategy
• Contains capabilities that provide the high-level constructs that allow the SOA initiative to proceed. This includes such things as business motivation, expected benefits, guiding principles, expected costs, funding model, etc.
• Architecture
• Contains capabilities concerning the definitions of the overall architecture and guidelines for various practitioners to ensure adherence to the architecture.
• Infrastructure
• Contains capabilities concerning the service infrastructure and tools that provide the technical foundation for the SOA initiative.
• Information
• Contains capabilities concerning the information aspects of SOA, e.g., providing Information as a Service (IAAS). This includes shared data models, message formats and schemas, master data management, content management, etc.
• Projects, Portfolios & Services
• Contains capabilities concerning the planning and building of services and the service usage guidelines of service consumers.
• Operations, Administration & Management
• Contains capabilities concerning the post deployment aspects of solutions based on a service-oriented architecture.
• Organization
• Contains capabilities concerning the development of corporate competency around SOA including the organizational structure and skills development.
• Governance
• Contains capabilities concerning the governance structures and processes that support and guide the SOA efforts. Maturity and adoption of adequate amount of governance is a leading indicator of the overall SOA success.

Remember that one of goals of a SOA Strategy is to identify the level of maturity required in each area.  Not every organization requires the highest levels to get the best value out of SOA.  For example an organization with a small service estate and correspondingly small focused projects does not require a large SOA governance infrastructure.  I’m interested to hear what people think about the assessment tool which now joins Oracles BPM assessment tool.

 Oracle SOA Executive Roundtable Webcast: Top Five Insights for Maximizing Returns with SOA

Oracle are having an executive round table web cast at 8AM PDT Thursday 23rd 2009 chaired by Amlan Debnath, Senior Vice President Integration Products at Oracle.  Other attendees include

• Job Simon, Senior Director, NetApp
  Dan Goerdt, Director, Schneider National Inc.
  Jennifer Briscoe, CTO and VP, Collect America

Check out the registration page here.

Tuxedo Connections or the On Ramp to Tux

Tuxedo can be considered as the original and purest service oriented architecture.  The key abstraction in Tuxedo is the service and everything is made to fit into the service mould.  It seems strange then that people think of Tuxedo as a legacy application.  Tuxedo is highly regarded by the senior management team in Oracle who view it as a key tool to support extreme transaction processing.  The question is then, how does this relate to the rest of the SOA world which does not subscribe to the Tuxedo technologies such ATMI, C++ or COBOL.

The diagram below shows the different interfaces into and out of the Tuxedo world.  Lets look at them briefly and how they relate to the rest of the SOA world which is focussed on XML, SOAP and HTTP.

Native Client Interfaces

The native client interfaces to Tuxedo are the C, C++, .Net or COBOL client interfaces using ATMI (Application to Transaction Monitor Interface).  There is also a version of ATMI for Java, called Jolt.  These interfaces allow clients to invoke Tuxedo services and get responses.  They do not allow Tuxedo to invoke services in these clients except by listening on Tuxedo message queues, these interfaces are asymmetric.

Legacy Client and Server Interfaces

A Tuxedo domain can interface to other Tuxedo domains, treating their services as though they were its own services.  This capability is extended to other systems such as mainframe systems.  The external systems see Tuxedo services as native services and invoke them as they would any other service, similarly Tuxedo sees these external systems as native Tuxedo services and invokes them as it would any other service.  This provides relatively seamless integration between legacy environments and Tuxedo and allows either side to operate as a server to the other, in other words these interfaces are symmetric.

Open System Interfaces

In addition to treating legacy mainframe interfaces and other Tuxedo domains in the same way as local services Tuxedo can also do this for such open system standards as CORBA and java code running in WebLogic Server.  CORBA applications can invoke Tux services through the CORBA API and Tuxedo services can invoke CORBA objects.  The WebLogic Tuxedo Connector (WTC) extends the capabilities of Jolt to become fully symmetric in that EJBs in WebLogic can be invoked as services from Tuxedo.

A Transactional Note

Note that all the interfaces we have spoken about so far are transactional, as in they are part of the Tuxedo transaction infrastructure, invoking a remote mainframe transaction may cause an XA transaction to be started within Tuxedo.  When calling an EJB in WebLogic this also is part of the overall Tuxedo XA transaction infrastructure.

Web Service Access to Tuxedo

There are two alternative ways to get Web Services to access Tuxedo.  The most obvious is to use SALT (Service Architecture Leveraging Tuxedo) which exposes Tuxedo services as web services, and allows Tuxedo to invoke Web Services as though they were Tuxedo services.  This is a symmetric interface and takes care of all the XML to Tuxedo translations but it is not transactional.  The web service call is not part of the transaction.  A web service request to Tuxedo may cause a Tux transaction to be initiated, but webs services don’t currently provide a transactional context.  Similarly when Tux makes a call to a web service, that call is not part of any Tuxedo transaction.

So what if you want transactionality and access to web services.  This is where the service bus comes in.  The Oracle Service Bus (OSB) takes advantage of the WebLogic Tuxedo Connector to provide a fast efficient and transactional interface to and from the Tuxedo world.  This allows a pipeline to make two seperate calls to Tuxedo as part of the same transaction.  Note that there are a couple fo wrinkles to making this happen and I will deal with those in a later post.

Summary – Long Live Tux, King of Services

Not only is Tuxedo the original service oriented architecture but despite being more than 20 years old, through SALT and WebLogic Tuxedo Connector it still speaks the modern lingo of service buses, Java, XML, SOAP and HTTP.  So if you have a Tuxedo investment don’t write it off, but look at how you can more easily make your Tux services available to the new fangled XML based web service world.

Last Wednesday the Open Group made available their SOA Source Book.  They describe it as “a collection of source material produced by the SOA Working Group for use by enterprise architects working with Service-Oriented Architecture”.  Having looked at it I have to say it seems to have a high information density and would be a good place to start getting someone's head around SOA concepts.  Well worth a look.