|
|
|
||||||||||||||||
|
|
|||||||||||||||||
May 1 2003 by Ash Parikh, Rajesh Pradhan
"Most organizations are moving toward methods and tools involving the Unified Modeling Language (UML) for defining service needs."
- The Evolving Web Services Architecture, Gartner Research
Augmented Web services are the next generation process aware services that enable meaningful end-to-end interactions in an application agnostic ecosystem. These Web services represent evolving open standards initiatives driven by standards bodies such as OASIS, W3C, JCP, etc.
According to Dr. Bhuvan Unhelkar, an acclaimed expert on software modeling, "modeling serves the dual purpose of understanding the complex reality and is a creative cause for a new reality." To simplify this concept, models create an abstraction of the complex reality, thereby making it easier to understand that reality.
In reality, we see Web services as true software components or artifacts that lend themselves well to modeling techniques. This article aims to introduce the reader to a whole new discipline of modeling, called modeling augmented Web services.
As we know, Web services are a specification for service invocation that includes a standard transport mechanism such as HTTP as the transport type, and a hybrid version of XML called SOAP.
Web services have since evolved from mere static services to more meaningful business process interactions involving long running transactions and collaborations between the various stakeholders of the business process.
The Web services space presents a nascent landscape, not only in terms of adoption, but also the emerging standards. So much so, that there exist a wide variety of semantic interpretations of various concepts. Ergo, a little digression to the conceptual world would not be out of order.
To take a simplistic view of a business process, a business process can be described as a sequence of tasks and the schematics on how stakeholders take on roles, relationships and responsibilities. Business collaborations or the public or viewable business processes can be defined as models expressed in XML. The interaction between roles takes place as a choreographed set of business transactions. A business transaction can be thought of as an atomic unit of work and cannot be decomposed into lower-level business transactions. Each business transaction is then expressed as an exchange of electronic business documents, i.e. one or two predefined business document flows.
To effectively represent a business process, we must first define a model for the business process and the interactions between the various stakeholders such as customers, partners and internal entities. Next, we must define the various tasks that occur within the business process accurately, paying close attention to the order and the time for completion.
It is now a good point in our discussion to understand the subtle difference between an executable business process and an abstract business process. An executable business process is a process in which we model the actual behavior of each participant in the business process, whereas an
abstract business process is one in which the process descriptions specify the mutually visible or observable message exchange behavior of the parties involved in the business process without revealing the internal behavior.
It would be also useful to understand the difference between orchestration and choreography of a business process, before we proceed further. The term orchestration describes how Web services interact with each other at the message level, including the business logic and execution order of the interactions. It is an executable process that may interact with both internal and external Web services. The term choreography, however, tracks the sequence of messages that may involve multiple parties and multiple sources, including customers, partners and suppliers. It is a collaborative process in which each party involved in the process describes the part they play in the interaction.
Recently, these paradigms have somewhat converged.
The Object Management Group (OMG) has standardized on the Unified Modeling Language (UML) as its de facto modeling language. UML has undergone many revisions (currently minor revision 1.5 and major revision 2.0 are in the works, although most tools are still at version 1.3). This article assumes UML 1.4 as the basis for further discussion.
UML is a graphical language for
specifying,
visualizing,
constructing, and
documenting
the artifacts of software systems [UML 1.4 Specification, OMG].
On account of its wide acceptance and capabilities, UML is the natural choice for any modeling activities.
A Profile is a stereotyped package that contains model elements that have been customized for a specific domain or purpose by extending the metamodel using Stereotypes, Tagged Vaues, and Constraints. A Profile may specify model libraries on which it depends and the metamodel subset that it extends.
A Profile is comprised of
1 Stereotype:
A Stereotype is a model element that defines additional values (based on Tag Definitions), additional Constraints, and optionally a new graphical representation. All model elements that are branded by one or more particular Stereotypes receive these values and Constraints in addition to the attributes, associations, and super classes that the element has in the standard UML. Stereotypes augment the classification mechanism based on the built in UML metamodel class hierarchy.
2 Constraints:
Constraints can also be attached to any model element to refine its semantics. Constraints attached to a Stereotype must be observed by all model elements branded by that Stereotype. If the rules are specified formally in a Profile (for example, by using the Object Constraints Language (OCL) for the expression of Constraints), then a modeling tool may be able to interpret the rules and aid the modeler in enforcing them when applying the Profile.
3 Tagged Values:
Tag Definitions specify new kinds of properties that may be attached to model elements. The actual properties of individual model elements are specified using Tagged Values. These may either be simple data type values or references to other model elements. Tag Definitions can be compared to meta attribute definitions while Tagged Values correspond to values attached to model elements. They may be used to represent properties such as management information (author, due date, status), code generation information (optimizationLevel, containerClass).
Having taken a detour to examine the key concepts, we would like to acquaint the reader with the two Web services Profiles that we have defined. These Profiles are based on functionality and the direction that industry leaders such as IBM, Sun Microsystems, BEA Systems, etc., and the various standards bodies such as OASIS, OMG, W3C, WS-I, have been taking of late.
As shown in Figure 1, the Profiles are:
The Basic Profile
The Process Profile
The Basic Profile corresponds to static Web services described by the over hyped triplet comprising of the Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) and the Universal Description and Discovery interface (UDDI).
We have found that in practice, UDDI utilizations have been sparse and SOAP modeling has limited appeal (on account of issues related to accessing and deploying to SOAP engines). Therefore, the dominant artifact in this Profile tends to be the WSDL and for the sake of brevity, we have limited the discussion to the WSDL in this article.
WSDL is essentially a XML language that contains information about the interface, semantics and administration of a call to a Web service.
The WSDL standard is defined by the W3C (World Wide Web Consortium). The W3C further defines WSDL as "an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate."
The Process Profile represents the augmented Web services interfaces. These augmented interfaces are governed by the emerging standards such as Business Process Execution Language for Web Services (BPEL4WS) and the ebXML Business Process Specification Schema (ebBPSS) from OASIS and the Web Services Choreography interface (WSCI) from W3C.
BPEL4WS is a notation for specifying business process behavior based on Web services. Processes in BPEL4WS export and import functionality by using Web services interfaces. With BPEL4WS, we can models the behavior of both executable and abstract business processes, as described earlier, and have a language for the formal specification of business interaction protocols. It also extends the Web services interaction model and enables it to support business transactions.
ebBPSS provides a standard framework for business process specification. It works with the ebXML Collaboration Protocol Profile (CPP) and Collaboration Protocol Agreement (CPA) specifications to bridge the gap between Business Process Modeling and the configuration of ebXML compliant e-commerce software, e.g. an ebXML Business Service Interface.
WSCI is a choreography standard that was initially defined by Sun Microsystems, Intalio and BEA. It is now a W3C
submission undergoing extensive reengineering and review
This article details only the Basic Profile. Subsequent articles will detail the Process Profile and some of the latest developments in this space.
The Basic Profile comprises of stereotypes, constraints and tagged values that allow modeling of all WSDL definitions.
WSDLs are the neglected denizens of the Web services world. Created almost mindlessly by the automatons (more glamorously known as Web Services Toolkits), they simply reflect the vagaries of the native interfaces they represent. Ironically summarized, "WSDL is the IDL that isn't" - simply because no one wants to use WSDL as a starting point!
It takes no feat of deduction to conclude that the authors of this specification had no intention to make the IDL a bedside read - and understandably so, as this solves functional issues rather than worry about the aesthetics. The bottom line is that WSDL is not for the faint hearted.
Consequently, modern Web services tools do not expect developers to write WSDL definitions. Instead, these kits treat WSDL as a second-class citizen. They generate WSDL definitions from existing server-side source code, e.g., a Java class, based on whatever custom language mapping.
The WSDL represents the contract between you and the user of your service. Not unlike the real world, the contract needs to be well crafted for all sorts of reasons. The foremost being to ensure that there is no lawsuit down the road for purported misrepresentation. Ergo, the contract needs to spell out in the clearest possible terms what the service offers (ideally, also what it does not do!).
The Web service contract also needs to be well crafted. It should convey the value clearly and do so in standard vocabulary (if any).
The current approach of simply exposing business components defers the responsibility of conveying semantics to the business component interfaces.
These interfaces may not be designed for these new requirements and may require versioning of components to service internal and external needs. This approach pains most Deployment and Support folk, as it requires a change to extant production resources! Also, internal interfaces usually require reengineering before they can be deployed for external collaborations.
Externalizing internal interfaces without careful thought may end up being akin to washing one's dirty laundry in public!
Moving onto technicalities, not all Web services toolkits support the same WSDL message binding options. Currently, most Java toolkits default to RPC/Encoded bindings, whilst .NET toolkits default to Document/Literal bindings. The WS-I Working Draft now occludes the usage of RPC/Encoded but does not preclude usage of the RPC/Literal. Some toolkits support the use of types that were derived by restriction, while others do not. Some support overloading the required SOAPAction header or element namespace affiliations on a per-operation basis, others do not.
Therefore, interoperability is difficult or impossible to enforce if developers:
Do not understand WSDL
Do not know what WSDL definitions their toolkits will generate from their server-side native interfaces by default
Do not know how to customize their toolkits' behavior
In fact, six out of ten developers are still unclear about the concrete parts of messages, bindings and transport sections of the WSDL specification.
Many toolkits generate the WSDL on the fly. The biggest assumption here is that you'll start development by writing a server, which you'll then expose as a web service. What if you want to start by writing a client? In the classic RPC model, once an interface was defined in IDL, developers could write clients and servers independently. For instance, CORBA was often used to wrap legacy data sources on heterogeneous platforms. Once an interface was defined in CORBA IDL, a client could be developed at the same time the servers were being written. When the client was done, it could use the same client-side proxy code to call objects in different servers: all it needed was the right object reference.
The abstraction and delayed creation of the WSDL mandates the need for more complicated Web services frameworks like BPEL4WS, WSCI and ebXML.
Now that the Grim Reaper hath created a storm in the WSDL teacup, it is time for us to examine the ways of riding this storm. The foremost question that pops up is "Is WSDL itself flawed?" The answer, in all fairness, is "Not really". The WSDL specification is designed to be functional. It is designed such that automatons manufacture it and it endeavors to be deterministic and machine-readable. The authors of this specification have made no claims about its human readability or the ease with which it can be crafted manually. So, if WSDL is not the major issue, then what is?
The issue lies in the methodology for WSDL creation.
WSDL is an Interface Definition Language (IDL). It needs to be the starting point in the Web Services Lifecycle. Ergo, it needs to be well crafted, designed and implemented. It needs the same respect as the other artifacts within the software system. Knowing the sex appeal of the extant WSDL format, there needs to be some means of making this activity more palatable.
The newer set of WSDL toolkits (e.g. JAX-RPC 1.0), have taken cognizance of this fact. JAX -RPC allows creation of the Java interfaces from extant WSDL - the first step towards an Interface Centric design.
However, creating a WSDL from scratch does not go down well with most developers - and rightly so!
The OMG has standardized on the Unified Modeling Language (UML) as its de facto modeling language, as part of its Model Driven Architecture (MDA) methodology). UML has undergone many revisions (currently minor version 1.5 and major revision 2.0 are in the works, although most tools are still at version 1.3).
UML is a graphical language for
specifying,
visualizing,
constructing, and
documenting
the artifacts of software systems.
On account of its wide acceptance and capabilities, UML is the natural choice for any modeling activities.
WSDL modeling in UML is easier than conjuring up the XML representation from scratch.
Deriving from the MDA methodology, the modelling of the WSDL can be divided into 2 phases:
Platform Independent Phase:
This view represents the abstract portion of the WSDL. This includes:
Definitions
Service
PortType(s)
Messages
Parts
PartType(s)
Platform Specific Model:
This phase completes the bindings section of the WSDL. The elements modelled here include:
Service
Ports
Binding(s)
The advantage of these phases is the ability to abstract and focus on relevant issues in each phase. The PIM phases require interactive modelling whilst most of the PSM entities can be auto generated once the deployment platforms are defined.
This 2-phased modelling approach is implemented by Iopsis iNsight (covered later in this article)
The UML diagrams required to define the two WSDL partitions are as follows:
|
Platform Independent View |
Class View, |
|
Platform Specific View |
Class View, Deployment View, Component View |
A non-exhaustive list of WSDL stereotypes for both phases is included below in Figure 2. No specific icons have been associated with any of the stereotypes here.
Figure 2: WSDL Stereotypes
Constraints
The constraints for the WSDL Profile are based primarily on the WSDL specification. These have can be augmented to ensure WS-I Basic Profile conformance as per the Working Draft available.
A few examples of the possible constraints are included below. For a complete list of constraints, please refer to the Iopsis iNsight 2.1 documentation that will be available after Java One 2003.
A case in point is the 'No encoding rule' (the Working Draft mandates the use of Doc/Literal or RPC/Literal). This constraint expressed in OCL is as follows:
context bndgSOAP : SOAPBinding inv:
bndgSOAP.encoding = "Literal"
Tagged Values
The PSM entities require some knowledge of the underlying environment. This includes the SOAP Engine and component container e.g. J2EE or .NET. Consequently a couple of Tag Definitions that makes sense are probably SOAPEngine and Container. The Tagged Values for these could be JAXRPC, Axis etc. and the Container could be J2EE and .NET.
A detailed list of tag values will be available in the Iopsis iNsight 2.1 documentation.
Some of the key issues that an efficient Web services modeling tool needs to take into account and address are:
We have categorized existing Web Services tools on the basis of the following criteria:
|
Description |
Symbol |
|
UML support |
|
|
WSDL definition support |
|
|
General modeling support (Ties, stubs, realization components, etc.) |
|
Conformance to each criterion is depicted with the corresponding symbol adjacent to the product name.
The information we have furnished on the various tools available has been derived from websites and whitepapers for the same.
BEA's commitment to open standards for the benefit of customers and the Java community is unparalleled, and this continues with the introduction of the BEA WebLogic Workshop. Web services built with WebLogic Workshop are J2EE applications, as is the WebLogic Workshop runtime framework itself. BEA WebLogic Workshop fully supports Web Service standards such as SOAP, WSDL, and UDDI, and developers can quickly build applications that provide full interoperability with Web services deployed on other platforms.
The authors opine that BEA WebLogic Workshop 8.1 currently does not support UML based modeling of Web services. It has its own proprietary notation for modeling.
More information on BEA WebLogic Workshop can be found athttp://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/workshop/.
Oracle 9i JDeveloper allows you to develop Enterprise Java Beans and Web services visually in a UML Class Diagram, visualize session, entity and message beans, and the classes and interfaces implementing them, enables end-to-end development from database to client, driven from a UML Class Diagram, maintain synchronization between EJB model, java code and deployment descriptor, visualize Web services and generate the WSDL and java classes implementing them and enables publishing, running and accessing Web services directly from a UML Class Diagram.
More information on Oracle9i JDeveloper can be found at http://www.oracle.com/ip/develop/ids/index.html?designer.html.
IBM WebSphere Studio Application Developer - the core development environment from IBM - helps you to optimize and simplify Java 2 Enterprise Edition (J2EE) and Web services development by offering best practices, templates, code generation, and the most comprehensive development environment in its class.
WSAD is IBM's flagship IDE that has basic web services support. With the acquisition of Rational, the next rev of WSAD will have extensive UML modeling support. Support for WSDL modeling is still not present.
More information on IBM WebSphere Studio Application Developer can be found at http://www-3.ibm.com/software/awdtools/studioappdev/.
Borland Delphi Studio enables the rapid creation and deployment of Web Services, with full support for SOAP, XML, WSDL and UDDI. Delphi Studio is a complete design-to-deploy e-business solution for businesses looking for reliability and scalability in their enterprise and Web
Services applications.
Borland C++Builder integrates Web Services support into a full-featured and flexible C++ Rapid Application Development (RAD) environment with native support for SOAP data types and additional Web Services support.
Both development solutions support Web Services-based vendor platforms such as Microsoft .NET and BizTalk and Sun ONE - while also providing the scalability and reliability required by enterprise and Web application developers.
The Borland Web Services Kit for Java provides support to deploy and consume Web Services with the Java language and Borland JBuilder. The kit handles the SOAP, UDDI, and WSDL implementations so that developers can concentrate on Java development.
The kit includes wizards to generate Java code from WSDL and to generate WSDL from Java code, a Web Services Explorer to publish and search for Web Services, and deployment support to expose Web Services using Tomcat and the Apache Axis implementation of the SOAP standard. The Borland Web Services Kit is fully integrated with the J2EE™ platform and is capable of automatically publishing Enterprise JavaBeans™ as Web Services.
More information on Borland's Web services offerings can be found at http://www.borland.com/webservices/.
Codagen's patent-pending technology integrates seamlessly with leading UML tools to provide you with fully customizable code generation. Their solutions revolutionize application development and integration by enabling development teams to transform UML models directly into working software code or business processes. Codagen's tools also allow you to adopt a Model Driven Architecture™ approach so that you can focus on the code that is specific to your business and allow it to evolve independently from your technology infrastructure. Codagen works with UML profiles for EJB, XSDL, web services, and e-business solutions. The Codagen family of tools utilizes standards such as ebXML, BPSS, BPML, WSFL, WSDL, and BizTalk XLANG. Their products generate source code in Java, C#, VB, C++, and XML-based languages.
More information on Codagen can be found at http://www.codagen.com/products/biztalk/.
""Iopsis's iNsight 2.1 is an ideal complement to Sun™ ONE Studio 4 update 1, Enterprise Edition for Java. iNsight with Sun™ ONE Studio 4, provides a complete platform for businesses to rapidly develop enterprise class applications, right from developing Java™ 2 Platform, Enterprise Edition (J2EE™platform) based service components, to exposing those as webservices and consuming them. This combination provides one of the most comprehensive set of development tools for Web Services creation, modelling and consumption, found in the market today." - Ashwin Rao, Sr. Product Manager, Sun™ ONE Studio 4.
Iopsis iNsight 2.1 is a suite of extensions to standard Java IDEs, such as Sun ONE Studio 4 update 1, Enterprise Edition for Java, that helps users visually model, create and, deploy basic and process aware Web Services. Iopsis iNsight 2.1 supports WSCI 1.0 and BPEL4WS 1.0 based web services choreography and supports UML based modeling of the standard web services based on the WS-I Basic Profile.
In addition, the Process Pack also supports the ebMSH 2.0 compliant messaging platforms for web services deployments.
Iopsis iNsight™ 2.1 has support for all the three Web services profiles as depicted earlier in Figure 1.
As shown in Figure 3 (below), the relevant augmented Web services modeling features of Iopsis iNsight 2.1 include UML 1.5 based modeling support, Roundtrip engineering as an automated combination of reverse and forward engineering for WSDL 1.1 and In-place editing, all of which is provided as an extension to the Sun ONE Stuido 4 update 1, Enterprise Edition for Java, a powerful, popular and intutive IDE for enterprise class J2EE applications, and web services.
Figure 3: Iopsis iNsight 2.1
More information on Iopsis iNsight™ can be found at http://www.iopsis.com.
Modelling the WSDL interfaces engenders added advantages beyond well-engineered contracts. A major advantage is versioning and another interesting by-product is interoperability. As Web services mature, there will be growing momentum towards extending the tenets of software modelling to these new and portable IDLs - Web services interfaces will never be the same again.
Web Services
Web Services Description Language (WSDL) 1.1 - W3C Note 15 March 2001 < http://www.w3.org/TR/2001/NOTE-wsdl-20010315>
The IDL That Isn't -by Martin Gudgin, Timothy Ewald
< http://www.xml.com/pub/a/2002/01/16/endpoints.html >
Is WSDL The Dispensable API? By Eoin Lane
< http://www.javaworld.com/javaworld/jw-05-2002/ jw-0524-wsdl.html >
Designing Your Web Service for Maximum Interoperability - Scott Seely
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service12052001.asp>
Web Services Interoperability (WS-I) Working Draft
<http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm>
UML
UML 1.5 Specification - OMG
< http://www.omg.org/technology/documents/formal/uml.htm >
Process Quality Assurance for UML-Based Projects - Dr. Bhuvan Unhelkar, Addison Wesley Professional
Dr. Bhuvan Unhelkar (BE, MDBA, MSc, PhD, MACS), Consultant, Method Science, Sydney, Australia
Hrishikesh Joshi, Lead Technology Architect, Iopsis Software.
Ash Parikh (ash@iopsis.com) is the Sr. Manager of Engineering and Architecture, with the Emerging Technology Group at Iopsis Software, Inc (http://www.iopsis.com). He is a named expert in the field of Distributed Computing, has authored abstracts for BEA e-World 2002, Java One 2002 and Java One 2003. He developed the first prototype for J2ME Web services, a paradigm earlier thought of as impossible to pull-off on limited footprint devices, while at BEA Systems. He has over 10 years of computer and IT experience, including expertise in object-oriented analysis and design, distributed architecture, middleware architecture and software design and development. He is also the President of the Bay Area Chapter of the Worldwide Institute of Software Architects, an initiative close to his heart, through which he evangelizes various software architecture paradigms. He recently co-authored a book through Osborne Press titled "Oracle9iAS Building J2EE Applications," ISBN: 0072226145, November 2002. He is the author of a two-part series of technical articles in Web Services Journal, titled "Extending Web services to the Real World," March 2003 and "Web Services and Portal Technology," April 2003. He is also a member of the Expert Group for JSR 188 "CC/PP Processing," JSR 205 "Wireless Messaging API 2.0," on the Java Community Process standards body.
Rajesh Pradhan (rajesh@iopsis.com) is the Founder and Chief Software Architect of Iopsis Software, Inc (http://www.iopsis.com). He is a well-acclaimed Internet architect in circles around the world and has co-authored articles on architectural strategies and Object Oriented Approaches for international conferences. He is the co-author of Hewlett Packard's patent pending Retail Web Services Framework, currently being used to integrate over 10 retailers with HP's Consumer Business Systems. He is the Chief Architect of the path-breaking new web services products that the company is bringing to market. He is also a founder member of the Bay Area Chapter of the Worldwide Institute of Software Architects, and represents Iopsis on various standards bodies like the JCP and OASIS. He is currently a member of the Expert Group for JCP hosted JSR 157, 198, 207, the Business Process Workgroup of the UN/CEFACT/TMG and the ebXML CPPA Technical Committee and the BPEL4WS Technical Committee under the aegis of the OASIS.
Sun™,
Sun Microsystems™,
Sun™
ONE, Java™,
Enterprise Java Beans™
are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. "
