sdoe – 678 engineering of agile systems and enterprises ... · sdoe – 678 service oriented...

SDOE – 678Engineering of Agile Systems and Enterprises

Term Project

Service Oriented ArchitectureAvoiding Speed Bumps on the Road to an Agile Enterprise

Stevens Institute of TechnologyHoboken, NJ 07030

Project Prepared by:Randell A. Wolfe

Academic Advisor:Rick Dove

Rick

Text Box

Class of 24March2008

SDOE – 678 Service Oriented Architecture 2 of 35Avoiding Speed Bumps on the Road to an Agile Enterprise

Randell A. Wolfe

Table of ContentsSystem Description....................................................................................................................................5

Drag and Drop Modules........................................................................................................................7Integrity Management...........................................................................................................................8

Component Mix................................................................................................................................8Component Inventory.......................................................................................................................8System Assembly.............................................................................................................................8

Time Based Focuses..............................................................................................................................8Infrastructure Evolution....................................................................................................................9

Plug and Play Standards........................................................................................................................9Agility of the System.................................................................................................................................9

RRS-Principles......................................................................................................................................9Reusable.........................................................................................................................................10

Self-Contained Units – Encapsulated Modules.........................................................................10Plug Compatibility – Facilitated Interfacing.............................................................................11Facilitated Reuse........................................................................................................................11

Scalable...........................................................................................................................................11Evolving Standards – Infrastructure/Framework.......................................................................11Redundancy and Diversity.........................................................................................................11Elastic Capacity – Scalable........................................................................................................11

Reconfigurable...............................................................................................................................11Flat Interaction – Peer-Peer/Non-Hierarchical..........................................................................12Deferred Commitment...............................................................................................................12Distributed Control and Information – Decentralized...............................................................12Self-Organization.......................................................................................................................12

Response-ability..................................................................................................................................12Proactive.........................................................................................................................................13

Creation/Elimination..................................................................................................................13Improvement..............................................................................................................................13Migration...................................................................................................................................14Modification...............................................................................................................................14

Reactive..........................................................................................................................................14Correction..................................................................................................................................14Variation....................................................................................................................................14Expansion/Contraction...............................................................................................................14Reconfiguration.........................................................................................................................14

Change-Enabling Structure and Culture.............................................................................................15Adaptable Structure........................................................................................................................15Adaptable Products.........................................................................................................................15Adaptable Processes.......................................................................................................................15

Contains no export controlled technical data subject to ITAR Regulation


Randell A. Wolfe

Adaptable Practices........................................................................................................................15Adaptable Culture...........................................................................................................................16

Systematic Design....................................................................................................................................16Design Framework..............................................................................................................................16

Proactive.........................................................................................................................................17Vulnerability/Risk Anticipation.................................................................................................17Prudence.....................................................................................................................................17Transformation...........................................................................................................................18Threat Anticipation....................................................................................................................18Migration...................................................................................................................................18Accountability............................................................................................................................18

Reactive..........................................................................................................................................18Detection....................................................................................................................................18Containment...............................................................................................................................18Mitigation...................................................................................................................................18Assessment.................................................................................................................................19Recovery....................................................................................................................................19Accountability............................................................................................................................19

Reality Factors.....................................................................................................................................19Human Behavior.............................................................................................................................20Organization Behavior....................................................................................................................21Technology Pace............................................................................................................................22System Complexity........................................................................................................................22Globalization..................................................................................................................................22Creeping Agile Practices................................................................................................................22Agile Adversaries...........................................................................................................................23

Change Proficiency.............................................................................................................................23Time of Change..............................................................................................................................23Cost of Change...............................................................................................................................23Quality of Change...........................................................................................................................23Scope of Change.............................................................................................................................24

Activity Diagram.................................................................................................................................24Modular..........................................................................................................................................25

Service Creation.........................................................................................................................25Application Creation..................................................................................................................26

Scalable...........................................................................................................................................26Application Creation..................................................................................................................26Industry Standards.....................................................................................................................26Mirror Business Needs...............................................................................................................26

Business Oriented...........................................................................................................................26Mirrors Business Needs.............................................................................................................26Full Life Cycle Support.............................................................................................................26

Closure Matrix.....................................................................................................................................27



Randell A. Wolfe

Conclusion...............................................................................................................................................29References................................................................................................................................................30Appendix A .............................................................................................................................................31Metaphor Story........................................................................................................................................32Metaphor Story........................................................................................................................................32

Illustration IndexIllustration 1: Abstract SOA......................................................................................................................5Illustration 2: SOA System Diagram.........................................................................................................6Illustration 3: Overall SOA Change Proficiency.....................................................................................24Illustration 4: Activity Diagram...............................................................................................................25Illustration 5: Response Proficiency Space..............................................................................................30

Index of TablesTable 1: RRS Principles...........................................................................................................................10Table 2: Response-Ability Analysis........................................................................................................13Table 3: Strategic Design Framework.....................................................................................................17Table 4: Reality Factors...........................................................................................................................20Table 5: Change Metrics..........................................................................................................................23



Randell A. Wolfe

Abstract – This paper investigates the agile aspects of the latest incarnation of Service Oriented Architectures (SOA) Web Services (WS) (SOA-WS). Agility is explored by analyzing the SOA-WS against the agility framework as expressed in Rick Doves book “Response Ability – The Language, Structure, and Culture of the Agile Enterprise”. The agility metrics introduced by this book are the result of many years of effort as the co-lead for an industry/government project at Lehigh University to “identify the competitive frontier in 2005”. Although 2005 has come and gone, the forward looking nature of the research applies today and into the foreseeable future as much as it did then. Using the Dove framework the conclusion is reached that SOA via web services has the potential to be agile, but the technology itself is not enough. Strong Program Management practices and Systems Engineering oversight will be necessary to make sure we do not become, once again, “Fools with a tool”. In addition to this management necessity, designers must change the way they think following SOA best practices to assure the success of their SOA-WS.Special Note: I have followed Dove's lead from his aforementioned book. The entire contents of this paper can be derived by viewing the pictures and tables. The text is merely an aid to hopefully give more information should the pictures and tables not be enough.

System DescriptionService Oriented Architectures (SOA) are themselves abstract concepts. There have been several technologies which have attempted to provide the core technologies for SOA such as the Common Object Request Broker (CORBA), and Remote Procedure Calls (RPC). An abstract service oriented architecture is composed of services, messages and registries as shown in illustration 1.

In this diagram the registry acts as a yellow pages containing all information necessary for a service to locate and communicate with another service. The three services communicate with each other


Illustration 1: Abstract SOA

Service 1

Service 3 Service 2

Message 1

Message 2

Message 1

Message 2

Registry

http://www.parshift.com/BioDove.htm

http://www.sei.cmu.edu/str/descriptions/rpc.html

http://www.omg.org/gettingstarted/corbafaq.htm

http://www.omg.org/gettingstarted/corbafaq.htm

http://www.amazon.com/Service-Oriented-Architecture-SOA-Technology-Computing/dp/0131858580

http://www.mario-konrad.ch/index.php?page=10005

http://www.amazon.com/Response-Ability-Language-Structure-Enterprise/dp/0471350184/ref=sr_1_1?ie=UTF8&s=books&qid=1212873141&sr=8-1

http://www3.lehigh.edu/default.asp



Randell A. Wolfe

using messages whose structure is detailed in the registry. A service typically has one interface it understands, so Service 2 always expects to receive messages of structure Message 2, while Service 1 expects to receive messages of structure Message 1. Messages themselves are self contained, providing all information necessary for a request to be fulfilled. This self containment allows the service to be stateless, reducing logic complexity and storage needs. The messages are interpreted and filled in by the services which contain the required logic to fulfill each request.

As mentioned, there have been several attempts at fulfilling SOA with various levels of success, the most recent actualization of SOA, and the focus of this paper, is Web Services. In web services, the registry is realized via the Universal Description, Discovery and Integration (UDDI); Messages are realized via SOAP and services via Web Services. Although these are the basic building blocks, the problem has become significantly more complex with the explosion of available web services and standards; as shown in drawing 2.

This diagram organizes the various aspects of a system into a form appropriate for analyzing various aspects of agility. These aspects revolve around architectural decisions recognized by Dove and his


Illustration 2: SOA System Diagram

Service Oriented Architectures

TimeTime

Infrastructure evolution:

System assembly:

Component mix:

Component inventory:


System assembly:

Component mix:


Business FocusedApplication Focused Enterprise Focused

application entityservices

orchestrationservices

WS-Iservices

choreographyservices

UDDI WSDL

Drag & Drop Modules

Plug & Play Standards

Active

Infrastructure

Passive

misc SpecificationsOASIS Specifications

W3C SpecificationsWS-I.org Basic Profile



IntegrityManagement

Various Developers

UDDI

WSO - BPEL

WSO-I.org


http://en.wikipedia.org/wiki/Web_Services

http://en.wikipedia.org/wiki/SOAP

http://en.wikipedia.org/wiki/UDDI


Randell A. Wolfe

team as having importance for the agility of a system.

Drag and Drop ModulesAlthough not reflected in the diagram, the SOAP messages provide the common communication infrastructure for communication between services. As with the abstract SOA, these messages have specific structure as required by each web service.

Each web service advertises itself in the previously mentioned UDDI, detailing its service and required SOAP structure via a Web Services Description Language (WSDL) definition.

Web services themselves come in many sizes and shapes. At the lowest and earliest level of development are the application services. These services are created by a system developer to provide business logic not available through COTS services. Next up the hierarchy are Web Services Interoperability Organization Services (WS-I). These services are actually a subset of all the available COTS web services. With the popularity and rapid growth of web services, many organizations and companies started creating their own web service standards. The problem became how to choose from the available web service standards, without painting oneself into a corner. Virtually all the major vendors and standards bodies came together to form the Web Service Interoperability Organization. The sole goal of this organization is to communicate to the SOA-WS buying and producing public which standards have wide enough acceptance to avoid vendor lock in. The communication mechanism the WS-I organizations uses is their Basic Profile. The Basic Profile is a list of standards the WS-I feels are widely enough used to be considered safe for use in a heterogeneous system environment.

Next up the hierarchy are the Orchestration Services. Orchestration services provide a common mechanism for allowing services to work together to perform higher level business functions. Orchestration services are written in a high level service scripting language, Business Process Execution Language (BPEL), allowing easier creation and modification than the lower level languages in which application services are typically written. BPEL scripts normally provide business wide functionality allowing multiple business units to work together.

At the top of the hierarchy are Choreography Services. Choreography services are implemented in an XML based business process modeling language higher even than BPEL. Choreography services usually provide cross company functionality allowing two organizations in different companies to work seamlessly together.

The metaphor model in the appendix demonstrates all of these elements in a hypothetical future military context. Some items to note which are unusual, even for SOA, is the blending of non computer world entities into the computer world as services. This blending allows commanding of real world entities, as simply as software systems.


http://en.wikipedia.org/wiki/Web_Service_Choreography

http://en.wikipedia.org/wiki/Business_Process_Execution_Language



http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

http://www.ws-i.org/




http://en.wikipedia.org/wiki/Web_Services_Description_Language


Randell A. Wolfe

Integrity ManagementIntegrity management is the processes by which the soundness of the system is maintained as the system evolves in time. Managing the integrity of any system is key to the long term success of that system. Without integrity management it is easy for even a solid system to decay into useless pieces. This section details the various areas of integrity management and how they are addressed in the SOA-WS arena.

Component MixThe component mix of a SOA-WS is controlled by the individual developers, realized through the mix of services in the system. Most times the SOA design decisions made by the developers is coincidental to their task at hand, with no thought being made towards “component mix” of the entire system. Instead the individual developers look to what services are necessary to complete their task. The beneficial component mix tends to come from the fact that specific business types have specific business needs as dictated by the industry in which the organization finds itself. These needs tend to be across the entire business, not just an individual department. So when the first department finds a need for a specific service to fulfill its application need, the odds are high that this service will be needed by another department at some future point in time. As long as there is a convenient; accurate; and detailed inventory of the available services, reuse of the service becomes at least possible.

Component InventoryThe Universal Description, Discovery and Integration (UDDI) is the component inventory of the available services. A UDDI is a collection center for the WSDL descriptions of all the services available throughout the system. This description is not only human readable, but is also computer processable. The WSDL description for a particular service details the service performed and the SOAP message structures necessary to interface with that service. There can be many services in a UDDI which provide the same logic, each (hopefully) with the same SOAP interface. Decisions can be made at runtime as to which instance of a service a calling service utilizes. This decision may be made based off location of service provider, cost of service or any other service distinguishing feature.

System AssemblyOrganizing the individual services into a business wide system is under the auspices of the Oasis Business Process Execution Language for Web Services (BPEL4WS). This higher order scripting language allows a business process developer to quickly bring various application services together to perform a particular business wide function.

Time Based FocusesIn an enterprise there will be a natural time progression of complexity for the system of services built. Initially there will be individual groups that develop their own applications utilizing web services. In


http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel


Randell A. Wolfe

illustration 2 this is the application focused time span. As general business services become available, construction of business wide applications will become easier. In illustration 2 this is the business focused time span. Finally as SOA-WS becomes an enterprise standard with the entirety of the business as well as business partners on line, large SOA-WS cross business applications become possible. In illustration 2 this is the enterprise time span.

Infrastructure EvolutionOver time the system will naturally evolve. This evolving system acts as the infrastructure for future applications and business processes. Care must be taken to assure that the evolution of this infrastructure does not go down a path which will lead to the extinction of the system, and with it, the business enterprise. In the technology based world this bad mutation tends to take the form of tying oneself to a technology only available from a single vendor resulting in vendor lock in. Web services are not exactly in the infant stage, but are at best just learning to walk. Web services, rightly or wrongly are tied at the hip with the World Wide Web. The amazing success of the web is naively viewed by many as guaranteed success for web services. This immense potential combined with an under abundance of interface standards has every company vying to become the interface owner for the next big widget. The question every SOA-WS architect should ask themselves is “How do I guarantee that I don't pick the service equivalent of the Edsel?” or “How do I guarantee that I don't buy the problems of the single company that supports a particular interface?”. The answer to both questions is the WS-I.org. The WS-I provides a “Basic Profile” which only includes well supported standard interfaces for various services. Currently these services primarily revolve around infrastructure like security, transaction management, etc . But as industry standards for customer management and accounts payable become more standardized, WS-I is likely to be the clearing house for the accepted industry standard.

Plug and Play StandardsStandards play an essential role in SOA. Much of the agility of SOA-WS comes from bodies, industries, corporate and departmental standards. The two main standards producers are the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). In addition there are many companies trying to stake out their claim in the web service standards world. The Web Service Interoperability Organization (WS-I) acts as a clearing house for developers making sure the developer keeps themselves out of trouble in the form of vendor lock in.

Agility of the SystemNow that the overall SOA-WS system structure is understood we will use the Dove agility metrics to measure the agility of SOA-WS.

RRS-PrinciplesThe “big 3” principles an agile system must address are re-usability, scalability, and


http://en.wikipedia.org/wiki/Vendor_lock-in

http://en.wikipedia.org/wiki/Vendor_lock-in

http://www.WS-I.org/

http://www.oasis-open.org/


http://www.w3c.org/

http://www.w3c.org/

http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html

http://www.ws-i.org/Profiles/BasicProfile-1_2(WGAD).html

http://ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

http://ws-i.org/

http://www.antipatterns.com/vendorlockin.htm

http://en.wikipedia.org/wiki/Edsel


Randell A. Wolfe

reconfigurability. Dove and team found not only these issues but specific sub issues important to the agility of a system. Table 1 summarizes and the following sections detail how SOA-WS measures up to these agility metrics.

ReusableIn an agile enterprise in this rapidly changing world waste can not be allowed. To help minimize waste as much as possible components used to construct the system must be reusable. There are three dimensions which help contribute to this re-usability.

Self-Contained Units – Encapsulated ModulesDuring development it is difficult if not impossible to identify which units will be needed in the far future. Instead of trying to rely on a crystal ball or, worse yet, not considering re-usability at all, developing self contained units almost guarantees that which will be needed will be available. SOA-WS mandates such self-contained units. This makes services distinct, separable, loosely-coupled, and self sufficient.


Table 1: RRS Principles

Response Able System Principles – RRS

Reconfigurable

Scal

able

Reusable

Self-Contained Units (Encapsulated Modules)Services are distinct, separable, loosely-coupled, self-sufficient units cooperating toward a shared common purpose. The purpose can be different depending on whether working at the application, business or enterprise level.Plug Compatibility (Facilitated Interfacing)Services share defined interaction and interface standards through the SOAP messaging standard; and are easily inserted or removed by placing their WSDL definition in the UDDI.

Facilitated ReuseWS-I Services are reusable and replicable being defined to handle common coding patterns. Application services are reusable and replicable being defined to handle application specific tasks.

Evolving Standards (Infrastructure/Framework)The SOAP and WS-I standards formalize inter-service communication and interaction; define service compatibility; common WSDL allows old, current, and new services to be used simultaneously.Redundancy and DiversityDuplicate services and load balancing provide capacity right-sizing options and fail-soft tolerance; diversity among different vendor WS-I implementations can be exploited.

Elastic Capacity (Scalable)Service populations in response able systems may be increased and decreased widely within the existing framework through load balancing services.

Flat Interaction (Peer-Peer, Non-Hierarchical)WSDL in the UDDI combined with real time service location allowspeer-to-peer relationships; and parallel relationships. Sequential relationships are supported when needed.

Deferred CommitmentService relationships are transient, only existing as long as the business process exists. Decisions and fixed bindings are postponed until immediately necessary through UDDI lookup; This also binds relationships in real-time.

Distributed Control and Information (Decentralized)Services are directed by business need rather than method; decisions are made at point of maximum knowledge; information is associated locally, accessible globally, and freely disseminated through the SOAP message aggregation.Self-OrganizationService relationships are self-determined by business process need; and service interaction is self-adjusting or negotiated as determined by higher-order business logic.


Randell A. Wolfe

Plug Compatibility – Facilitated InterfacingReuse of any software is difficult if the interface is complex, not well documented, or difficult to find. The use of WSDL stored in UDDI to detail the service offered and the SOAP structure to use the service combats all these issues. Addition/removal of web services is simply a matter of placing/removing the appropriate WSDL in the UDDI.

Facilitated ReuseThe strict definition and documentation of services via WSDL combined with the publication allows easy access to any web service. Purchasing commercial web services and placing them on the company UDDI provides access to the entire corporate network. The UDDI acts as the directory of services available. Any developer building an application would be well served to investigate the contents of the UDDI to see which services are already available before embarking on a development journey. Enterprise Architects in the guise of Systems Engineers can facilitate this effort.

ScalableIf the companies applications cannot scale with the company, they can become a limiting factor to the growth of the company. In today's quarterly profit driven companies, this is not acceptable. This section addresses the various ways an agile system must support scalability.

Evolving Standards – Infrastructure/FrameworkSupport for evolving standards comes in the form of the WS-I organization. This organization acts as the gate keeper providing for cross-industry infrastructure and framework standards evolution.

Redundancy and DiversityAny service can be run on any number of machines allowing an organization to either scale up or down their applications as needed. Multiple copies of a service can be run simultaneously.

Elastic Capacity – ScalableUse of load balancing services combined with late identification of the service to use provides for a very response able system.

ReconfigurableMonolithic systems which perform a single task, no matter how well they perform the task, tend to be brittle. This brittleness manifests itself in many forms but inability the change is the most readily observed. Reconfigurability is essential to an agile system, extending the lifetime of the system long beyond the life of most monolithic systems.



Randell A. Wolfe

Flat Interaction – Peer-Peer/Non-HierarchicalThe deeper the hierarchy of a system, the more tightly coupled the system is likely to be. This results in a system which is difficult to change. SOA-WS establishes an environment where all services are treated as peers. Even though a particular service may be three layers down in a service we are using directly, that deep service is also directly available should we need it.

Deferred CommitmentSOA-WSs use of WSDL in UDDI encourages an application to decide at runtime what service to use. This allows for optimal use of computing resources and avoidance of dependencies on broken servers.

Distributed Control and Information – DecentralizedWithin a SOA-WS organization there is no need for a central body to control content. Each user community has the knowledge on what they need as well as the information necessary to achieve their goal. Although this information is locally known, once it is published in the UDDI with the WSDL, the service becomes globally accessible. Any service which can construct the WSDL documented SOAP message can consume the service.

Self-OrganizationDepartments organize the available services how they need. Business units organize the services how they need. Enterprise level organization organize the available services how they need. This all combined with replicated services doled out based off load balancing provides a system where the organization of the system is very agile: adapting to server outages, excess loads, etc.

Response-abilityWhere the previous section identifies the architectural issues of an agile system, this section details issues important to the life span of an agile system. Specifically how the agile system addresses change. Table 2 provides an overview of how SOA-WS meets these critical needs.



Randell A. Wolfe

ProactiveProactive change domains are the forefront of identifying and correcting change problems before they are problems.

Creation/EliminationThe WSDL definitions in the UDDI combined with the interfaces imposed by SOAP provide an environment that encourages creation and replacement of web services. To publish a new interface simply requires the placement of the WSDL definition of the service in the UDDI. Likewise removing the WSDL from the UDDI removes the service from the system.

ImprovementThe contract established by the SOAP interfaces is the sole binding of two service together. As long as this interface is constant the using service need not know that the used service has changed. This


Table 2: Response-Ability Analysis

Change Domains General Issues

Proa

ctiv

e

Creation/Elimination

Improvement

Migration

Modification

Reac

tive

Correction

Variation

Expansion/Contraction

Reconfiguration

Through the use of the WSDL published in the UDDI, new services can easily be added or removed.As long as the WSDL for a particular service does not change, the implementation can be easily changed improving performance, accuracy, or ROI for the life of the web services technology.For any new technology to displace web services, the creators will have to provide migration tools and strategies otherwise the costs will be too high for users of web services and the new technology will be a non starter. This combined with the far reaching use of web services guarantees that should a migration ever be desired, it will be practical.New services can easily be added or removed simply by publishing or removing their WSDL descriptions from the UDDI directories.Should a problem be found in an implementation of a service, an equivalent replacement service can be added, with no negative effect on or changes of users of the old service be necessary.Implementation of services as described in the “Metaphor Story” can provide for a virtually infinite variation in the real time operations within the systems mission.Monitoring of the system under use and during exercises can be used to purchase additional server resources for hosting the services. The sophistication of the dynamic addition and removal of servers is limited only by vendors load sharing logic and the amount of money available for servers.All resources are by the very nature of web services, available to anyone on the network with appropriate authority through security credentials. A process manifests itself as a web service possibly directing other web services. Changing a process is noting more than changing either the coding of the process, or in the case BPEL use, changing the BPEL script.


Randell A. Wolfe

loose coupling provides an environment where improvement of a service for ROI or resource usage will have minimal negative impact on the service users.

MigrationSOA-WS may be the be all end all SOA for all time, but I doubt it. However whatever it is that replaces SOA will likely have to provide a migration path, otherwise the cost of switchover will be too much. This problem is subtly different from vendor lock in. In vendor lock in a displacing company would have to expend the effort to overcome a single competitor. Rarely is this worth the effort. In the case of SOA-WS the creator(s) are trying to displace an entire market segment. If the follow on to SOA-WS, whatever it is, happens, there is guaranteed to be a race amongst the new deliverers to have the easiest migration path to the next new thing.

ModificationA SOA-WS system is easily modified via the addition or removal of WSDL at the UDDI.

ReactiveReactive change domains are the domains we find ourselves in when the proactive domains failed to see a looming problem.

CorrectionShould a problem be found in a service, small modular services are easier to fix than monolithic applications. In addition, bringing a new replacement service on line is a simple matter of placing the new service's WSDL in the UDDI.

VariationAs the visibility of the parts of the application for SOA-WS exceeds virtually all other application domains, the possible variations in the use of the components is virtually infinite.

Expansion/ContractionSince SOA-WS is built on the same technological infrastructure as the World Wide Web, all the tools available to monitor network usage there are applicable to the SOA-WS domain. These tools can be used as they are today to help the network and service administrators bring on new servers, or reconfigure enterprise or department UDDIs to optimize the performance of the system as a whole.

ReconfigurationWeb services are by their very nature available to anyone on the network with correct security credentials. Applications are composed of web services which use other web services. Business



Randell A. Wolfe

application are also web services which utilize other web services. This flat peer-to-peer environment promotes a level of loose cohesiveness which allows for rapid reconfiguration. The standard network tools provided by the major network vendors are a great aid in deciding on and executing the reconfiguration at one level. The use of the easily changed high level BPEL scripts enables change at a higher level.

Change-Enabling Structure and CultureTechnology is rarely enough to provide for agility in a company and SOA-WS is no different. When C++ was being introduced by the brilliant Bjarne Stroustrup a non techy interviewer asked if this would allow every programmer to write better programs. His response has stuck with me for all these years, “A fool with a tool, is just a fool with a tool”. SOA-WS must have the support of the enterprise structure and culture otherwise SOA-WS will simply become the next big over hyped technological silver bullet at the company.

Adaptable StructureThe organization must be as equally agile as the SOA-WS systems generated. In addition, the organizational structure will need to have a cadre of trained system architects and software engineers who can easily move around the company to build needed web services.

Adaptable ProductsAs long as the services developed model the business, the odds of a drastic change to which the system cannot adapt is relatively small. In my 28 years of object oriented analysis and design (OOA/D) a tenet to which I have always stuck is “model the real world”. Although seemingly obvious, it is amazing how few have realized this core truth. If in the SOA-WS you stick with this rule and unless there is a major paradigm shift in which all old ways become extinct, you will be able to reconfigure the parts to whatever your needs.

Adaptable ProcessesThe organization must buy in to the concept of automated process first. Then through the use of BPEL4WS the organizational processes will be adaptable.

Adaptable PracticesApplying adaptable practices such as agile software development to SOA-WS can be a very powerful combination. Not applying agile development does not guarantee failure, but if the enterprise institutes a rigorous highly hierarchical step by step process, the agility of the whole system can be compromised.


http://en.wikipedia.org/wiki/Agile_software_development

http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

http://en.wikipedia.org/wiki/Bjarne_Stroustrup

http://en.wikipedia.org/wiki/C++


Randell A. Wolfe

Adaptable CultureThis could easily be the most difficult aspect of adaptability. Most engineers tend to be quite logical. Once shown the benefit of anything they will go whole hog, sometimes too whole hog, in that direction. For them, selling SOA-WS should be little problem. However there is almost always someone in an organization who is quite territorial. This can manifest itself in many ways as described later in the reality factors section. The organizational culture must overcome this sticking points to assure agility of the entire enterprise.

Systematic DesignAll of the agility aspects addressed so far have been purely from a generic SOA-WS perspective and would not change for any SOA-WS implementation. The following section will also remain at the generic SOA-WS perspective but should be reanalyzed and measured for any particular SOA-WS implementation. It is listed in a separate design section as a result of this analysis only being able to be accurately performed late in the design process.

Design FrameworkThis first section in design addresses strategic design issues Dove's team found in their agility research as being common to the agile systems. Addressing these issues helps assure a system's longevity.



Randell A. Wolfe

ProactiveThe proactive strategic design issues are those issues that are addressed before there is a problem, trying to avoid there ever being a problem.

Vulnerability/Risk AnticipationSince web services rely heavily on standard network technologies, the SOA-WS community can heavily leverage the vulnerability and risk assessments of the current network community.

PrudenceSince web services rely heavily on standard network technologies, the SOA-WS community can heavily leverage the vulnerability and risk assessment tools currently used by the network industry.


Table 3: Strategic Design Framework

Strategic Domains General Issues

Proa

ctiv

e

Prudence

Transformation

Threat Anticipation

Migration

Accountability

Reac

tive

Detection

Containment Standard network best practices limit damage to localized areas.Mitigation

Assessment Web auditing tools allow assessment of the depth and breadth of penetration.Recovery Standard server backup strategies allow for rapid recovery.Accountability

Vulnerability/Risk Anticipation

Identification of pending changes in vulnerability and risk before occurrence is distributed to the various creators of web services instead of a centralized authority. Decentralization improves likelihood of identification.Web service security tools and standard network tools enable testing for vulnerabilities. Network best practices results in user passwords being changed frequently. If increased security is required, use of virtual private networks further limits access.Use of COTS tools leverages a vast user community to capture and disseminate vulnerabilities quickly.Network security best practices and use of COTS will update security as available, keeping the security as up to date as possible.Standard network monitors, security software and honey pots provide traps for potential perpetrators.Web service security framework provides for early detection of security penetration.

Web service security tools and standard network tools allow for testing of vulnerabilities to limit the depth of penetration.

Web auditing tools allow traceback of perpetrators to the points of penetration. Past that, external tools may provide for further forensic analysis.


Randell A. Wolfe

TransformationCurrent network security best practices equally apply to SOA-WS. As with standard networks, use of higher security measures like Virtual Private Networks will equally add security to the SOA-WS system.

Threat AnticipationLeveraging the network industries infrastructure allows for any threats identified there to be equally applied to the SOA-WS community.

MigrationAgain best practices play a huge role in keeping the security up to date. Using COTS security packages and keeping the software updated will help prevent any security issues.

AccountabilityA common method to “trap” hackers is to build a honey pot. The system security is intentionally left weak with an attractive system name and equally attractive fake content. The one thing not left weak is the auditing. Trip wires and automated reporting lets the administrator know when the system is being probed. This will allow the hacker to expose that they are in the system before they have penetrated a critical resource. Enhanced auditing of the network can then be used to identify the path of penetration and correct the problem.

ReactiveReactive issues are those in which the proactive issues failed to avoid a problem. The reactive issues document how the problem is addressed once it has become known.

DetectionCOTS security tools provide many mechanisms for detecting penetration. Honey pots, system security logs, network logs, etc are all important tools to detecting an intruder.

ContainmentNetwork best practices such as frequent password change, limiting user access to only necessary privileges, strong router configurations, etc will assure that when a penetration occurs the seriousness will be contained.

MitigationRedundancy of services and backups of critical data can mitigate any damage a penetration causes.



Randell A. Wolfe

AssessmentAuditing logs play an essential role in assessing how far the perpetrator was able to progress.

RecoveryDaily backups of key databases, database activity logs, and redundancy of web services will allow for quick recovery should damage happen.

AccountabilityThe primary goal of the auditing logs is to figure out how the hacker got in and what damage they have done. Inspection of the various logs allows the security administrator to perform these tasks.

Reality FactorsAny system must exist in a real world. All too frequently a system is designed and put in place without taking into account these reality factors. Table 6 contains a summary of the reality factors which must be addressed by any institution implementing web services.



Randell A. Wolfe

Human BehaviorA common problem in any institution where a level of creativity along with the accompanying pride in product is the dreaded “Not Invented Here Syndrome”. In twenty four years of software experience I have grown to believe that good software and pride in product go hand in hand. I have yet to see a developer who doesn't have pride in their software who also writes good code. So the good developers always have pride in their code almost always leading to an “I could do it better” attitude. A pilot friend of mine once made a statement that I have grown to apply to my software engineers. His statement was, “I wouldn't fly with any pilot who didn't think they were the best pilot in the world.” Likewise I want on my team a bunch of software engineers who think they are amongst the best programmers in the world. Yes this will likely lead to personality conflicts and passionate interchanges. But this can be managed by good managers. Quality cannot be managed into a bad


Table 4: Reality Factors

Reality FactorsHuman BehaviorNot Invented Here SyndromeRice Bowl IssuesInterface will do but isn't exactly what I wantI don't want to learn the added level of complexityThanks for letting me use yours but I don't want you using mineOrganizational Behavior Survival rules rule, nobody's in control...Big picture of cross department, business unit and business partner integrationAll the human behavior times an order of magnitudeTechnology Pace Accelerating vulnerability-introductions, sparse testing...

System Complexity Incomprehensible, highly networked, unintended consequences, emergence...As number of services grows, potential complexity will grow geometrically.Globalization Partners with different ethics, values, infrastructures...

Creeping Agile PracticesOver modularization of services can result in performance issues due to network latency.

Agile Adversaries Distributed, collaborative, self organizing, proactive...

As new standards or equipment is introduced individual departments, units or divisions can roll out on an as needed basis.Standards introduction is rapid at this point in time. The naturally distributed nature of SOA allows adoption to occur at the place it is most needed first with gradual roll out

As enterprises integrate with each other, security will be important to assure only data approved for exposure is in fact exposed.

Reliance on services managed by others can result in unintentional effects in changes to that service effecting your application.

If a large web service based enterprise has a choice of doing business with you as a non SOA company or a SOA based competitor you will lose.Your SOA based competitors will be able to conduct business internally and externally more efficiently, and will be able to adapt to change easier.


Randell A. Wolfe

product.

For a long period of time Information Technology (IT) departments have wielded the application power through limiting access. This limited access includes keeping people away from direct access to the business knowledge in the form of databases. With all application pieces now being available via the SOA it is possible for anyone to bring together large complex applications in short time. Some IT managers are likely to resent this loss of power in the form of “Stay out of my rice bowl”. This is a upper level management issue which would need to be solved.

Developers being the creative proud lot that they are don't like sloppiness in their code. When needing to interface to another application, in this case a web service, whose interface does not exactly match the structure they need they are forced to write glue code. Amongst those with too much time and budget, they will frequently just write their own version, frequently under the guise of improved performance. It is the System Engineers responsibility to monitor the software development and report when unnecessary expense is being consumed. However the organization must provide an environment in which the SEs have sufficient insight into the program to make such advice. This is rarely a problem in programs which use a strong form of Program Management, but is frequently a problem in matrix organizations.

Good developers have a natural thirst for knowledge. They will continuously learn on their own, because they realize that if they do not, in just a few years their knowledge will be obsolete. Unfortunately not all developers have this desire. There will be those who do not want to learn the added complexity of developing their applications as web services. Fortunately the various development tool vendors realize the benefit of supporting the web services realm and are doing everything possible to simplify web service development. Purchasing of these tools along with in house training will go a long way to bringing the developers who do not have the “eye of the tiger” up to speed on web service development.

There is a class of individuals in the computer business referred to by some as information hogs. They hoard information like life saving food, gaining power by only doling out information to those they want when they feel like it. In the development community they take the form of individuals who will supply their software to their users, but not to other developers. This is an issue which can be solved by use of System Architects, likely as an added role to Systems Engineering. The System Architect will be responsible for keeping up, with full management support, on every development effort advising when certain business logic planned for “inside the application” should be made into a service. The possibility of forcing the hoarder into a fixed Application Programming Interface (API), so that another team could actually develop the web service is a possibility. This step is necessary to avoid those information hogs who always say, “We can do that but it will cost way more than it is worth”. Rarely is this really the case, it is just another defense mechanism to prevent sharing of their sacred knowledge.

Organization BehaviorThe migration to SOA will only be of limited success until the full organization has full buy in. The view of a future where the full organization is integrated must be seen as important to the success of



Randell A. Wolfe

the company by everyone from the CEO to the individual developers. The ability to adapt to change delivered by this architecture must be effectively communicated. As soon as everyone realizes we are all in the same boat and either sink or swim together, many of the human issues will disappear.

However there is a down side that accents the importance of the organizational buy in. An organization is a large group of people. If an organization does not buy in, you can rest assured that the problems in the human section will be multiplied by at least the number of people in the organization.

Technology PaceBeing in the toddler age of web services, standards are evolving quickly along with new standards being introduced monthly. Fortunately SOA has a built in immune system. As new standards are introduced they can be introduced to the services on an as needed basis. New services can then use these standards. As old services reach old age and retire, old standards will die a natural death.

System ComplexityAs the number of services grow, the complexity of the entire system will grow geometrically due to the possible communication paths. The enterprise architect will have to monitor the growth and decide when partitioning of the individual services or even the UDDI makes since.

GlobalizationOne huge benefit of SOA-WS is the potential to have closer integration with customers and business partners. This close integration allows for more rapid and efficient response. There is however the danger of exposing proprietary information. Maybe a customer or business partner would like to have access to your cost information to improve their bargaining position. Web service and network security will be vital to preventing this from becoming a problem.

Creeping Agile PracticesWhen CORBA first came out, many in the telecommunications industry jumped on board seeing the potential of distributed objects. Far too many went about making all their object distributed and were immediately introduced to the concept of network latency. Direct calls to software functions are hundreds of times faster than network calls. This learning experience resulted in the concept of call granularity. If you want a customer record you do not say, give me his last name, give me his first name, give me his street, give me his address, give me his city, give me his state, give me his zip code. Instead you say give me his customer record. Network latency is paid for once not seven times. Over modularization of a SOA-WS will exhibit the exact same effect.

When relying on others for critical functionality risk is added to the program. This risk can be partially mitigated by assuring redundancy in service suppliers for critical functionality. Whether a hot spare, warm spare or replaceable part strategy is utilized becomes a business decision.


http://compnetworking.about.com/od/speedtweaks/l/aa021902a.htm


Randell A. Wolfe

Agile AdversariesCompetitors who adopt web services are more likely to adapt to change. In this world of continuously changing business relationships these competitors are also more likely to be picked as a partner or merger target. Integration of multiple businesses into a single enterprise, no matter the ownership dimension, using web services is much simpler than past technologies and provides for a larger return on investment (ROI).

Change ProficiencyA critical characteristic for any enterprise which seeks long term success is change proficiency. Without change proficiency an organization can be very successful for a short period of time, but as soon as the environment changes lack of mobility can result in a quick death. Dove identifies four axes in measuring change proficiency.

Time of ChangeWith SOA-WS time of change is more closely related to the scope of new additional effort. Reconfiguration aspects of change are easily handled by the changing of BPEL scripts. As the core service logic is not modified, there can be no ripple and unintended consequences at this level. Time of change is thus minimized. (Ranking 3 out of 4)

Cost of ChangeRelated to the issues raised in the Time of Change, the cost of change will be equally minimized due to less wasted effort. (Ranking 3 out of 4)

Quality of ChangeThe massive reuse of established components helps assure that quality will be constant. Use of good engineering practices in the development of new services will help maintain a high level of quality. (Ranking 3 out of 4)


Table 5: Change Metrics

Time Cost

Quality Scope

Inherent modular nature allows natural partitioning of the application into quickly constructed components.

Modularity allows for maximum reuse, minimizing cost.

Massive reuse of established services helps minimize impact on quality of change.

Scope is only limited to the developer resources available.


Randell A. Wolfe

Scope of ChangeAny scope of change will be possible. Good program management, systems engineering, and software development practices are required to assure increased scope does not result in failure. (Ranking 4 out of 4)

Activity DiagramThe activity diagram documents both the strategic themes of the system, but also the functional or tactical way those themes will be addressed. In the case of generic SOA-WS both subjects are pretty small and straight forward. The real versatility a “real” system, that is SOA-WS based, would reveal in this diagram would likely be much more complex. The simpleness of the generic SOA-WS does not reveal the true potential of either the Activity Diagram or the Closure Matrix. But if the reader looks closely, I am sure the benefit in measuring the design agility will be appreciated.


Illustration 3: Overall SOA Change Proficiency

Time

Cost

Quality

Scope0

2

4


Randell A. Wolfe

ModularWithout modularity, the loose coupling, adaptability, testability and most other abilities of an agile system will not be achieved. SOA-WS almost mandates a modular design, however good design practices must be followed. There are many books on these best practices. The author's favorite is Service-Oriented Architecture: Concepts, Technology & Design by Thomas Erl.

Service CreationOnce again best practices play an important role. These best practices must be applied throughout the design, development and testing of the services.


Illustration 4: Activity Diagram


Strategic Themes/Values

Functional Activities

Key

Modular

ServiceCreation

BusinessOriented

Scalable

ApplicationCreation

Industry Standards

Mirror Business

Needs

Full Life Cycle Support

http://www.amazon.com/Service-Oriented-Architecture-SOA-Technology-Computing/dp/0131858580/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1212888341&sr=8-2


Randell A. Wolfe

Application CreationProper use of the various layering technologies (BPEL) is critical to a good SOA. Chatty interactions between services must be avoided. To accomplish this, proper granularity of the service interfaces is critical.

ScalableThe use of web server technologies provides a naturally scalable environment. Network load measuring tools combined with server load tools can be leveraged to determine how many additional servers are needed and how many copies of web services need to be made.

Application CreationApplications must remain stateless to support scalability. As soon as an application maintains state in the application as opposed to the SOAP message, the server with the particular instance of the application becomes the only place a chain of services can complete. This can greatly reduce the effectiveness of load balancing and thus the scalability of the application.

Industry StandardsThe use of industry standards aids the scalability by allowing the use of COTS tools for load balancing. As better and better COTS load balancers become available, they can easily be brought into a SOA-WS system to replace the existing load balancer. This concept applies to all levels of COTS services, not simply the load balancer.

Mirror Business NeedsAs previously discussed, good OOA/D principles should be followed. The effect on scalability is provided by the likelihood that a particular business need will be where the scaling is required. If the services mirror these business needs, breaking of a service to scale a part, or unnecessary scaling of a particular part can be avoided.

Business OrientedAll SOA-WS systems should be business oriented.

Mirrors Business Needs Your business may be accounting or putting weapons on target. Whatever your business, someone looking at any service in you UDDI should easily see how it fits into your business.

Full Life Cycle SupportIn most circles a perfect application with a short life span is no longer acceptable. The environment



Randell A. Wolfe

must support all phases from concept to retirement. The modular and easily changeable nature of SOA-WS provides this support.

Closure MatrixThe closure matrix shows how all the design items previously discussed interact with metrics also previously discussed to measure the agility of the system. In the case of SOA every RRS principle is covered by one or more design issues. In addition, each activity is covered by one or more design issue. The straight forward, simple and concise nature of the SOA concept provides for a fairly simple design issues list with expansion of the issue description being unnecessary. In more complex issues lists, it is common practice for there to be a section for each tuple of Activity/Issue/RRS principle describing the relationship. The author feels this would be redundant.



Randell A. Wolfe


ActivitiesRRS Principles

Reusable Reconfigurable ScalableService Creation 1

Sel

f Con

tain

ed U

nits

Plu

g C

ompa

tibili

ty

Fac

ilita

ted

Re-

Use

Fla

t Int

erac

tion

Def

erre

d C

omm

itmen

t

Dis

trib

uted

Con

trol

& In

fo

Sel

f Org

aniz

ing

Ela

stic

Cap

acity

Uni

t Red

unda

ncy

Evo

lvin

g St

anda

rds

Application Creation 2Use Industry Standards 3Services Mirror Business Needs 4Full life cycle support 5

Issues Principle-Based Activities and Issues Served

Proa

ctiv

e

CreationNew services are independently developed. 1 1 1New applications can be created from existing services. 2 2New tight associations with business partners can created. 4 4New services utilize industry standard interfaces. 3 3Multiple implementations requiring different execution resources can be created. 2,4 4 2 2Improvem entNon monolithic applications improves ability to adapt to changing requirements. 2,4 2 4Multiple instances of a service can be made available to improve performance. 4 4 4Migration

3,5 3 5

3,5 5 3 3Modification

4,5 4,5

Rea

ctiv

e

CorrectionShould defects be detected in procedure, it only needs correction in one place. 5 5ValidationUse of common services helps assure consistent policy and results. 3 3ExpansionNew servers to host services can be easily added. 5 5

5 5

4 4ReconfigurationDistribution of services to servers is easily changed. 4 4Applications can decide at runtime whose implementation of a service will be used. 2 2 2Use of industry standard interfaces facilitates reconfiguration. 3 3

As robust corporate services become available, use of BPEL simplifies migration to new service.As new standards become available, they can be brought on line for parallel use with the old standard, allowing migration on an as needed basis.

As robust corporate services become available, existing services can be easily modified to utilize the new service.

Business process can be expanded across departments, to units, to divisions, to enterprises.Individual departments and/or units and/or divisions and/or enterprise decide where to focus for new functionality.


Randell A. Wolfe

ConclusionService oriented architectures delivered via web services can be very agile, however using this technology does not guarantee agility. A systemic view must be taken and include the people, processes, policies and culture of the organization. For SOA-WS this will be the most difficult part. An agile system requires an agile organization usually loosely structured, however in any creative endeavor there will be egos involved. The only way to address the ego issue is through strong intelligent management. However this can easily go against the loose structure required of an agile organization. Ranking SOA-WS against Doves definition of agility provides the following observations:Collaborative Learning Environment: The easy accessibility of the available services via the UDDI allow architects and software engineers to easily identify what is available and how to use it. Making read only copies of all source code available throughout the organization would also greatly aid in achieving a collaborative learning environment. (Ranking 10 out of 10)Knowledge Portfolio Management: The fully published nature of SOA-WS guarantees that all knowledge within the company is available. (Ranking 10 out of 10)Reusable/Reconfigurable/Scalable Structured Relationships: One of the primary tenets of SOA is to meet all these needs. SOA-WS fulfills these requirements. (Ranking 10 out of 10)Change Proficiency: Although the modular nature encouraged by SOA-WS leads one towards an architecture which has change proficiency, many things can get in the way. Incorrect granularity of services, services which do not model the business, people management problems, etc. (Ranking 7 out of 10)Value Based Decision Making: Decision making local to the services will tend towards being value based. As to whether the organizational decisions are equally value based is, once again, a management issue. (Ranking 8 out of 10)

Knowledge Management: Knowledge Portfolio Management + Collaborative Learning Environment (Ranking 20 out of 20)Response Ability: Change Proficiency + Reusable/Reconfigurable/Scalable Structured Relationships (Ranking 17 out of 20)

Agility: Knowledge Management + Response Ability + Value Based Decision Making (Ranking 45 out of 50)Assuming the management issues can be addressed I would rate SOA as an agile system.



Randell A. Wolfe

ReferencesAll references are implemented as hyper links providing for easier access to the referenced materials at the point of reference.


Illustration 5: Response Proficiency Space

OpportunisticAgile

FragileInnovative

Proactive (Leadership)

Rea

ctiv

e (V

iabi

lity)

(SOA)


Randell A. Wolfe

Appendix A


Service Oriented ArchitectureAvoiding Speed Bumps on the Road to an Agile EnterpriseMetaphor Story

By Randell A. Wolfe, L-3 communications Integrated Systems, Greenville Texas

The mission seemed simple enough: use a helicopter insertion onto the 15,000 ft ridge overlooking the valley below. The Navy Seal team's mission was to call in any activity seen in the surrounding valleys. As the lumbering Army MH-47E Chinook helicopter headed towards the landing zone (LZ in military lingo) the Seal team leader worried again about the use of such a large, loud and slow delivery system. Unfortunately the altitude precluded the use of the quieter and nimbler UH-60 Black hawk, and there aren't enough V-22 Ospreys to go around. His thoughts then shifted to the mindset shared with his SPECOP brethren, use what you got. As the helicopter flared, slowly, for the LZ the Seal leader chuckled at the team motto, “The quick or the dead”. As the Chinook touched down and the barn sized rear door opened, his team hurried out. No more than three of his team had touched the dirt when dozens of 14.5 mm bullets from a Russian KPV anti aircraft gun ripped through the cockpit of the helicopter disabling the pilot and co-pilot instantly. Not again, thought the team leader. He flashed back to a similar episode on a similar mountaintop named Takur Ghar just a few years before. That episode had lead to a 15 hour ordeal and loss of 7 of his team members. As before, the helicopter had landed within a hundred and fifty yards of a well camouflaged machine gun nest. As the team took up defensive positions, the leader pulled out his tactical radio. He called to a team member requesting range and bearing. The team member pulled a hand held device from his backpack, aimed the optics at the bunker and pushed a button, quickly dropping his head back below a much too small rock. He called out to his

lead, one five niner at one hundred twenty four yards. The team leader entered the pinned down code as well the range and bearing into the radio and pressed send. The digital message, along with the units GPS position was immediately sent over the satellite link to the Department of Defense Integrated Military Services System. A Seal Team Application Web Service (STAWS) immediately picked up the radio packet and translated it to an XML SOAP message, passing the request to a Business Process Execution Language (BPEL) Pinned Down Orchestration Script (PDOS). The PDOS script passes the SOAP request message to a Locate Assistance Web Service (LAWS). The LAWS pulls the relevant information from the XML and inspects the Seal Universal Description, Discovery and Integration (UDDI) registry to see if there is a Web Service Definition Language (WSDL) description for any nearby Seal Teams to assist. In milliseconds, the lack of an entry in the UDDI, causes the exception processing of the PDOS script to promote the request to the long running Inter Service Assistance Choreography Script (ISACS). The ISACS script attaches a 30 minute time constraint on the XML message and immediately fans the XML request out to the Army, Air Force, Navy, Marine, Coast Guard and Allies Immediate Assistance Web Services (IAWS). Each of the IAWS in parallel query their own UDDI registries for units which meet the time and ordinance kill radius constraints. The ISACS gathers the resulting responses. The Marines have two F-18 Hornets in the area, but their GBU-32 Joint Direct Attack Munition (JDAM) would place the seal team dangerously close to the kill radius. The Army provides an empty response indicating they have no one within reach in the alloted time. The Navy's ships are too far from the area of engagement so they too respond indicating no joy. The Air Force however has a F-22 Raptor, 5 minutes away at super cruise carrying the Adjustable Yield Munition (AYM). The ISACS script makes the decision issuing a request back to the Air Force IAWS asking for redirection of the F-22 to the specified location. The IAWS checks its built in priorities and determines the F-22s current mission can be handled by another aircraft. The IAWS locates the F-22s Command Web Service (CWS), attaches the orders to the XML message and sends the request. The CWS picks up the message and issues an encrypted message to the F-22 redirecting it to the latitude and longitude of the bunker. Not only do the new commands with a situational update appear on the F-22 pilot's display, but the computers on board automatically command

Metaphor Story

http://www.abovetopsecret.com/pages/futureweapons.html

http://www.abovetopsecret.com/pages/futureweapons.html

http://en.wikipedia.org/wiki/Supercruise

http://en.wikipedia.org/wiki/F-22_Raptor

http://www.fas.org/man/dod-101/sys/smart/jdam.htm

http://www.fas.org/man/dod-101/sys/smart/jdam.htm

http://en.wikipedia.org/wiki/F-18

http://en.wikipedia.org/wiki/Web_Service_Choreography

http://en.wikipedia.org/wiki/Web_Services_Description_Language

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration

http://www.serviceoriented.org/web_service_orchestration.html

http://en.wikipedia.org/wiki/BPEL

http://en.wikipedia.org/wiki/BPEL

http://en.wikipedia.org/wiki/SOAP

http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/Web_services

http://en.wikipedia.org/wiki/Operation_Anaconda#Battle_of_Takur_Ghar

http://www.liveleak.com/view?i=b46_1182424422&c=1

http://marinetilldeath.multiply.com/journal/item/98

http://marinetilldeath.multiply.com/journal/item/98

http://en.wikipedia.org/wiki/United_States_Special_Operations_Command

http://en.wikipedia.org/wiki/V-22_Osprey

http://en.wikipedia.org/wiki/UH-60_Black_Hawk

http://en.wikipedia.org/wiki/MH-47E_Chinook#MH-47

http://en.wikipedia.org/wiki/United_States_Navy_SEALs

the AYM to an appropriate yield to devastate the bunker while leaving the Seal team safe. The pilot immediately goes into super cruise and heads for the target. The IAWS identifies an aircraft on a target of opportunity mission, 20 minutes further away than the original F-22. The IAWS locates the aircraft's CWS, builds and sends the command to reroute to the original target of the F-22. The area patrol aircraft immediately kicks into super cruise and heads for his new target.Once the ISACS receives notification from the IAWS that there will be bombs on target in 5 minutes, it passes the notification to the STAWS which broadcasts the message to the Seal team leader's radio. The commander sees the message and despite the dire circumstance smiles. A nearby Seal member sees this and queries, “What's so funny?”. To which the reply comes, “What a difference this net-centric BS makes. Heads down in 4 minutes guys. Pass it along”. The team leader could hardly believe, he had barely taken his finger off the send key, when the reply message notifying them of their saviors arrival in 5 minutes was received.The IAWS's job not yet complete, uses the UDDI to locate another MH-47E, 45 minutes out. The orders are built and sent to their CWS, indicating to load up an exfiltration team and medic to head to the mountain top. IAWS also locates and reroutes two F-16 Fighting Falcons and a Predator B to the mountain top should any more bad guys lift their heads out of the surrounding caves.The Seal team lead yells, “heads down” and everybody ducks. Within 20 seconds the bunker explodes into shrapnel and the 5 minutes of 14.5 millimeter fire the team had been hearing is silenced. Ten minutes later the two F-16s can be seen circling over head. They spot and take out two mortar teams as they are trying to set up. The Predator arrives another 5 minutes later, providing real-time video back to command headquarters through the Predators Publish and Scribe Video Link Web Service (PSVWS). Twenty five minutes later the MH-47E helicopter arrives with the medics who are able to stabilize the pilot and co-pilot, placing them on the helicopter. The medics ruggedized laptop forwards the patients' status to the bases Inbound Patient Web Service (IPWS). Once in route home the medics treat what the Seal members refer to as nicks and scratches. After all none of them required more than 10 stitches.The demonstrated level of agility, cooperation and integration could only have been achieved through

careful use of standards. In the current SOA world, realized through Web Services, there is no shortage of standards. So the question becomes, what is all the alphabet soup the various SOA vendors are throwing around? Do you need them? Should you use them? Further complicating the problem is the fact that, unlike the web, there is no single standards body - there are in fact two main recognized bodies. You would expect that the main standards body for the world wide web, the World Wide Web Consortium (W3C), would be a major player, and you'd be right. However the W3C is a very formal and structured organization which can take unacceptably long periods of time to formalize a standard. This is simply not compatible with the rapidly evolving world of web services. Agility in the marketplace has been demonstrated by the appearance of a standards competitor, the Organization for the Advancement of Structured Information Standards (OASIS). Besides these two organizations, but to a lesser degree, individual companies in the web services market are creating their own, sometimes competing (Microsoft), standards. What role should these standards play in your SOA?

Fortunately the answers to all these questions is available in three simple letters; WS-I. The Web Service Interoperability Organization was created “to establish Best Practices for Web services interoperability, for selected groups of Web services standards, across platforms, operating systems and programming languages”.

Every major and most minor participants in the Web Services community are members of the WS-I organization. Their goal is to make sure implementers know which standards have wide enough support to prevent vendor lock-in. Through the organizations published Basic Profile, anyone can see which standards the community feels is ready for prime time. When developing a web service, standards in the Basic Profile should be the first choice. If what the developer needs is not there, the draft Basic Profiles should be examined. Past that the various forums, in order, WS-I, OASIS, W3C should be examined. Finally the standards developed by smaller organizations and individual companies can be leveraged but should be kept separated for easy replacement.

http://www.WS-I.org/



http://www.w3c.org/

http://www.w3c.org/

http://www.inert-ord.net/russ02i/mort_at/R5082.html

http://www.ga-asi.com/products/predator_b.php



SDOE – 645 Service Oriented Architecture 34 of 35 Avoiding Speed Bumps on the Road to an Agile Enterprise

Randell A. Wolfe


Response Able System Principles – RRS

ReconfigurableSc

alab

leR

eusable

Self-Contained Units (Encapsulated Modules)Services are distinct, separable, loosely-coupled, self-sufficient units cooperating toward a shared common purpose. The purpose can be different depending on whether working at the application, business or enterprise level.Plug Compatibility (Facilitated Interfacing)Services share defined interaction and interface standards through the SOAP messaging standard; and are easily inserted or removed by placing their WSDL definition in the UDDI.Facilitated ReuseWS-I Services are reusable and replicable being defined to handle common coding patterns. Application services are reusable and replicable being defined to handle application specific tasks.

Evolving Standards (Infrastructure/Framework)The SOAP and WS-I standards formalize inter-service communication and interaction; define service compatibility; common WSDL allows old, current, and new services to be used simultaneously.Redundancy and DiversityDuplicate services and load balancing provide capacity right-sizing options and fail-soft tolerance; diversity among different vendor WS-I implementations can be exploited.

Elastic Capacity (Scalable)Service populations in response able systems may be increased and decreased widely within the existing framework through load balancing services.

Flat Interaction (Peer-Peer, Non-Hierarchical)WSDL in the UDDI combined with real time service location allowspeer-to-peer relationships; and parallel relationships. Sequential relationships are supported when needed.

Deferred CommitmentService relationships are transient, only existing as long as the business process exists. Decisions and fixed bindings are postponed until immediately necessary through UDDI lookup; This also binds relationships in real-time.

Distributed Control and Information (Decentralized)Services are directed by business need rather than method; decisions are made at point of maximum knowledge; information is associated locally, accessible globally, and freely disseminated through the SOAP message aggregation.Self-OrganizationService relationships are self-determined by business process need; and service interaction is self-adjusting or negotiated as determined by higher-order business logic.

SDOE – 645 Service Oriented Architecture 35 of 35 Avoiding Speed Bumps on the Road to an Agile Enterprise

Randell A. Wolfe



TimeTime


System assembly:

Component mix:



System assembly:

Component mix:


Business FocusedApplication Focused Enterprise Focused

application entityservices

orchestrationservices

WS-Iservices

choreographyservices

UDDI WSDL

Drag & Drop Modules

Plug & Play Standards

Active

Infrastructure

Passive





IntegrityManagement

Various Developers

UDDI

WSO - BPEL

WSO-I.org

sdoe – 678 engineering of agile systems and enterprises ... · sdoe – 678 service oriented...

Documents