to LooselyCoupled.com homepage
 
 Weekly emails: how to advanced search
 Glossary lookup:

 

> opinion > vendor perspective


New rules govern SOA lifecycle

by Jared Rodriguez
July 1st, 2005

Moving to SOA requires a strategic commitment to create a more flexible IT system that maps closely with business processes, instead of trying to retrofit business requirements into technology decisions. Once the commitment is made, the path to SOA can be very difficult or very straightforward based on the enabling technologies and practices.

 
• print  • comment

The main value propositions behind SOA are reuse, efficient development, simplified maintenance and portability, producing the flexibility to evolve more advanced business processes. However, managing those processes is a significant challenge.

Jared Rodriquez is founder, CTO and CEO of Skyway Software, which has created a platform to build, govern, and deploy business level solutions, processes and services in an enterprise SOA. This article is adapted from Skyway Software's white paper, Service Oriented Architecture - Realizing the Business Value.


Glossary terms: governance, SOA, business process, BPEL, SOAP, lookup tool

Construct — model the custom SOA services
Many SOA platforms require extensive engineering and knowledge of specific programming languages in order to extend custom services and evolve SOA throughout the enterprise. Most of today's development platforms, which are re-branding themselves as SOA, require knowledge of .NET, J2EE, or other programming languages. The ability for these platforms to enable business service development, deployment and management is very limited. Services developed using these frameworks, otherwise known as Integrated Development Environments (IDEs), require extensive engineering expertise, not only for development but also for distribution. This often results in the retraining or rehiring of IT staff.

Early best practices for SOA strongly support a model driven approach to composite application development, modularity and extensibility. Application modeling is especially useful to SOA, as it allows for architects to evolve their solutions in flexible ways and enable companies to define, manipulate and store processes, as they exist — apart from the specific technology needed to support them. Many codeless tools and claims have surfaced over the years and many have failed when it came to proving their promises. The evolution of such claims has gotten closer to the mark over time, and current technology and design metaphors have finally made codeless development a reality. By eliminating the time-consuming process of manually writing code, companies can drastically accelerate their solution development.

Assemble — connect to native and web services as part of an SOA solution
Some of the confusion in the acceptance and adaptation of SOA has been the misconception that Web Services and BPEL (Business Process Execution Language) are the key components of building out an SOA. Both have played a large part in the evolution of business and application development and certainly have their applicability. However, they are merely components in a successful SOA. Services within the SOA should be implemented based upon the specific requirement.

Services in a SOA will be created in many fashions — some in Java, some in C#, and some in C or C++. Deploying these services as web services would be well suited for interoperability, as they are by nature heterogeneous, interoperable, and loosely coupled. However, when building end-user applications or high volume processes, web services may not be the best choice. Web services are expensive in both processing and bandwidth. On average, a web service invocation is 10 times larger than the binary form of such an object interaction. Using XML and SOAP requires huge chunks of bandwidth when dealing with large numbers of transactions, as both the SOAP transport and all data are passed as XML, which is expressed as raw text.

BPEL, in theory, gets us closer to SOA today and has been a good way to link and assemble some business processes, although it is not an enterprise platform for deploying high volume custom business applications. BPEL is for orchestration only: it enables the calling of processes, but does not allow for new processes to be developed. It can be an optional layer of SOA, but BPEL alone will not deliver an SOA, as it relies entirely on Web services and XML. Some of the early problems with BPEL have been difficulty in adhering to standards. Considerable customization is required to implement BPEL. Standards are often lost in the process, and many of the services end up becoming proprietary solutions, thereby losing the ability to be quickly extensible as the business requirements change.

These are challenges that can be solved by implementing a distributed infrastructure comprised of web services, Java, and other native services, thereby creating services that make the most sense for SOA — both web services and native services.

Control — catalog, govern, provision, and deploy services
Some services built today will become part of larger service implementations in the future as Enterprise SOA. As the SOA grows into several thousand services, manageability must be a key consideration early on. The main value propositions behind SOA are reuse, efficient development, simplified maintenance and portability, producing the flexibility to evolve more advanced business processes. However, managing those processes is a significant challenge.

In terms of delivery, control is required at the application, systems and infrastructure levels. As SOA implementations expand, different levels of service management will be required in order to deploy, distribute, extend, and monitor the SOA. The SOA platform market contains many technologies that address management and infrastructure monitoring, however these tools do not address the provisioning of service development, integration, and distribution. As your services move through development, such as QA and delivery, maintaining consistency and quality along the way is a key component.

The release cycle is often a forgotten element in many projects. Once a project is released, a different set of challenges surfaces for updating released versions of the software due to the many dependencies that exist. With SOA, the challenge is even greater as the goal of SOA is to deploy services only once and access them from anywhere. Imagine a few thousand services being deployed to many different servers throughout the enterprise. The URL and location of those services will differ from that of existing production services, multiplied by how many services are being released. The easiest solution for most would be to redeploy the service to many locations. This defeats the value of SOA and creates more complexities around service versioning.

In terms of SOA lifecycle, control is required at all phases (design, build, test, deploy, and operate). As SOA implementations expand, companies will need a catalog of services and an approval/workflow process (governance) to ensure that the value propositions are realized.


More on this topic


Related

Weak governance haunts SOAs
Making sure that developers adhere to corporate policies in an SOA ...


 
 


Copyright © 2002-2006, Procullux Media Ltd. All Rights Reserved.