CA2420786A1 - Enterprise services development model - Google Patents
Enterprise services development model Download PDFInfo
- Publication number
- CA2420786A1 CA2420786A1 CA002420786A CA2420786A CA2420786A1 CA 2420786 A1 CA2420786 A1 CA 2420786A1 CA 002420786 A CA002420786 A CA 002420786A CA 2420786 A CA2420786 A CA 2420786A CA 2420786 A1 CA2420786 A1 CA 2420786A1
- Authority
- CA
- Canada
- Prior art keywords
- service
- services
- definition
- toolkit
- implementation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000011161 development Methods 0.000 title claims abstract description 39
- 238000009739 binding Methods 0.000 claims description 46
- 230000027455 binding Effects 0.000 claims description 45
- 238000000034 method Methods 0.000 claims description 20
- 239000000203 mixture Substances 0.000 claims description 18
- 238000013507 mapping Methods 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 2
- 238000013501 data transformation Methods 0.000 claims description 2
- 230000010354 integration Effects 0.000 abstract description 9
- 239000008186 active pharmaceutical agent Substances 0.000 abstract description 8
- 238000013459 approach Methods 0.000 abstract description 6
- 238000004891 communication Methods 0.000 description 15
- 238000000157 electrochemical-induced impedance spectroscopy Methods 0.000 description 13
- 239000000344 soap Substances 0.000 description 11
- 101001074449 Crotalus durissus terrificus Phospholipase A2 inhibitor CNF Proteins 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 238000012360 testing method Methods 0.000 description 8
- 230000009466 transformation Effects 0.000 description 6
- 235000010627 Phaseolus vulgaris Nutrition 0.000 description 5
- 244000046052 Phaseolus vulgaris Species 0.000 description 5
- 235000006719 Cassia obtusifolia Nutrition 0.000 description 4
- 235000014552 Cassia tora Nutrition 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 244000277285 Cassia obtusifolia Species 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 238000000844 transformation Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000002860 competitive effect Effects 0.000 description 2
- 238000013506 data mapping Methods 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 101100438752 Arabidopsis thaliana CPI1 gene Proteins 0.000 description 1
- 101710125089 Bindin Proteins 0.000 description 1
- 244000201986 Cassia tora Species 0.000 description 1
- 241000428198 Lutrinae Species 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 230000003116 impacting effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000009870 specific binding Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001131 transforming effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
Abstract
A development model for architecting enterprise systems presents a service-oriented approach which leverages open standards to represent virtually all software assets as services including legacy applications, packaged applications. J2EE components or web services. This approach provides developers with a standard way of representing and interacting with parts of a business application without having to spend time working with unique interfaces and low-level APIs. Furthermore, individual business application components become building blocks that can be reused in developing other applications. Using i:he service-oriented approach to integration in accordance with the present invention reduces the complexity, cost, and risk of integration by providing a single, simple architectural framework based on Web Services in which to build, deploy, and manage application functionality. In one aspect, a services toolkit for an integrated development environment is introduced to facilitate development in accordance with the model.
Description
ENTERPRISE SERVICES DEVELOPMENT MODEL
FIELD OF THE INVENTION
The present invention relates to application development and operation and.
more particularly, to enterprise services applications and the development of such applications using an integrated development environment.
BACKGROUND OF 1"HE INVE:N'TION
Many enterprises today encounter a growing information technology (IT) predicament for their electronic commerce (e-commerce, whereby transactions for a variety of goods and services are conducted electronically) and electronic; business (e-business, whereby business processes -e.g., shipping, procurement, staffing, etc. - are transformed so as to be conducted electronically) needs. The evolution of their I'T systems has left them with an enterprise-computing infrastructure that is often heterogeneous, widely distributed. and increasingly complex. In the face of pressure to cut costs. build customer loyalties. and gain a competitive advantage. new I'T
applications are often created to achieve these goals.
Instead of building each new application from the top down, reinventing the wheel, companies need a way to reuse their existing software assets and to leverage the power of web services in the development of new applications. The new applications should themselves provide reusable assets providing leverage to further the goals of cost cutting and competitive advantage in the future. Existing assets may include those that are web based and those which are not, such as legacy back end systems (sometimes referred to as Enterprise Information Systems - EISs, which systems may stand alone and are not designed for web services) to access and store information related to an e-business or e-commerce transaction. For example, a large scale enterprise e-business application may be desired to provide For web-based purchasing of goods or services. Rather than build such an enterprise service ti~om scratch, such a service may be constructed ti~om numerous existing and new service components to ensure that a good or service purchased is delivered on time to the customer making the purchase.
As a result of the complexity and cost involved with architecting enterprise applications, much research and development has been undertaking to produce an appropriate development model.
Otle COtlltllollly used approached to developing mufti tier enterprise applications is to develop in accordance with the .IavaT"' 2 Platform. Enterprise Edition (J2EE) standard of Sun Microsystems, Ine. created in collaboration with others. (Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc.) J2EE is intended to simplify enterprise applications and their development by basing the applications on standardized, modular components. .I2EE further provides a complete set of services to those components, and 1 ~ handles automatically many details of application behavior to avoid complex programming.
.12EE extends many features of the Java 2 Platform. Standard Edition for Java based applications and adds titll support for Enterprise Java Beans components. .lava Servlets AP1, Java Server Pages and Extensible Markup language (XML) technology. J2EE was developed with a view to facilitating quicker application development and deployment and to producing applications that are portable and scalable for longevity.
Mufti tier applications that require the integration of a variety of resources including legacy data and code as well as programmer skill-sets are difficult to design.
It is reported that integrating these resources can take up to ~0°ro of application development time. The ,12EE
standard wraps and embraces existing resources required by multi tier applications with a unified. component-based application model and enables co-operating components, tools.
systems, and applications for solving the strategic requirements of an enterprise.
However. J2EE component architecture is not without its limitations and disadvantages.
For example, J2EE does not provide to developers a standard way of representing and interacting with software assets without having to spend time working with unique interfaces and low-level APIs. As such, components created are otters unique to the interfaces and low-level APIs and cannot be used conveniently as building blocks to be reused in developing other applications.
J2EE component architecture is Java language based and requires that non-,lava applications be wrapped in ,12EE components via ,12EE Connector AI'CIlLtectLICe.
J2EE and its Connector Architecture do not inherently provide a model or standard for abstractly defining the functionality of an enterprise application or a consistent way of interacting with aspects of the enterprise application such as connectors, web services, messaging applications and EJB components.
In furtherance of goals related to interoperability, code re-use and component architecture for detlning and offering e-commerce and e-business applications via the protocols of the Internet. a web services model was developed. The functionality of a business application component offered via the Internet or web is described as an abstract serv.~ice such as in an XML-based document. in accordance with a standard. The description can then be shared with other developers and used to construct clients of the offered service. Access to the service is provided by web based protocols such as Simple Object Access Protocol (SOAP) over Hyper Text Transfer Protocol (HTTP). Vv'eb Services Description Language is one such XML-based language for abstractly describing web services. However, this model is directed to web services and not to enterprise applications generally, lacking an inherent capacity to deal with (i.e.
adequately describe) other protocols or bindings, componen t implementations, backend systems and their specific data requirements. Moreover, as the web protocols are relatively inefficient, the model is not embraced universally.
As such, a development model for architecting enterprise applications which addresses some or all of these shortcomings is desired.
SL!MMARY OF THE INVENTION
The present invention is directed to a service-oriented development model for enterprise applications and an integrated development environment for architecting such applications.
In one aspect of the present invention, there is provided a method for architecting an enterprise application. The method comprises creating one or more services that define said enterprise application. each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of types, the service definition conforming to a standard common for differing service provider types. The method further comprises deploying the one or more services where each service is deployed in accordance with an access definition sufficient to access the service. In accordance with this method aspect, the dii:fering service provider types comprise tw-o ~~r more types selected from:
access protocols:
software assets; resource adapted EIS services; a.~ tlow composition defining a service tivom one or more other services: and a transformer mapping one or more input messages of a particular service to an output message of the particular service.
The service definition comprises a service interface definition and a service implementation definition and, in accordance with a feature of this method, the step of creating comprises, for each service, generating a service interface definition modeling the interface of the service provider: and generating a service implementation definition describing an implementation of the service interface and the location of the implementation. The service interface definition and service implementation definition preferably comprise separate documents which documents may be XML-based and conform to the WSDL standard.
The step of deploying comprises adapting the deployed service for operation on an application server. The method may also connprise a step of defining a service proxy for accessing the deployed service and the service proxy may be defined from a portion of the service definition describing an interface to the service and the access definition for accessing the deployed service.
In accordance with another aspect of the invention there is a services toolkit for architecting an enterprise service. The services toolkit comprises a service creation component for creating one or more services that define said enterprise application, each setviee created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types. 'l~he differing sc;rvice provider types comprise two or more types selected ti~om access protocols; software assets: resource adapted EIS
services: flow compositions. each flow defining a service ti~otn one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service. IN accordance with this services toolkit, the toolkit further comprises a service deployment component for deploying the one or more services in accordance with a respective access definition sufficient to access a respective service and the services toolkit is adapted to communicate with an integrated development environment to assist with architecting the enterprise application.
The services toolkit may including one or more tools to assist with the creation of the service definition for each service provider type. Particularly, the services toolkit may comprise one or more of: a service provider browses to facilitate a selection of a service provider type to create the service definition; a service definition editor for generating a service interface detinition modeling the interface of the service provider; and at least one service implementation editor for generating a service implementation definition describing an implementation of a service interface of the service and the locatic,~n of the implementation. A
particular service implementation editor may comprises a flow editor for generating flow compositions graphically or a transformer editor for defining data transformations in accordance with a standard therefor.
I S Service definitions may comprises a service interface definition and a service implementation definition detlned by separate documents, which may be XML
documents and which XML documents may conform to the WSDL standard.
One feature of the services toolkit includes a tool for at least one of importing and exporting the service definition to facilitate creating at least one of a service and a client application to use the service. Further, the service deployment component comprises a tool for adapting the deployed service for operation on an application server and may include a service proxy wizard for creating a service proxy to access the deployed service. A
service skeleton wizard may be included to at least partially generate a service provider from a service definition.
The services toolkit may be adapted for architecting enterprise application for operation in a .12EE environment. The access protocols may be selected from protocols operable to invoke Java based components: the software assets may be selected from Java based software components; and the resource adapters may be selected tcom resource adaptors operable in accordance with Java based connector standards.
In accordance with a further aspect, the invention provides a computer program product embodied in a computer readable medium for providing instructions and data to a computer system executing an inte~~rated development environment ( IDE) for architectin g an enterprise service application. The instructions and data define a services toolkit that, when operated on said computer system, adapts the IDE to (a) create one or more services that define said enterprise application, each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types; and (b) deploy the one or more services, each deployed in accordance with an access definition sufficient to access the service. The differing service provider types comprise at least two types selected from access protocols; software assets: resource adapted EIS services: tlow compositions, each tlow defining a service from one or more other services; and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service.
In accordance with yet a further aspect, there is provided An integrated development environment (IDE) for architecting an enterprise service comprising: first means for describing a service interface to a service: second means for describing a service implementation to the service, said service implementation binding the service interface to one of a plurality service providers having one of a plurality of service provider types, the second means conforming to a standard common for differing service provider types; third means for generating a service from said first and second means: fourth means for describing a protocol sufficient to access the service; and fifth means for deploying the service in accordance with the fourth means. Ln accordance with this aspect. the differing service provider types comprise two or more types selected from access protocols; software assets; resource adapted EIS
services; flow compositions, each flow det7ning a service from one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service.
Advantageously a service-oriented architecture leverages open standards to represent virtually all software assets as services including legacy applications, packaged applications, .12EE components or Vl~'eb services. This approach provides developers with a standard way of representing and interacting with software assets without having to spend time working with unique interfaces and low-level APIs. Ivrthermore, individual software assets become building blocks that can be reused in developing other applications.
Using the service-oriented approach to integration in accordance with the present invention reduces the complexity, cost, and rill: of integration by providing a single, simple architectural framework based on mb services in which to build, deploy, and manage application functionality.
Other aspects and features oi' the present invention will become apparent to those ordinarily skilled in the art upon review ~ of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
In the figures which illustrate an example embodiment of this invention:
FIG. 1 schematically illustrates a computer system embodying aspects of the invention;
FIG. 2 schematically illustrates. in greater detail, a portion of the computer system of FIG. 1;
FIG. 3 illustrates, in functional block form, a portion of the memory illustrated in FIG. 2;
FIG. 4 illustrates in schematic form a service in accordance with a programming model of this invention;
FIG. 5 illustrates in schematic form a logical service bus for integrating services in an enterprise services environment according to the present invention;
FIG. 6 illustrates the architecture of a WSDL document:
FIGs. 7a, 7b, 7c and 7d illustrate, in greater detail and in functional block form, a portion of FIG. 3;
FIG. 8 illustrates in greater detail and in Iianetional block form, a portion of FIG. 3;
FIG. 9 illustrates, in greater detail and in functional block form, a portion of FIG. ~; and FIG. 10 is a t7ow chart of operations performed during the development of an enterprise services application.
DETAILED DESCRIPTION
An embodiment of the invention, computer system 100, is illustrated in FIG.1.
Computer system 100, illustrated for exemplary purposes as a networked computing device, is in communication with other networked computing devices (not shown) via network 110. As will be appreciated by those of ordinary skill in the art. network 110 may be embodied using conventional networking technologies and may include one or more of the following: local area networks, wide area networks, intranets. public Internet and the like.
Throughout the description herein, an embodiment of the invention is illustrated with aspects of the invention embodied solely on computer system 100. As will be appreciated by those of ordinary skill in the art, aspects of the invention may be distributed amongst one or more networked computing devices which interact with computer system 100 via one or more data networks such as, for example, network I 10. However. for ease of understanding, aspects of the invention have been embodied in a single computing device - computer system 100.
Computer system 100 includes processin,~~ system 102 which communicates with various input devices 104, output devices 106 and network 1 10. Input devices 104, two of which are shown, may include, for example, a keybu>ard, a mouse, a scanner, an imaging system (e.g., a camera, ete.) or the like. Similarly, output devices 106 (only one of which is illustrated) may include displays, information display unit printers and the like.
Additionally, combination input/output (I/O) devices may also be in communication with processing system 102. Examples CA9-2002-0027 1 () of conventional I/O devices include removable and fixed recordable media (e.g., floppy disk drives, tape drives. CD-ROM drives, DVD-RW drives, etc.). touch screen displays and the like.
Exemplary processing system 102 is illustrated in greater detail in FIG. 2. As illustrated, processing system 102 includes several components - central processing unit (CPL1) 202, memory 204, network interface (I/F) 2()8 and I/O I/F 210. Each component is in communication with the other components via a suitable communications bus 206 as reduired.
CPLI 202 is a p~°ocessing unit, such as an Intel Pentium'rM. IBM
PowerPCTM, Sun Microsystems LlltraSparcTM processor or the like. suitable for the operations described herein. As will be appreciated by those of ordinary skill in the art, other embodiments of processing system 102 could use alternative CPUs and may include embodiments in which one or more CPUs are employed (for example 202A, 202B, ... 202N). (_'PU 202 may include various support circuits to enable communication between itself and the other components of processing system I 02.
Memory 204 includes both persistent and volatile memory (212 and 214) for the storage of: operational instructions for execution by CPI1 202, data registers, application storage and the like. Memory 204 preferably includes a combination oi~ random access memory (RAM), read only memory (ROM) and persistent memory such as that provided by a hard disk drive.
Network I/F 208 enables communication between computer system 100 and other network computing devices (not shown) via network 1 10. Network I/F 208 may be embodied in one or more conventional communication devices. Examples of a conventional communication device include an Ethernet card, a token ring card, a modem or the like.
Network I/F 208 may also enable the retrieval or transmission of instructions for execution by CPU
202 from or to a remote storage media or device via network 110.
I/O I/F 210 enables communication between processing system 102 and the various I/O
devices 104, 106. 1/O I/F 210 may include, for example, a video card for interfacing with an external display such as output device 106. Additionally. I/O I/F 210 may enable communication between processing system 102 and a removable media 215. Although removable media 215 is illustrated as a conventional diskette other ren uovable memory devices such as ZipT"'' drives, Clash cards, CD-ROMs, static memory devices and the like may also be employed.
Removable media 215 may be used to provide instructions t~.~r execution by CPU 202 or as a removable data storage device.
The computer instructions/applications stored in memory 204 and executed by (thus adapting the operation of computer system 100 as described herein) are illustrated in functional block form in FIG. 3. As will be appreciated by those of ordinary skill in the aut, the delineation between aspects of the applications illustrated as functional blocks in FIG. 3 is somewhat arbitrary as the various operations attributed to a particular application as described herein may, in alternative embodiments. be subsumed by another application.
1 ~ As illustrated, for exemplary purposes only, memory 204 stores operating system (OS) 302, communications suite 304, IDE 306 adapted with services toolkit 308, various service providers 310a-310g (collectively 310), services 312 comprising development artifacts (shown in doted outline) and application server 314 to which the services are deployed.
OS 302 is an operating system suitable for operation with a selected CPU 202 and the operations described herein. For example, IBM AIX!K~, Microsoft Windows NTTM
or XP
ProfessionalTN', Linux (Linux is a trademark of Linus Torvalds) or the like.
are expected in many embodiments to be preferred.
Communication suite 30=1 provides, through. lzltez'actlotl with OS 302 and network I/F
2U8 (FIG. 2), suitable communication protocols to enable communication with other networked computing devices via network 110 (FIG. l ). Communication suite 301 may include one or more of such protocols such as TCPlII', Ethernet, token ring and the like.
Also stored in memory 204 (and used during the development process) and incorporating aspects of the present invention is Integrated Development Environment (IDE) 306. In the exemplary embodiment, IDE 30fi provides a developer (or a team of developers) a development environment using a graphical user interface (GUI) known to those of ordinary skill in the art.
The GUI typically includes a number of windows or panes for viewing source code, project files, debugging information or the like.
Unlike conventional IDES, IDE 306 is adapted to have services toolkit 310 "plugged in".
'through tools of the services toolkit 308, IDE 306 is able to assist developers in developing a business or enterprise services application incorporating artifacts 312 designed to use the services provided by one or more selected service providers 3I0. FIG. 4 illustrates a definition for a service in accordance with the programming model 400 of the present invention and showing exemplary service providers. A service 312 is defined using a service provider such as a software asset. for example. a Java bean 310c or stateless session Enterprise Java Bean (EJB) 310d, resource adapted EIS services (RA 310e ), such as .12EE Connector Architecture (JCA) connected or otherwise resource adapted service (for example, fr~r facilitating EIS services such as CICSu~K, IMSTM, IBM Host On Demand (HOD), and others), database assets (not shown) via a ,lava Database Connector (JDBC) and access protocols such as SOAP 310a or JMS
(not shown).
J2EE Connector architecture (JCA) is described in greater detail in the document entitled "J2EE Connector Architecture Specification", ,ISR 016, Version 1.0, Final Release, Released August 22, 2001 from Sun Microsystems, Inc. of Palo Alto. California, the contents of which are hereby incorporated herein by reference. Integrating a .ICA based resource adapter with the services toolkit is accomplished via a JCA tool plty~in. The .1C'A tool plugin is a connector architecture extension to make connectors communicate with tool environments such as an IDE
and is not specific to the present services toolkit. ~rhe tool plugin defines how to provide EIS-specit3c binding extensions and how the tool environment interacts with the EIS to get the information. Lastly°, it defines how an EIS provides code generation contributions. The tool plugin also supplies JCA Common Client Interface (CCI) extensions for EIS
system service invocations. While a tool plugin assists with working with the resource adapter, it can be directly worked using Java and EJB tools to wrap the connector functions in a Java Bean or stateless session EJB. Thereafter. the services toolkit can consume these services transparently as per other similar typed software assets.
1 ~ Additionally a service may be defined using a flow service provider 310f which may use one or more services and including a service comprising a Transform (Xform) 3108 service provider. As described in detail herein below, features like flow composition provided by flow 41? can be used to compose a new service out of other services.
Transformations provided by Xform 414 allow the mapping of data from one or more messages received by a service to an output message for the service in a flow composition.
Access to sei°vices is made available via one or more access protocols such as Simple Object Access Protocol (SOAP) run over HTTP and Remote Method Invocation (RMI) run over Internet Inter-Orb Protocol (IIOP) (not shown). RMI-IIOP delivers Common Object Request Broker Architecture (CORBATM) distributed computing capabilities to the Java 2 platform. Other service provider options may be included. such as Java Messaging Service (JMS) (not shown) as will be apparent to those of ordinary skill in the art.
The operation of IDE 306 and s~:r<~ices toolkit 308 and their interaction with service providers 310, services 312 and application server 314 is better understood with reference to FIGs 5-10 described below ~.
Services Toolkit 308 provides service-oriented development environment for business and enterprise application integration for deployment to a server such as application server 314.
With reference to FIG. 5, there is shown a logical schematic representation of memory 204 from the viewpoint of application server 314 having a logical service bus 502 that acts as the point of integration for the wide variety of services 312 offered by service providers 31 Oa-310g. Services toolkit 308 provides tools and support needed to be able to consume and provide services to server 314 via the service bus X02.
At the core of the programming model 400 of the services toolkit 308 are enterprise 1 ~ services. or services 312 for- short. Services 31 ? ace used to model different kinds of service providers 310 in a consistent way. rfhe following is an overview ~ of the programming model 400:
Data: XML Schema, Service Message Interface: Serv ice Interface Implementation: Service Binding SOAP
Java bean Stateless session EJB
JCA
Flow CA9-2002-0027 1 '_i Transformer The part of the programming model 400 that ties the elements of the model together is the service 312. Services tc.>olkit 308 employs a description mechanism namely, Web Services Description Language ( WSDL), for describing any kind of service 312. WSDI_ is sufficiently extensible to describe any kind of IT services and not simply web services.
FIG. 6 illustrates WSDL document architecture: 600 comprising an abstract service interface definition section 602 and service implementation and location definition section 604.
The service interface in WSDL is called a port~I~ype 606. PortType 606 consists of one or more operations 608 with input 610 and output 612. Input 610 and output 612 are described by lU services messages typed using XML Schema to describe the business data that flows in and out of the services.
Service implementation and location definition section 604 describes how the service interface is implemented and where it can be found. ~fhe service location is described by a service provider specific port extensibility element 6I6. The servlCe llllplelllelltatl011 IS described I~ by service provider specific extensibility elements in the binding section 618. Services toolkit 308 can be adapted to support a wide variety of service provider specific bindings such as SOAP.
JC'A. .lava Bean, Stateless session E,IB, Flow, and 'Cransform. among others, as previously described.
WSDL. provides a standard way fur describing which services arc; ot~ered by a ser~~ice provider 20 and how you access them. WSDL, in XML Ibrmat. describes 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 CA9-?002-0027 16 network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDC, is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. WSDI. can be better understood with reference to the World Wide Web s Consortium (W3C) document entitled "Web Services Description Language (WSDL) 1.1" dated March 15, 2001 the contents of which are hereby incorporated herein by reference. While the exemplary embodiment described herein utilizes VVSDL, other languages which describe services could also be employed. For example, it is contemplated that the Electronic Business XML (ebXML) language protnulgat~d. in part, by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFAC.'T) could, alternatively, be employed.
A docwnent from the Sun Microsystems, Inc. (,lava Community Process group) of Palo Alto, California entitled JSR 110 "Java APIs for WSDL" describes a proposed standard set of APIs for representing and manipulating services described by Vl~'SDL documents. These APIs define a way to construct and manipulate models of service descriptions. The contents of ",lava APIs for WSDL" is I 5 hereby incorporated herein by reference.
In accordance with the invention, flow ~ 12 and Transform (sometimes referred to as Xform) 414 are each a specific form of service implementation. Flow 412 is useful to compose a service 312 out of other services 312 while Xform 414 provides a manner of mapping between service messages, including mapping multiple input messages to a single output message. A flow consists of service nodes, each node representing the invocation of a service operation. The service nodes are tied together by control links which indicate the sequence of execution and under which condition execution takes place. The data flow between service nodes is constructed using data links. These data links can include data mapping nodes (via Xform 414) for cases when messages between service nodes do not match and a new service message is to be produced. Flow composition may be described using a markup Imguage. The transformation implementation is described in the form of XSL'i'.
XSLT (Extensible Stylesheet Language Transformation] is a language for transforming XML documents into other XML documents. XSL~T addresses the need to have data presented differently to meet the particular reduirements of an organization/individual by providing the ability to define a set of transformation ~°ules to transform the data.
XSLT can be better understood with reference to the World Wide Web Consortium (W3C) document entitled "XSL
'Transformations (XSLT) Version 1.0" dated November 16, 1999.
The development model of services toolkit 308 consists of three primary process steps:
(1) creating a service; (2) deploying a service; and (3) creating a service proxy, each of which steps is described herein below in more detail, along with the development artifacts produced.
FIGS 7a, 7b. 7c and 7d illustrate in greater detail development artitacts 312 produced by services toolkit 306, namely an exemplary service 702, an exemplary deployed service 704, an exemplary deployed services archive 705 and an exemplary service proxy 706.
Service toolkit 308 can facilitate the creation of a service in different ways. First it facilitates creation of a service for an existing provider. for example, a Java Bean, a Stateless Session EJB, resource adapted services (e.g. .1CA adapted CICS services) and others. Another form of service creation is through flow composition, where a service is created by composing it out of other services. Finally, a service may be created from scratch and from it a service provider may be created (that is, top-down development).
In accordance with an embodiment of services toolkit 308, when creating a service, the Vv'SDL defining the service is partitioned into a services interface definition embodied in a document ("interface".wsdl) comprising a WSDL, abstract service interface definition section 602 (FIG. 6) and a services implementation and binding dellnition embodied in a document ("implementation_binding".wsdl) comprising a WSDL service interface and binding section 604.
It will be understood to persons skilled in that art that the message and type descriptions of section 602 could also be in separate files. WSDL artifacts are preferably partitioned into separate tiles to facilitate re-use, separating interfaces, which may be made public, IrOnl implementation details, which may be proprietary and desired to be kept private. Further.
separation enhances transparency, permitting an implementation to change without impacting an interface.
The following Java and WSDL code samples shows how an exemplary service 702 (FIG.
7A) is created from an existing software asset type service provider (e.g.
Java Bean 404), in this case ti~om a StockQuote .lava class:
package sample.stockduote:
public class StockQuote i public float g,etQuote(String symbol) float quote = 0;
// ...
return duote;
a r Creating the service from the StockQuote ,lava class results in the creation of two WSDL
resources, one containing the StockQuote interface, namely StockQuote.wsdl 708, the other one containing the native .lava binding of the StockQuote interface. namely StockQuote.Java.wsdl CA9-2002-0027 1 ~) 710. The following WSDL sample shows the content of the StockQuote.wsdl 708 resource, including a StockQuote interface with the operation getQuote, and the service messages for the input and output of the operation.
StockQuote.wsdl: <?xml version="1.0'~ encoding="U'hF-8"'?>
<definitions name="StockQuote"' targetNamespace="http:'/stockquote.sample/"' xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns='http://stc>ckquote.samplef"
xmlns:xsd= 'http://www.w3.org/2001 /XM L.Schema'">
<message name="getQuoteRequest'~>
<part name="symbol"" type--'xsd:string"/>
</message>
<message name="getQuateResponse">
<part name="result"~ type="xsd:float" ;'>
</message>
<portType name--"StockQuote'">
<operation name="getQuote"" parameterOrder="symbol"'>
<input tllesSage=="tnS:~etQLlotelZ~C~LIeSt"" name--"getQuoteRequest"/>
<output message="tns:getQuoteResponse"" name="getQuoteResponse~"/>
</operation>
</portType>
</definitions>
'the following WSDL sample shows the content of the StockQuoteJava.wsdl 710 resource with the StockQuote .lava class as the f°ndpoint in the port section, and the native Java 2~ binding that references the interface defined in St.ockQuote.wsdl 7()8.
StockQuoteJava.wsdl: <''~ml version-- '1.0"' encoding="UTF-8"'?>
<detinitions name="StockQuoteJava'"
targetNamespace="http:/!stockquote.sample/"' xmlns="http://schemas.xmlsoap.org; wsdl;"
xmlns:tbrmat="http:; /schemas.xmlsoap.org/wsdl/formatbinding/"
xmlns:java="http://schemas.xmlsoap.org/wsdl/java/"' xmlnsans="http:/istockduote.sample/""
xmlns:xsd="http://wvw.w3.org/2001 /XMhSchema">
<import location="StockQuote.wsdl"' namespace="http://stoekquote.sample/""/>
<binding name="StockQuote,lavaBinding"" type="tns:StockQuote"">
<j ava: bi nding/>
<formataypeMapping encoding=",lava" style=",lava"'>
<format:typeMap formatType="float'" typeName="xsd:tloat'"/>
<format:typeMap formatType='java.lang.String"" typeName="xsd:string"/>
</formataypeMapping>
<operation name="getQuote'">
<java:operation methodName="getQuote"~ parameterOrder="symbol"' returnPart="result'"i>
<input name="getQuoteRequest'"/>
<output name--"getQuoteResponse'"/>
</operation>
</binding>
<service name="StockQuoteSemice~"=
<port binding="tns:StockQuoteJavaBinding'" name-- 'StockQuoteJavaPort'">
<java:address className="sample.stockquote.StockQuote""/>
</port>
</service>
</delinitions>
When deploying a service to a server, additional definitions are provided for the inbound bindings by which the service is made accessible to a client application (not shown). An inbound binding is an outbound binding that a client of the service must use to invoke the service as described further below with respect to service proxies. In accordance with an embodiment of the services toolkit 308, an inbound binding may be a SOAP binding or a EJB
binding which makes the service accessible by using the EJB programming model. Services toolkit 308 may also be adapted to support other inbound/outbound bindings such as JMS and others. FIG. 7b shows service 702 accessible through the SOAP protocol. That is FIG. 7b shows an exemplary CA9-2002-0027 2 l deployed service 704 comprising service 702 and one or mode additional inbound binding WSDL files, namely StockQuoteSOAP.wsdl 71:?. The inbound binding tiles contain the service location information as well as the inbound binding to the service interface.
The following WSDL sample code lists the content of the StockQuoteSOAP.wsdl resource. with the SOAP address as the endpoint in the port section, and the SOAP binding referencing the interface defined in StockQuote.wsdl 708.
StockQuoteSOAP.wsdl: ~~'?xml version='°1.0'~ encoding="L1TF-8'"?>
<detinitions name="StockQuoteSOAPBinding'' targetNamespace="http:!/stockquote.samplef"
xmlns="http://schemas.xmlsoap.orgiwsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlnsans="http:/istockquote.sample/"=
<import location="StockQuote.wsdl"
namespace="http://stockquote.sample/' ~'>
<bindin~ name="StockQuoteSOAPBinding" type="tns:StockQuote"'>
<soap:binding style--'rpe" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getQuote">
<soap:operation soapAction="urn:StockQuote"' style="rpe"/>
<input name="getQuoteRequest'">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/'"
namespace= 'urn:StockQuote" parts= 'symbol"' use="encoded"/>
</input>
<output name="getQuoteResponse">
<soap:body encodingStyle=''http://schemas.xmlsoap.org/soap/encoding/"' namespace="urn:StockQuote"' parts="result"' use="encoded"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
CA9-2002-0027 2:?
<port binding="tns:StockQuoteSOAPBinding~~
name="StockQuoteSOAPfort ~>
<soap:address location="http:// localhost:8080/Services-SOAP/servlet/rpcrouter"/>
</po rt>
</service>
</deflnitions>
Services toolkit 308 also generates a thin stateless session EJB wrapper (i.e.
bindings) StockQuoteE,lB.wsdl 713 for the service 702. StockQuoteEJB.wsdl describes the thin stateless session EJB wrapper. Standard EJB deployment descriptor definitions can be used to specify additional Quality of Service (QOS) attributes for the deployed service, for example, security and transactional attributes as will be apparent to those of ordinary skill in the art.
Deployed services are installed into application server 314 by packaging them into a ,12EE enterprise archive ( EAR) file such as exemplary archive 7(.)5 as shown FIG. 7c. Exemplary archive 705 illustrates exemplary deployed service 704 for a stock quote service together with additional deployed services 714 and 716 for a purchase order service and a customer information service, respectively, in L:AR "Myservices.ear" 70~. StockQuote service 704 is accessible through SOAP and provided by a .Java class. PurchaseOrder service 714 is accessible through SOAP and provided by a l7ow and CustomerInfo service 716 accessible through SOAP
and provided by a resource adapted CICS service.
FIG. 8 illustrates how a deployed service, such as C ustomerInfo 716, manifests itself in server 314. In this sample, deployed service 716 is provided by a CICS service requiring a resource adapter such as a ,ICA service provider. Deployed service 716 is accessible from the client side by the SOAP protocol (for example as a web service) and the EJB
programming model (for example for a more local, private invocation). As described above.
deployed service 716 comprises service 802 having interface and implementation artifacts 804 and 806, respectively, and inbound bindings development artifacts 808 and 810. The artifacts 808 and 810 are tiles "customerInfoSOAP.wsdl" and "Custon nerlnfoE.lB.wsdl" providing binding descriptions to the application server components 812 and 814 for SOAP and RMI-IIOP object request broker (ORB) access. The artifacts 804 and 806 are the tiles "Customerlnfo.w~sdl" and "C'ustomerInfoClCS.wsdl" providing descriptions of the target CICS service to session bean component 816 including a JCA CICS connector run-time component 818. Server component 812 receives and responds to service invocation requests (e.g. remote procedure calls (RPC)) via SOAP over HTTP protocols. Using artifact 808, the SOAP server component determines the particulars for service invocation. In the present example. SOAP provides a front end to the session EJB 816. Session EJB 816 recognizes the request and invokes the CICS
service. Session EJB 816 acts as a proxy to the CICS service to provide the result. Similarly, ORB run-time component 814 may receive a RMI-IIOP invocation for session EJB 816 and pass the invocation through. When the eustomerlnfo service is deployed. an EJB deployment descriptor for session EJB 816 is generated from the corresponding WSDI. information 810 and ORB
component 814 is configured with this deployment descriptor. The deployment descriptor provides a way to route an incoming RMI-IIOP request to the appropriate session bean.).
Creating a service proxy. such as exemplary proxy 706 illustrated in FIG. 7d, involves creating a .lava Bean which may be invoked by a client application (not shown) to access a deployed service, for example, exemplary deployed service 704. A service proxy is generated ti-otn a service interface for the service to be invoked and an outbound binding that describes how to access the service interface. The outbound binding used by the proxy is the inbound binding with which the service is deployed. As such, exemplary service proxy 706 for exemplary deployed service 704 comprises interface StockQuote.wsdl 708 and binding StockQuoteSUAP.wsdl 712.
Services toolkit 308 provides a set of toi:>l components, such as wizards and editors etc., to simplify business and enterprise application integration tasks. The tool components are grouped and presented conveniently in a service perspective or view, which extends base tool components available in a typical IDE. For simplicity, the set of tool components is referred to as the services toolkit. FIG. 9 shows the tool component architecture of services toolkit 308 along with the development artifacts produced by the tool components.
A main function of the services toolkit ;>08 is the facilitation of service definitions 902.
Various tools aid a user to create and edit the different aspects of service definitions 902 and to use the definitions 902 to create additional development artifacts 904 and 906 for an application server, such as server 314, and for a service client (not shown).
Services toolkit 308 provides a graphic user interface (GLJI) for working with service definitions having customizable perspectives for presenting views to promote role-based development. A service perspective custumizes the layout of the GUI to facilitate the development of enterprise services containing the views of various resources for use to develop such services. As is commonly understood to persons skilled in the art, there are several ways to Launch tool components from a perspective in a GUI-based IDE including a toolbar, pop-up menu choices and a resource creation dialog or wizard.
A service view contained in the perspective provides a view of service resources such as three folders comprising, respectively, service projects containing service definitions; deployed services containing the services that have been deployed; and resource adapters containing one or more JCA or CCF or other resource adapters added (i.e. plugged in) to the IDE for facilitating services from EISs. A service project wizard (not shown) is provided for creating and manipulating service projects.
A service provider browses 907 provides a central tool to create services from existing service providers collectively 310 such as Java Qeans, Stateless Session EJBs, 3270 Terminals, and EIS systems made accessible by the .ICA Tool Plugin as described previously. The browses 907 presents the services and options offered by a particular service provider type to the user. A
service definition wizard and editor 908 assists with creating new service definitions (that is, WSDL. documents in the present embodiment). Service definition editor 908 is provided for editing these definitions, providing source editing as well as a browses style design editing capability.
As noted previously. XML schema definitions are used in service detlnitions to type service messages, modeling business data. A XML. schema wizard and editor 910 allows a user to create XML schema definitions. A I7ow wizard and editor 912 facilitates the creation of a service implementation by flow, composing the service out of other services.
Flow editor 912 is a graphical composition tool that allows scripting of services visually. To use services in a flow composition, services represented by icons are simply dragged and dropped from the service view into the flow editor 912. The I7ow of control between the services gets expressed by control links. the flow of data by data links which can contain data mappings when necessary.
In conjunction with the flow editor 912, a transformer wizard 914 creates message transformations to define mappings between service messages. The resulting transformer is itself a service and its operation is implemented using the XSL r specification as discussed previously.
UDDI Browses 916 facilitates importing service definitions from a Universal Description. Discovery, and Integration (UDDI) registry for web services. UDDI
provides a "meta service" for locating web services useful in private as well as public deployments. Once imported, the service definition may be used like any other service definition created with the services toolkit 308, for example, in a flow. A UDDI Export function exports service definitions for deployed web services to a llDDI registry so that other registry users can find and use the service.
Though not illustrated, a service skeleton wizard creates service provider skeletons from service definitions. The skeleton tool examines the service definition and generates an implementation skeleton from the definition. This tool can be used for a top-down approach to creating a service provider; that is, starting with the service definition and then creating the implementation.
A deployment wizard 918 creates deployed services from service definitions, such as exemplary deployed service 930 comprising exemplary service 932, into an Enterprise Archive (EAR) tile (for example file 90G) that can be installed into an application server 314. For each deployed service a thin stateless session bean wrapper 936 gets generated, and inbound bindings 938 can be configured through which the service should be accessible.
CA9-2002-0027 2'7 A service proxy wizard 920 creates proxies (such as a Java Bean proxy 904) for services to simplify interactions between deployed services 930 and client applications operating in a run-time environment 90~.
Services toolkit 308 may be adapted or associated with server tools (not shown) for use with a test environment, which can be used to eftlciently test deployed services. Server tools may be employed to set up a test server (not shown) and an association may be made between the E~1R tile that contains deployed services for testing with the test server. A
first level of testing can be done using a generic EJB test client to exercise the session EJB that was created for the service. A next level of test would be to create a ,lava proxy to exercise the deployed service, for example, to access the service using the SOAP protocol. In each case, a Java debug environment is used to debug Java code and the code generated by the services toolkit.
Use of IDE 306 and services toolkit 308 is described herein below by way of example and with reference to operations 1000 of FI(J. 10. The example relates to the use of Java bean based services to compose a new service through flow composition. The composed service is then deployed into an application server and made accessible through the SOAP
protocol. A Java proxy is created to make the SOAP service accessible from a Java application.
Upon start-up of operations 1000. IDE 306 adapted with services toolkit 308 launches a services perspective offering access, such as via a toolbar or pop-up menu choices, to tool components needed to accomplish service development tasks (Step 1002). To create a service project to contain the service definitions created in accordance with the following exemplary steps, a service project wizard may be employed and the requested particulars provided (Step 1004). After the service project is created, service provider bi°owser 906 is employed to create service definitions from existing service providers 907 (Step 1006). Service provider browses 906 informs the user about which service providers 907 are available, for example. ,lava classes, stateless session EJBs, 3270 Terminal services. resource adapters or connectors for EIS or other le~~acy services such as CICS, and others.
Service provider browses 906 may be launched from within a service project and the service provider type to be used is selected. In the present example, the services are based on Java classes. and the Java class services option is selected (Step 1008).
Thereafter, service provider browses 906 facilitates tine browsing of available Java classes to select one or more desired classes to add the class' service definition to the service project (Step 1010). The .lava classes themselves may have been previously created in the service project using the Java IDE
tools that are part of IDE 306 or those classes could be contained in any other Java project.
Following selection of particular Java classes, a service definition is created using the service definition editor (Step 1012). Simply and advantageously, only a service interface (portType) and its associated messages as described previously need be created in an interface WSDL document artifact. Service definition editor 908 may offer design and source editing such as by way of different views as will be understood by persons of ordinary skill in the art.
Thereafter. the service implementation WSDL document for the service interface is constructed using on of the service implementation editors, in this example, flow editor 912 for Ilow composition (Step 1014). Flow editor 912 is used to visually compose a new service out of other existing services. Service definitions created previously from .lava classes in the services perspective may be dragged and dropped into the flow editor. Control links between services are added, for example, visually represented by connecting a line between the services and defined CA9-2002-0027 2~) to control the sequence in which a tlow executes. The passing of data is controlled through data links comprising data maps for cases where message types do not match between services. Such may be defined with transformer wizard '~ 14. Flow editor 912 constructs a service implementation WSDI. artifact.
Once the flow-based service (e.g. 932) is determined. the service is deployed to an application server 314. In accordance with the present example. the services are packaged as a Stateless Session EJB and given further access by SOAP protocol bindings. In order to deploy the service as described (Step 1016), the service is packaged into au Enterprise Archive (EAR) file (e.g. 934) and the archive comprising the service is then installed into the application server 314 using the deployment wizard 918. The inbound bindings are selected to specify how access to the service will be provided. In this example, the SOAP protocol is selected. In the deployed services section of the services perspective view, the results (i.e.
artifacts) of the deployment step are displayed. The artifacts comprise the Stateless Session E.IB wrapper, the E.IB binding WSDL
file 936, and the SOAP binding WSDL tile 938.
Once the application server is started with this EAR, the flow-based service can either be accessed using the EJB programming model or through SOAP. The SOAP binding WSDL tile 938 can be published for public use (for' example. via UDDI Export 916 with the service interface WSDL) to make the service accessible via a registry (publicly or not) and the EJB
bindings 936 and the EJB wrapper details may be restricted.
The SOAP binding WSDL tile 938 that provides inbound descriptors for the application server side also provides outbound binding descriptors for a client application. Service proxy wizard 920 can be employed to create a Java proxy via SOAP 905 protocol to the deployed service 930.
The services-oriented architecture described herein is intended to allow developers to tie .lava and non-Java applications together with existing Web services to create logical flow-based enterprise services. Users can make such services available on an application server and even expose the services as a Web service. An IDE as adapted by the services toolkit described above and application server help build new applications that integrate with existing assets by leveraging a service-oriented architecture to reduce the complexity of large-scale application development and promote reuse by offering a standard way of representing and interacting with virtually all software assets. Integrated worki~ow increases productivity by enabling developers to visually choreograph interactions between software assets. Advanced transactional connectivity capabilities help developers avoid custom coding by providing extended transactional support for the many challenges related to integrating existing software assets with a J2EE environment.
As will be appreciated by those skilled in the art, modifications to the above-described embodiment can be made without departing from the essence of the invention.
For example, in addition to or in lieu of SOAP inbound bindings. JMS or other middleware service bindings can be Used for deployed services. While services toolkit 308 is provided to create the WSDL files and other artifacts, it will be appreciated by those of ordinary skill in the art that such artifacts may be created without toolkit assistance.
While one (or more) embodiments) ~:~f this invention has been illustrated in the accompanying drawings and described above, it will be evident to those skilled in the art that changes and modifications may be made therein without departing ti~om the essence of this invention. All such modifications or variations are believed to be within the sphere and scope of the invention as defined by the claims appended hereto. Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.
FIELD OF THE INVENTION
The present invention relates to application development and operation and.
more particularly, to enterprise services applications and the development of such applications using an integrated development environment.
BACKGROUND OF 1"HE INVE:N'TION
Many enterprises today encounter a growing information technology (IT) predicament for their electronic commerce (e-commerce, whereby transactions for a variety of goods and services are conducted electronically) and electronic; business (e-business, whereby business processes -e.g., shipping, procurement, staffing, etc. - are transformed so as to be conducted electronically) needs. The evolution of their I'T systems has left them with an enterprise-computing infrastructure that is often heterogeneous, widely distributed. and increasingly complex. In the face of pressure to cut costs. build customer loyalties. and gain a competitive advantage. new I'T
applications are often created to achieve these goals.
Instead of building each new application from the top down, reinventing the wheel, companies need a way to reuse their existing software assets and to leverage the power of web services in the development of new applications. The new applications should themselves provide reusable assets providing leverage to further the goals of cost cutting and competitive advantage in the future. Existing assets may include those that are web based and those which are not, such as legacy back end systems (sometimes referred to as Enterprise Information Systems - EISs, which systems may stand alone and are not designed for web services) to access and store information related to an e-business or e-commerce transaction. For example, a large scale enterprise e-business application may be desired to provide For web-based purchasing of goods or services. Rather than build such an enterprise service ti~om scratch, such a service may be constructed ti~om numerous existing and new service components to ensure that a good or service purchased is delivered on time to the customer making the purchase.
As a result of the complexity and cost involved with architecting enterprise applications, much research and development has been undertaking to produce an appropriate development model.
Otle COtlltllollly used approached to developing mufti tier enterprise applications is to develop in accordance with the .IavaT"' 2 Platform. Enterprise Edition (J2EE) standard of Sun Microsystems, Ine. created in collaboration with others. (Java and all Java-based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc.) J2EE is intended to simplify enterprise applications and their development by basing the applications on standardized, modular components. .I2EE further provides a complete set of services to those components, and 1 ~ handles automatically many details of application behavior to avoid complex programming.
.12EE extends many features of the Java 2 Platform. Standard Edition for Java based applications and adds titll support for Enterprise Java Beans components. .lava Servlets AP1, Java Server Pages and Extensible Markup language (XML) technology. J2EE was developed with a view to facilitating quicker application development and deployment and to producing applications that are portable and scalable for longevity.
Mufti tier applications that require the integration of a variety of resources including legacy data and code as well as programmer skill-sets are difficult to design.
It is reported that integrating these resources can take up to ~0°ro of application development time. The ,12EE
standard wraps and embraces existing resources required by multi tier applications with a unified. component-based application model and enables co-operating components, tools.
systems, and applications for solving the strategic requirements of an enterprise.
However. J2EE component architecture is not without its limitations and disadvantages.
For example, J2EE does not provide to developers a standard way of representing and interacting with software assets without having to spend time working with unique interfaces and low-level APIs. As such, components created are otters unique to the interfaces and low-level APIs and cannot be used conveniently as building blocks to be reused in developing other applications.
J2EE component architecture is Java language based and requires that non-,lava applications be wrapped in ,12EE components via ,12EE Connector AI'CIlLtectLICe.
J2EE and its Connector Architecture do not inherently provide a model or standard for abstractly defining the functionality of an enterprise application or a consistent way of interacting with aspects of the enterprise application such as connectors, web services, messaging applications and EJB components.
In furtherance of goals related to interoperability, code re-use and component architecture for detlning and offering e-commerce and e-business applications via the protocols of the Internet. a web services model was developed. The functionality of a business application component offered via the Internet or web is described as an abstract serv.~ice such as in an XML-based document. in accordance with a standard. The description can then be shared with other developers and used to construct clients of the offered service. Access to the service is provided by web based protocols such as Simple Object Access Protocol (SOAP) over Hyper Text Transfer Protocol (HTTP). Vv'eb Services Description Language is one such XML-based language for abstractly describing web services. However, this model is directed to web services and not to enterprise applications generally, lacking an inherent capacity to deal with (i.e.
adequately describe) other protocols or bindings, componen t implementations, backend systems and their specific data requirements. Moreover, as the web protocols are relatively inefficient, the model is not embraced universally.
As such, a development model for architecting enterprise applications which addresses some or all of these shortcomings is desired.
SL!MMARY OF THE INVENTION
The present invention is directed to a service-oriented development model for enterprise applications and an integrated development environment for architecting such applications.
In one aspect of the present invention, there is provided a method for architecting an enterprise application. The method comprises creating one or more services that define said enterprise application. each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of types, the service definition conforming to a standard common for differing service provider types. The method further comprises deploying the one or more services where each service is deployed in accordance with an access definition sufficient to access the service. In accordance with this method aspect, the dii:fering service provider types comprise tw-o ~~r more types selected from:
access protocols:
software assets; resource adapted EIS services; a.~ tlow composition defining a service tivom one or more other services: and a transformer mapping one or more input messages of a particular service to an output message of the particular service.
The service definition comprises a service interface definition and a service implementation definition and, in accordance with a feature of this method, the step of creating comprises, for each service, generating a service interface definition modeling the interface of the service provider: and generating a service implementation definition describing an implementation of the service interface and the location of the implementation. The service interface definition and service implementation definition preferably comprise separate documents which documents may be XML-based and conform to the WSDL standard.
The step of deploying comprises adapting the deployed service for operation on an application server. The method may also connprise a step of defining a service proxy for accessing the deployed service and the service proxy may be defined from a portion of the service definition describing an interface to the service and the access definition for accessing the deployed service.
In accordance with another aspect of the invention there is a services toolkit for architecting an enterprise service. The services toolkit comprises a service creation component for creating one or more services that define said enterprise application, each setviee created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types. 'l~he differing sc;rvice provider types comprise two or more types selected ti~om access protocols; software assets: resource adapted EIS
services: flow compositions. each flow defining a service ti~otn one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service. IN accordance with this services toolkit, the toolkit further comprises a service deployment component for deploying the one or more services in accordance with a respective access definition sufficient to access a respective service and the services toolkit is adapted to communicate with an integrated development environment to assist with architecting the enterprise application.
The services toolkit may including one or more tools to assist with the creation of the service definition for each service provider type. Particularly, the services toolkit may comprise one or more of: a service provider browses to facilitate a selection of a service provider type to create the service definition; a service definition editor for generating a service interface detinition modeling the interface of the service provider; and at least one service implementation editor for generating a service implementation definition describing an implementation of a service interface of the service and the locatic,~n of the implementation. A
particular service implementation editor may comprises a flow editor for generating flow compositions graphically or a transformer editor for defining data transformations in accordance with a standard therefor.
I S Service definitions may comprises a service interface definition and a service implementation definition detlned by separate documents, which may be XML
documents and which XML documents may conform to the WSDL standard.
One feature of the services toolkit includes a tool for at least one of importing and exporting the service definition to facilitate creating at least one of a service and a client application to use the service. Further, the service deployment component comprises a tool for adapting the deployed service for operation on an application server and may include a service proxy wizard for creating a service proxy to access the deployed service. A
service skeleton wizard may be included to at least partially generate a service provider from a service definition.
The services toolkit may be adapted for architecting enterprise application for operation in a .12EE environment. The access protocols may be selected from protocols operable to invoke Java based components: the software assets may be selected from Java based software components; and the resource adapters may be selected tcom resource adaptors operable in accordance with Java based connector standards.
In accordance with a further aspect, the invention provides a computer program product embodied in a computer readable medium for providing instructions and data to a computer system executing an inte~~rated development environment ( IDE) for architectin g an enterprise service application. The instructions and data define a services toolkit that, when operated on said computer system, adapts the IDE to (a) create one or more services that define said enterprise application, each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types; and (b) deploy the one or more services, each deployed in accordance with an access definition sufficient to access the service. The differing service provider types comprise at least two types selected from access protocols; software assets: resource adapted EIS services: tlow compositions, each tlow defining a service from one or more other services; and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service.
In accordance with yet a further aspect, there is provided An integrated development environment (IDE) for architecting an enterprise service comprising: first means for describing a service interface to a service: second means for describing a service implementation to the service, said service implementation binding the service interface to one of a plurality service providers having one of a plurality of service provider types, the second means conforming to a standard common for differing service provider types; third means for generating a service from said first and second means: fourth means for describing a protocol sufficient to access the service; and fifth means for deploying the service in accordance with the fourth means. Ln accordance with this aspect. the differing service provider types comprise two or more types selected from access protocols; software assets; resource adapted EIS
services; flow compositions, each flow det7ning a service from one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service.
Advantageously a service-oriented architecture leverages open standards to represent virtually all software assets as services including legacy applications, packaged applications, .12EE components or Vl~'eb services. This approach provides developers with a standard way of representing and interacting with software assets without having to spend time working with unique interfaces and low-level APIs. Ivrthermore, individual software assets become building blocks that can be reused in developing other applications.
Using the service-oriented approach to integration in accordance with the present invention reduces the complexity, cost, and rill: of integration by providing a single, simple architectural framework based on mb services in which to build, deploy, and manage application functionality.
Other aspects and features oi' the present invention will become apparent to those ordinarily skilled in the art upon review ~ of the following description of specific embodiments of the invention in conjunction with the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS
In the figures which illustrate an example embodiment of this invention:
FIG. 1 schematically illustrates a computer system embodying aspects of the invention;
FIG. 2 schematically illustrates. in greater detail, a portion of the computer system of FIG. 1;
FIG. 3 illustrates, in functional block form, a portion of the memory illustrated in FIG. 2;
FIG. 4 illustrates in schematic form a service in accordance with a programming model of this invention;
FIG. 5 illustrates in schematic form a logical service bus for integrating services in an enterprise services environment according to the present invention;
FIG. 6 illustrates the architecture of a WSDL document:
FIGs. 7a, 7b, 7c and 7d illustrate, in greater detail and in functional block form, a portion of FIG. 3;
FIG. 8 illustrates in greater detail and in Iianetional block form, a portion of FIG. 3;
FIG. 9 illustrates, in greater detail and in functional block form, a portion of FIG. ~; and FIG. 10 is a t7ow chart of operations performed during the development of an enterprise services application.
DETAILED DESCRIPTION
An embodiment of the invention, computer system 100, is illustrated in FIG.1.
Computer system 100, illustrated for exemplary purposes as a networked computing device, is in communication with other networked computing devices (not shown) via network 110. As will be appreciated by those of ordinary skill in the art. network 110 may be embodied using conventional networking technologies and may include one or more of the following: local area networks, wide area networks, intranets. public Internet and the like.
Throughout the description herein, an embodiment of the invention is illustrated with aspects of the invention embodied solely on computer system 100. As will be appreciated by those of ordinary skill in the art, aspects of the invention may be distributed amongst one or more networked computing devices which interact with computer system 100 via one or more data networks such as, for example, network I 10. However. for ease of understanding, aspects of the invention have been embodied in a single computing device - computer system 100.
Computer system 100 includes processin,~~ system 102 which communicates with various input devices 104, output devices 106 and network 1 10. Input devices 104, two of which are shown, may include, for example, a keybu>ard, a mouse, a scanner, an imaging system (e.g., a camera, ete.) or the like. Similarly, output devices 106 (only one of which is illustrated) may include displays, information display unit printers and the like.
Additionally, combination input/output (I/O) devices may also be in communication with processing system 102. Examples CA9-2002-0027 1 () of conventional I/O devices include removable and fixed recordable media (e.g., floppy disk drives, tape drives. CD-ROM drives, DVD-RW drives, etc.). touch screen displays and the like.
Exemplary processing system 102 is illustrated in greater detail in FIG. 2. As illustrated, processing system 102 includes several components - central processing unit (CPL1) 202, memory 204, network interface (I/F) 2()8 and I/O I/F 210. Each component is in communication with the other components via a suitable communications bus 206 as reduired.
CPLI 202 is a p~°ocessing unit, such as an Intel Pentium'rM. IBM
PowerPCTM, Sun Microsystems LlltraSparcTM processor or the like. suitable for the operations described herein. As will be appreciated by those of ordinary skill in the art, other embodiments of processing system 102 could use alternative CPUs and may include embodiments in which one or more CPUs are employed (for example 202A, 202B, ... 202N). (_'PU 202 may include various support circuits to enable communication between itself and the other components of processing system I 02.
Memory 204 includes both persistent and volatile memory (212 and 214) for the storage of: operational instructions for execution by CPI1 202, data registers, application storage and the like. Memory 204 preferably includes a combination oi~ random access memory (RAM), read only memory (ROM) and persistent memory such as that provided by a hard disk drive.
Network I/F 208 enables communication between computer system 100 and other network computing devices (not shown) via network 1 10. Network I/F 208 may be embodied in one or more conventional communication devices. Examples of a conventional communication device include an Ethernet card, a token ring card, a modem or the like.
Network I/F 208 may also enable the retrieval or transmission of instructions for execution by CPU
202 from or to a remote storage media or device via network 110.
I/O I/F 210 enables communication between processing system 102 and the various I/O
devices 104, 106. 1/O I/F 210 may include, for example, a video card for interfacing with an external display such as output device 106. Additionally. I/O I/F 210 may enable communication between processing system 102 and a removable media 215. Although removable media 215 is illustrated as a conventional diskette other ren uovable memory devices such as ZipT"'' drives, Clash cards, CD-ROMs, static memory devices and the like may also be employed.
Removable media 215 may be used to provide instructions t~.~r execution by CPU 202 or as a removable data storage device.
The computer instructions/applications stored in memory 204 and executed by (thus adapting the operation of computer system 100 as described herein) are illustrated in functional block form in FIG. 3. As will be appreciated by those of ordinary skill in the aut, the delineation between aspects of the applications illustrated as functional blocks in FIG. 3 is somewhat arbitrary as the various operations attributed to a particular application as described herein may, in alternative embodiments. be subsumed by another application.
1 ~ As illustrated, for exemplary purposes only, memory 204 stores operating system (OS) 302, communications suite 304, IDE 306 adapted with services toolkit 308, various service providers 310a-310g (collectively 310), services 312 comprising development artifacts (shown in doted outline) and application server 314 to which the services are deployed.
OS 302 is an operating system suitable for operation with a selected CPU 202 and the operations described herein. For example, IBM AIX!K~, Microsoft Windows NTTM
or XP
ProfessionalTN', Linux (Linux is a trademark of Linus Torvalds) or the like.
are expected in many embodiments to be preferred.
Communication suite 30=1 provides, through. lzltez'actlotl with OS 302 and network I/F
2U8 (FIG. 2), suitable communication protocols to enable communication with other networked computing devices via network 110 (FIG. l ). Communication suite 301 may include one or more of such protocols such as TCPlII', Ethernet, token ring and the like.
Also stored in memory 204 (and used during the development process) and incorporating aspects of the present invention is Integrated Development Environment (IDE) 306. In the exemplary embodiment, IDE 30fi provides a developer (or a team of developers) a development environment using a graphical user interface (GUI) known to those of ordinary skill in the art.
The GUI typically includes a number of windows or panes for viewing source code, project files, debugging information or the like.
Unlike conventional IDES, IDE 306 is adapted to have services toolkit 310 "plugged in".
'through tools of the services toolkit 308, IDE 306 is able to assist developers in developing a business or enterprise services application incorporating artifacts 312 designed to use the services provided by one or more selected service providers 3I0. FIG. 4 illustrates a definition for a service in accordance with the programming model 400 of the present invention and showing exemplary service providers. A service 312 is defined using a service provider such as a software asset. for example. a Java bean 310c or stateless session Enterprise Java Bean (EJB) 310d, resource adapted EIS services (RA 310e ), such as .12EE Connector Architecture (JCA) connected or otherwise resource adapted service (for example, fr~r facilitating EIS services such as CICSu~K, IMSTM, IBM Host On Demand (HOD), and others), database assets (not shown) via a ,lava Database Connector (JDBC) and access protocols such as SOAP 310a or JMS
(not shown).
J2EE Connector architecture (JCA) is described in greater detail in the document entitled "J2EE Connector Architecture Specification", ,ISR 016, Version 1.0, Final Release, Released August 22, 2001 from Sun Microsystems, Inc. of Palo Alto. California, the contents of which are hereby incorporated herein by reference. Integrating a .ICA based resource adapter with the services toolkit is accomplished via a JCA tool plty~in. The .1C'A tool plugin is a connector architecture extension to make connectors communicate with tool environments such as an IDE
and is not specific to the present services toolkit. ~rhe tool plugin defines how to provide EIS-specit3c binding extensions and how the tool environment interacts with the EIS to get the information. Lastly°, it defines how an EIS provides code generation contributions. The tool plugin also supplies JCA Common Client Interface (CCI) extensions for EIS
system service invocations. While a tool plugin assists with working with the resource adapter, it can be directly worked using Java and EJB tools to wrap the connector functions in a Java Bean or stateless session EJB. Thereafter. the services toolkit can consume these services transparently as per other similar typed software assets.
1 ~ Additionally a service may be defined using a flow service provider 310f which may use one or more services and including a service comprising a Transform (Xform) 3108 service provider. As described in detail herein below, features like flow composition provided by flow 41? can be used to compose a new service out of other services.
Transformations provided by Xform 414 allow the mapping of data from one or more messages received by a service to an output message for the service in a flow composition.
Access to sei°vices is made available via one or more access protocols such as Simple Object Access Protocol (SOAP) run over HTTP and Remote Method Invocation (RMI) run over Internet Inter-Orb Protocol (IIOP) (not shown). RMI-IIOP delivers Common Object Request Broker Architecture (CORBATM) distributed computing capabilities to the Java 2 platform. Other service provider options may be included. such as Java Messaging Service (JMS) (not shown) as will be apparent to those of ordinary skill in the art.
The operation of IDE 306 and s~:r<~ices toolkit 308 and their interaction with service providers 310, services 312 and application server 314 is better understood with reference to FIGs 5-10 described below ~.
Services Toolkit 308 provides service-oriented development environment for business and enterprise application integration for deployment to a server such as application server 314.
With reference to FIG. 5, there is shown a logical schematic representation of memory 204 from the viewpoint of application server 314 having a logical service bus 502 that acts as the point of integration for the wide variety of services 312 offered by service providers 31 Oa-310g. Services toolkit 308 provides tools and support needed to be able to consume and provide services to server 314 via the service bus X02.
At the core of the programming model 400 of the services toolkit 308 are enterprise 1 ~ services. or services 312 for- short. Services 31 ? ace used to model different kinds of service providers 310 in a consistent way. rfhe following is an overview ~ of the programming model 400:
Data: XML Schema, Service Message Interface: Serv ice Interface Implementation: Service Binding SOAP
Java bean Stateless session EJB
JCA
Flow CA9-2002-0027 1 '_i Transformer The part of the programming model 400 that ties the elements of the model together is the service 312. Services tc.>olkit 308 employs a description mechanism namely, Web Services Description Language ( WSDL), for describing any kind of service 312. WSDI_ is sufficiently extensible to describe any kind of IT services and not simply web services.
FIG. 6 illustrates WSDL document architecture: 600 comprising an abstract service interface definition section 602 and service implementation and location definition section 604.
The service interface in WSDL is called a port~I~ype 606. PortType 606 consists of one or more operations 608 with input 610 and output 612. Input 610 and output 612 are described by lU services messages typed using XML Schema to describe the business data that flows in and out of the services.
Service implementation and location definition section 604 describes how the service interface is implemented and where it can be found. ~fhe service location is described by a service provider specific port extensibility element 6I6. The servlCe llllplelllelltatl011 IS described I~ by service provider specific extensibility elements in the binding section 618. Services toolkit 308 can be adapted to support a wide variety of service provider specific bindings such as SOAP.
JC'A. .lava Bean, Stateless session E,IB, Flow, and 'Cransform. among others, as previously described.
WSDL. provides a standard way fur describing which services arc; ot~ered by a ser~~ice provider 20 and how you access them. WSDL, in XML Ibrmat. describes 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 CA9-?002-0027 16 network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDC, is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. WSDI. can be better understood with reference to the World Wide Web s Consortium (W3C) document entitled "Web Services Description Language (WSDL) 1.1" dated March 15, 2001 the contents of which are hereby incorporated herein by reference. While the exemplary embodiment described herein utilizes VVSDL, other languages which describe services could also be employed. For example, it is contemplated that the Electronic Business XML (ebXML) language protnulgat~d. in part, by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFAC.'T) could, alternatively, be employed.
A docwnent from the Sun Microsystems, Inc. (,lava Community Process group) of Palo Alto, California entitled JSR 110 "Java APIs for WSDL" describes a proposed standard set of APIs for representing and manipulating services described by Vl~'SDL documents. These APIs define a way to construct and manipulate models of service descriptions. The contents of ",lava APIs for WSDL" is I 5 hereby incorporated herein by reference.
In accordance with the invention, flow ~ 12 and Transform (sometimes referred to as Xform) 414 are each a specific form of service implementation. Flow 412 is useful to compose a service 312 out of other services 312 while Xform 414 provides a manner of mapping between service messages, including mapping multiple input messages to a single output message. A flow consists of service nodes, each node representing the invocation of a service operation. The service nodes are tied together by control links which indicate the sequence of execution and under which condition execution takes place. The data flow between service nodes is constructed using data links. These data links can include data mapping nodes (via Xform 414) for cases when messages between service nodes do not match and a new service message is to be produced. Flow composition may be described using a markup Imguage. The transformation implementation is described in the form of XSL'i'.
XSLT (Extensible Stylesheet Language Transformation] is a language for transforming XML documents into other XML documents. XSL~T addresses the need to have data presented differently to meet the particular reduirements of an organization/individual by providing the ability to define a set of transformation ~°ules to transform the data.
XSLT can be better understood with reference to the World Wide Web Consortium (W3C) document entitled "XSL
'Transformations (XSLT) Version 1.0" dated November 16, 1999.
The development model of services toolkit 308 consists of three primary process steps:
(1) creating a service; (2) deploying a service; and (3) creating a service proxy, each of which steps is described herein below in more detail, along with the development artifacts produced.
FIGS 7a, 7b. 7c and 7d illustrate in greater detail development artitacts 312 produced by services toolkit 306, namely an exemplary service 702, an exemplary deployed service 704, an exemplary deployed services archive 705 and an exemplary service proxy 706.
Service toolkit 308 can facilitate the creation of a service in different ways. First it facilitates creation of a service for an existing provider. for example, a Java Bean, a Stateless Session EJB, resource adapted services (e.g. .1CA adapted CICS services) and others. Another form of service creation is through flow composition, where a service is created by composing it out of other services. Finally, a service may be created from scratch and from it a service provider may be created (that is, top-down development).
In accordance with an embodiment of services toolkit 308, when creating a service, the Vv'SDL defining the service is partitioned into a services interface definition embodied in a document ("interface".wsdl) comprising a WSDL, abstract service interface definition section 602 (FIG. 6) and a services implementation and binding dellnition embodied in a document ("implementation_binding".wsdl) comprising a WSDL service interface and binding section 604.
It will be understood to persons skilled in that art that the message and type descriptions of section 602 could also be in separate files. WSDL artifacts are preferably partitioned into separate tiles to facilitate re-use, separating interfaces, which may be made public, IrOnl implementation details, which may be proprietary and desired to be kept private. Further.
separation enhances transparency, permitting an implementation to change without impacting an interface.
The following Java and WSDL code samples shows how an exemplary service 702 (FIG.
7A) is created from an existing software asset type service provider (e.g.
Java Bean 404), in this case ti~om a StockQuote .lava class:
package sample.stockduote:
public class StockQuote i public float g,etQuote(String symbol) float quote = 0;
// ...
return duote;
a r Creating the service from the StockQuote ,lava class results in the creation of two WSDL
resources, one containing the StockQuote interface, namely StockQuote.wsdl 708, the other one containing the native .lava binding of the StockQuote interface. namely StockQuote.Java.wsdl CA9-2002-0027 1 ~) 710. The following WSDL sample shows the content of the StockQuote.wsdl 708 resource, including a StockQuote interface with the operation getQuote, and the service messages for the input and output of the operation.
StockQuote.wsdl: <?xml version="1.0'~ encoding="U'hF-8"'?>
<definitions name="StockQuote"' targetNamespace="http:'/stockquote.sample/"' xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns='http://stc>ckquote.samplef"
xmlns:xsd= 'http://www.w3.org/2001 /XM L.Schema'">
<message name="getQuoteRequest'~>
<part name="symbol"" type--'xsd:string"/>
</message>
<message name="getQuateResponse">
<part name="result"~ type="xsd:float" ;'>
</message>
<portType name--"StockQuote'">
<operation name="getQuote"" parameterOrder="symbol"'>
<input tllesSage=="tnS:~etQLlotelZ~C~LIeSt"" name--"getQuoteRequest"/>
<output message="tns:getQuoteResponse"" name="getQuoteResponse~"/>
</operation>
</portType>
</definitions>
'the following WSDL sample shows the content of the StockQuoteJava.wsdl 710 resource with the StockQuote .lava class as the f°ndpoint in the port section, and the native Java 2~ binding that references the interface defined in St.ockQuote.wsdl 7()8.
StockQuoteJava.wsdl: <''~ml version-- '1.0"' encoding="UTF-8"'?>
<detinitions name="StockQuoteJava'"
targetNamespace="http:/!stockquote.sample/"' xmlns="http://schemas.xmlsoap.org; wsdl;"
xmlns:tbrmat="http:; /schemas.xmlsoap.org/wsdl/formatbinding/"
xmlns:java="http://schemas.xmlsoap.org/wsdl/java/"' xmlnsans="http:/istockduote.sample/""
xmlns:xsd="http://wvw.w3.org/2001 /XMhSchema">
<import location="StockQuote.wsdl"' namespace="http://stoekquote.sample/""/>
<binding name="StockQuote,lavaBinding"" type="tns:StockQuote"">
<j ava: bi nding/>
<formataypeMapping encoding=",lava" style=",lava"'>
<format:typeMap formatType="float'" typeName="xsd:tloat'"/>
<format:typeMap formatType='java.lang.String"" typeName="xsd:string"/>
</formataypeMapping>
<operation name="getQuote'">
<java:operation methodName="getQuote"~ parameterOrder="symbol"' returnPart="result'"i>
<input name="getQuoteRequest'"/>
<output name--"getQuoteResponse'"/>
</operation>
</binding>
<service name="StockQuoteSemice~"=
<port binding="tns:StockQuoteJavaBinding'" name-- 'StockQuoteJavaPort'">
<java:address className="sample.stockquote.StockQuote""/>
</port>
</service>
</delinitions>
When deploying a service to a server, additional definitions are provided for the inbound bindings by which the service is made accessible to a client application (not shown). An inbound binding is an outbound binding that a client of the service must use to invoke the service as described further below with respect to service proxies. In accordance with an embodiment of the services toolkit 308, an inbound binding may be a SOAP binding or a EJB
binding which makes the service accessible by using the EJB programming model. Services toolkit 308 may also be adapted to support other inbound/outbound bindings such as JMS and others. FIG. 7b shows service 702 accessible through the SOAP protocol. That is FIG. 7b shows an exemplary CA9-2002-0027 2 l deployed service 704 comprising service 702 and one or mode additional inbound binding WSDL files, namely StockQuoteSOAP.wsdl 71:?. The inbound binding tiles contain the service location information as well as the inbound binding to the service interface.
The following WSDL sample code lists the content of the StockQuoteSOAP.wsdl resource. with the SOAP address as the endpoint in the port section, and the SOAP binding referencing the interface defined in StockQuote.wsdl 708.
StockQuoteSOAP.wsdl: ~~'?xml version='°1.0'~ encoding="L1TF-8'"?>
<detinitions name="StockQuoteSOAPBinding'' targetNamespace="http:!/stockquote.samplef"
xmlns="http://schemas.xmlsoap.orgiwsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlnsans="http:/istockquote.sample/"=
<import location="StockQuote.wsdl"
namespace="http://stockquote.sample/' ~'>
<bindin~ name="StockQuoteSOAPBinding" type="tns:StockQuote"'>
<soap:binding style--'rpe" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getQuote">
<soap:operation soapAction="urn:StockQuote"' style="rpe"/>
<input name="getQuoteRequest'">
<soap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/'"
namespace= 'urn:StockQuote" parts= 'symbol"' use="encoded"/>
</input>
<output name="getQuoteResponse">
<soap:body encodingStyle=''http://schemas.xmlsoap.org/soap/encoding/"' namespace="urn:StockQuote"' parts="result"' use="encoded"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
CA9-2002-0027 2:?
<port binding="tns:StockQuoteSOAPBinding~~
name="StockQuoteSOAPfort ~>
<soap:address location="http:// localhost:8080/Services-SOAP/servlet/rpcrouter"/>
</po rt>
</service>
</deflnitions>
Services toolkit 308 also generates a thin stateless session EJB wrapper (i.e.
bindings) StockQuoteE,lB.wsdl 713 for the service 702. StockQuoteEJB.wsdl describes the thin stateless session EJB wrapper. Standard EJB deployment descriptor definitions can be used to specify additional Quality of Service (QOS) attributes for the deployed service, for example, security and transactional attributes as will be apparent to those of ordinary skill in the art.
Deployed services are installed into application server 314 by packaging them into a ,12EE enterprise archive ( EAR) file such as exemplary archive 7(.)5 as shown FIG. 7c. Exemplary archive 705 illustrates exemplary deployed service 704 for a stock quote service together with additional deployed services 714 and 716 for a purchase order service and a customer information service, respectively, in L:AR "Myservices.ear" 70~. StockQuote service 704 is accessible through SOAP and provided by a .Java class. PurchaseOrder service 714 is accessible through SOAP and provided by a l7ow and CustomerInfo service 716 accessible through SOAP
and provided by a resource adapted CICS service.
FIG. 8 illustrates how a deployed service, such as C ustomerInfo 716, manifests itself in server 314. In this sample, deployed service 716 is provided by a CICS service requiring a resource adapter such as a ,ICA service provider. Deployed service 716 is accessible from the client side by the SOAP protocol (for example as a web service) and the EJB
programming model (for example for a more local, private invocation). As described above.
deployed service 716 comprises service 802 having interface and implementation artifacts 804 and 806, respectively, and inbound bindings development artifacts 808 and 810. The artifacts 808 and 810 are tiles "customerInfoSOAP.wsdl" and "Custon nerlnfoE.lB.wsdl" providing binding descriptions to the application server components 812 and 814 for SOAP and RMI-IIOP object request broker (ORB) access. The artifacts 804 and 806 are the tiles "Customerlnfo.w~sdl" and "C'ustomerInfoClCS.wsdl" providing descriptions of the target CICS service to session bean component 816 including a JCA CICS connector run-time component 818. Server component 812 receives and responds to service invocation requests (e.g. remote procedure calls (RPC)) via SOAP over HTTP protocols. Using artifact 808, the SOAP server component determines the particulars for service invocation. In the present example. SOAP provides a front end to the session EJB 816. Session EJB 816 recognizes the request and invokes the CICS
service. Session EJB 816 acts as a proxy to the CICS service to provide the result. Similarly, ORB run-time component 814 may receive a RMI-IIOP invocation for session EJB 816 and pass the invocation through. When the eustomerlnfo service is deployed. an EJB deployment descriptor for session EJB 816 is generated from the corresponding WSDI. information 810 and ORB
component 814 is configured with this deployment descriptor. The deployment descriptor provides a way to route an incoming RMI-IIOP request to the appropriate session bean.).
Creating a service proxy. such as exemplary proxy 706 illustrated in FIG. 7d, involves creating a .lava Bean which may be invoked by a client application (not shown) to access a deployed service, for example, exemplary deployed service 704. A service proxy is generated ti-otn a service interface for the service to be invoked and an outbound binding that describes how to access the service interface. The outbound binding used by the proxy is the inbound binding with which the service is deployed. As such, exemplary service proxy 706 for exemplary deployed service 704 comprises interface StockQuote.wsdl 708 and binding StockQuoteSUAP.wsdl 712.
Services toolkit 308 provides a set of toi:>l components, such as wizards and editors etc., to simplify business and enterprise application integration tasks. The tool components are grouped and presented conveniently in a service perspective or view, which extends base tool components available in a typical IDE. For simplicity, the set of tool components is referred to as the services toolkit. FIG. 9 shows the tool component architecture of services toolkit 308 along with the development artifacts produced by the tool components.
A main function of the services toolkit ;>08 is the facilitation of service definitions 902.
Various tools aid a user to create and edit the different aspects of service definitions 902 and to use the definitions 902 to create additional development artifacts 904 and 906 for an application server, such as server 314, and for a service client (not shown).
Services toolkit 308 provides a graphic user interface (GLJI) for working with service definitions having customizable perspectives for presenting views to promote role-based development. A service perspective custumizes the layout of the GUI to facilitate the development of enterprise services containing the views of various resources for use to develop such services. As is commonly understood to persons skilled in the art, there are several ways to Launch tool components from a perspective in a GUI-based IDE including a toolbar, pop-up menu choices and a resource creation dialog or wizard.
A service view contained in the perspective provides a view of service resources such as three folders comprising, respectively, service projects containing service definitions; deployed services containing the services that have been deployed; and resource adapters containing one or more JCA or CCF or other resource adapters added (i.e. plugged in) to the IDE for facilitating services from EISs. A service project wizard (not shown) is provided for creating and manipulating service projects.
A service provider browses 907 provides a central tool to create services from existing service providers collectively 310 such as Java Qeans, Stateless Session EJBs, 3270 Terminals, and EIS systems made accessible by the .ICA Tool Plugin as described previously. The browses 907 presents the services and options offered by a particular service provider type to the user. A
service definition wizard and editor 908 assists with creating new service definitions (that is, WSDL. documents in the present embodiment). Service definition editor 908 is provided for editing these definitions, providing source editing as well as a browses style design editing capability.
As noted previously. XML schema definitions are used in service detlnitions to type service messages, modeling business data. A XML. schema wizard and editor 910 allows a user to create XML schema definitions. A I7ow wizard and editor 912 facilitates the creation of a service implementation by flow, composing the service out of other services.
Flow editor 912 is a graphical composition tool that allows scripting of services visually. To use services in a flow composition, services represented by icons are simply dragged and dropped from the service view into the flow editor 912. The I7ow of control between the services gets expressed by control links. the flow of data by data links which can contain data mappings when necessary.
In conjunction with the flow editor 912, a transformer wizard 914 creates message transformations to define mappings between service messages. The resulting transformer is itself a service and its operation is implemented using the XSL r specification as discussed previously.
UDDI Browses 916 facilitates importing service definitions from a Universal Description. Discovery, and Integration (UDDI) registry for web services. UDDI
provides a "meta service" for locating web services useful in private as well as public deployments. Once imported, the service definition may be used like any other service definition created with the services toolkit 308, for example, in a flow. A UDDI Export function exports service definitions for deployed web services to a llDDI registry so that other registry users can find and use the service.
Though not illustrated, a service skeleton wizard creates service provider skeletons from service definitions. The skeleton tool examines the service definition and generates an implementation skeleton from the definition. This tool can be used for a top-down approach to creating a service provider; that is, starting with the service definition and then creating the implementation.
A deployment wizard 918 creates deployed services from service definitions, such as exemplary deployed service 930 comprising exemplary service 932, into an Enterprise Archive (EAR) tile (for example file 90G) that can be installed into an application server 314. For each deployed service a thin stateless session bean wrapper 936 gets generated, and inbound bindings 938 can be configured through which the service should be accessible.
CA9-2002-0027 2'7 A service proxy wizard 920 creates proxies (such as a Java Bean proxy 904) for services to simplify interactions between deployed services 930 and client applications operating in a run-time environment 90~.
Services toolkit 308 may be adapted or associated with server tools (not shown) for use with a test environment, which can be used to eftlciently test deployed services. Server tools may be employed to set up a test server (not shown) and an association may be made between the E~1R tile that contains deployed services for testing with the test server. A
first level of testing can be done using a generic EJB test client to exercise the session EJB that was created for the service. A next level of test would be to create a ,lava proxy to exercise the deployed service, for example, to access the service using the SOAP protocol. In each case, a Java debug environment is used to debug Java code and the code generated by the services toolkit.
Use of IDE 306 and services toolkit 308 is described herein below by way of example and with reference to operations 1000 of FI(J. 10. The example relates to the use of Java bean based services to compose a new service through flow composition. The composed service is then deployed into an application server and made accessible through the SOAP
protocol. A Java proxy is created to make the SOAP service accessible from a Java application.
Upon start-up of operations 1000. IDE 306 adapted with services toolkit 308 launches a services perspective offering access, such as via a toolbar or pop-up menu choices, to tool components needed to accomplish service development tasks (Step 1002). To create a service project to contain the service definitions created in accordance with the following exemplary steps, a service project wizard may be employed and the requested particulars provided (Step 1004). After the service project is created, service provider bi°owser 906 is employed to create service definitions from existing service providers 907 (Step 1006). Service provider browses 906 informs the user about which service providers 907 are available, for example. ,lava classes, stateless session EJBs, 3270 Terminal services. resource adapters or connectors for EIS or other le~~acy services such as CICS, and others.
Service provider browses 906 may be launched from within a service project and the service provider type to be used is selected. In the present example, the services are based on Java classes. and the Java class services option is selected (Step 1008).
Thereafter, service provider browses 906 facilitates tine browsing of available Java classes to select one or more desired classes to add the class' service definition to the service project (Step 1010). The .lava classes themselves may have been previously created in the service project using the Java IDE
tools that are part of IDE 306 or those classes could be contained in any other Java project.
Following selection of particular Java classes, a service definition is created using the service definition editor (Step 1012). Simply and advantageously, only a service interface (portType) and its associated messages as described previously need be created in an interface WSDL document artifact. Service definition editor 908 may offer design and source editing such as by way of different views as will be understood by persons of ordinary skill in the art.
Thereafter. the service implementation WSDL document for the service interface is constructed using on of the service implementation editors, in this example, flow editor 912 for Ilow composition (Step 1014). Flow editor 912 is used to visually compose a new service out of other existing services. Service definitions created previously from .lava classes in the services perspective may be dragged and dropped into the flow editor. Control links between services are added, for example, visually represented by connecting a line between the services and defined CA9-2002-0027 2~) to control the sequence in which a tlow executes. The passing of data is controlled through data links comprising data maps for cases where message types do not match between services. Such may be defined with transformer wizard '~ 14. Flow editor 912 constructs a service implementation WSDI. artifact.
Once the flow-based service (e.g. 932) is determined. the service is deployed to an application server 314. In accordance with the present example. the services are packaged as a Stateless Session EJB and given further access by SOAP protocol bindings. In order to deploy the service as described (Step 1016), the service is packaged into au Enterprise Archive (EAR) file (e.g. 934) and the archive comprising the service is then installed into the application server 314 using the deployment wizard 918. The inbound bindings are selected to specify how access to the service will be provided. In this example, the SOAP protocol is selected. In the deployed services section of the services perspective view, the results (i.e.
artifacts) of the deployment step are displayed. The artifacts comprise the Stateless Session E.IB wrapper, the E.IB binding WSDL
file 936, and the SOAP binding WSDL tile 938.
Once the application server is started with this EAR, the flow-based service can either be accessed using the EJB programming model or through SOAP. The SOAP binding WSDL tile 938 can be published for public use (for' example. via UDDI Export 916 with the service interface WSDL) to make the service accessible via a registry (publicly or not) and the EJB
bindings 936 and the EJB wrapper details may be restricted.
The SOAP binding WSDL tile 938 that provides inbound descriptors for the application server side also provides outbound binding descriptors for a client application. Service proxy wizard 920 can be employed to create a Java proxy via SOAP 905 protocol to the deployed service 930.
The services-oriented architecture described herein is intended to allow developers to tie .lava and non-Java applications together with existing Web services to create logical flow-based enterprise services. Users can make such services available on an application server and even expose the services as a Web service. An IDE as adapted by the services toolkit described above and application server help build new applications that integrate with existing assets by leveraging a service-oriented architecture to reduce the complexity of large-scale application development and promote reuse by offering a standard way of representing and interacting with virtually all software assets. Integrated worki~ow increases productivity by enabling developers to visually choreograph interactions between software assets. Advanced transactional connectivity capabilities help developers avoid custom coding by providing extended transactional support for the many challenges related to integrating existing software assets with a J2EE environment.
As will be appreciated by those skilled in the art, modifications to the above-described embodiment can be made without departing from the essence of the invention.
For example, in addition to or in lieu of SOAP inbound bindings. JMS or other middleware service bindings can be Used for deployed services. While services toolkit 308 is provided to create the WSDL files and other artifacts, it will be appreciated by those of ordinary skill in the art that such artifacts may be created without toolkit assistance.
While one (or more) embodiments) ~:~f this invention has been illustrated in the accompanying drawings and described above, it will be evident to those skilled in the art that changes and modifications may be made therein without departing ti~om the essence of this invention. All such modifications or variations are believed to be within the sphere and scope of the invention as defined by the claims appended hereto. Other modifications will be apparent to those skilled in the art and, therefore, the invention is defined in the claims.
Claims (28)
1. A method for architecting an enterprise application comprising:
creating one or more services that define said enterprise application, each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types; and deploying the one or more services. each deployed in accordance with an access definition sufficient to access the service:
wherein said differing service provider types comprise at least two types selected from:
access protocols; software assets; resource adapted EIS services; a flow composition defining a service from one or more other services; and a transformer mapping one or more input messages of a particular service to an output message of the particular service.
creating one or more services that define said enterprise application, each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types; and deploying the one or more services. each deployed in accordance with an access definition sufficient to access the service:
wherein said differing service provider types comprise at least two types selected from:
access protocols; software assets; resource adapted EIS services; a flow composition defining a service from one or more other services; and a transformer mapping one or more input messages of a particular service to an output message of the particular service.
2. The method of claim 1 wherein the service definition comprises a service interface definition and a service implementation definition and wherein the step of creating comprises, for each service:
generating a service interface definition modeling the interface of the service provider;
and generating a service implementation definition describing an implementation of the service interface and the location of the implementation.
generating a service interface definition modeling the interface of the service provider;
and generating a service implementation definition describing an implementation of the service interface and the location of the implementation.
3. The method of claim 2 wherein the service interface definition and service implementation definition comprise separate documents.
4. The method of claim 3 wherein the documents conform to the WSDL standard.
5. The method of claim 2 including the step of publishing the service interface definition and access definition to facilitate creating a client application to use the deployed seance.
6. The method of claim 1 wherein the step of deploying comprises adapting the deployed service for operation on an application server.
7. The method of claim 1 further comprising a step of:
defining a service proxy for accessing the deployed service.
defining a service proxy for accessing the deployed service.
8. The method of claim 7 wherein the service proxy is defined from a portion of the service definition describing an interface to the service and the access definition for accessing the deployed service.
9. A services toolkit for architecting an enterprise service comprising:
a service creation component for creating one or more services that define said enterprise application, each service created in accordance with a service definition modeling one of a plurality service, providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types, the differing service provider types comprising at least two types selected from: access protocols; software assets; resource adapted EIS services; flow compositions. each flow defining a service from one or more other services; and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service: and a service deployment component for deploying the one or more services, each deployed in accordance with an access definition sufficient to access the service:
wherein the services toolkit is adapted to communicate with an integrated development environment to assist with architecting the enterprise application.
a service creation component for creating one or more services that define said enterprise application, each service created in accordance with a service definition modeling one of a plurality service, providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types, the differing service provider types comprising at least two types selected from: access protocols; software assets; resource adapted EIS services; flow compositions. each flow defining a service from one or more other services; and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service: and a service deployment component for deploying the one or more services, each deployed in accordance with an access definition sufficient to access the service:
wherein the services toolkit is adapted to communicate with an integrated development environment to assist with architecting the enterprise application.
10. The services toolkit of claim 9 wherein the service creation component comprising one or more tools to assist with the creation of the service definition for each service provider type.
11. The services toolkit of claim 10 comprising a service provider browses to facilitate a selection of a service provider type to create the service definition.
12. The services toolkit of claim 9 wherein the service definition comprises a service interface definition and wherein the service creation component comprises:
a service definition editor for generating a service interface definition modeling the interface of the service provider.
a service definition editor for generating a service interface definition modeling the interface of the service provider.
13. The services toolkit of claim 9 wherein the service definition comprises a service implementation definition and wherein the service creation component comprises:
at least one service implementation editor for generating a service implementation definition describing an implementation of a service interface of the service and a location of the implementation.
at least one service implementation editor for generating a service implementation definition describing an implementation of a service interface of the service and a location of the implementation.
14. The services toolkit of claim 13 wherein one of the at least one service implementation editors comprises a flow editor for generating flow compositions graphically.
15. The services toolkit of claim 13 wherein one of the at least one service implementation editors comprises a transformer editor for defining data transformations in accordance with a standard therefor.
16. The services toolkit of claim 9 wherein the service definition comprises a service interface definition and a service implementation definition defined by separate documents.
17. The services toolkit of claim 16 wherein the documents are XML documents.
18. The services toolkit of claim 17 wherein the XML documents conform to the WSDL
standard.
standard.
19. The services toolkit of claim 9 including a tool for at least one of importing and exporting the service definition to facilitate creating at least one of a service and a client application to use the service.
20. The services toolkit of claim 9 wherein the service deployment component comprises a tool for adapting the deployed service for operation on an application server.
21. The services toolkit of claim 9 comprising:
a service proxy wizard for creating a service proxy to access the deployed service.
a service proxy wizard for creating a service proxy to access the deployed service.
22. The services toolkit of claim 21 wherein the service proxy wizard is operable with the access definition and the service definition to generate the service proxy.
23. The services toolkit of claim 9 comprising a service skeleton wizard to at least partially generate a service provider from a service definition.
24. The services toolkit of claim 9 wherein the enterprise application is operable in a J2EE
environment.
environment.
25. The services toolkit of claim 24 wherein the access protocols are selected from protocols operable to invoke java based components; wherein the software assets are selected from java based software components; and wherein the resource adapters are selected from resource adaptors operable in accordance with Java based connector standards.
26. A computer program product embodied in a computer readable medium for providing instructions and data to a computer system executing an integrated development environment (IDE) for architecting an enterprise service application, said instructions and data defining a services toolkit that when operated on said computer system, adapts said IDE to:
create one or more services that define said enterprise application. each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types; and deploy the one or more services, each deployed in accordance with an access definition sufficient to access the service;
wherein the differing service provider types comprise at least two types selected from:
access protocols; software assets; resource adapted EIS services; flow compositions. each flow defining a service from one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service.
create one or more services that define said enterprise application. each service created in accordance with a service definition modeling one of a plurality service providers having one of a plurality of service provider types, the service definition conforming to a standard common for differing service provider types; and deploy the one or more services, each deployed in accordance with an access definition sufficient to access the service;
wherein the differing service provider types comprise at least two types selected from:
access protocols; software assets; resource adapted EIS services; flow compositions. each flow defining a service from one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service.
27. An integrated development environment (IDE) for architecting an enterprise service comprising:
first means for describing a service interface to a service;
second means for describing a service implementation to the service. said service implementation binding the service interface to one of a plurality service providers having one of a plurality of service provider types, the second means conforming to a standard common for differing service provider types, the differing service provider types comprising at least two types selected from:
access protocols: software assets; resource adapted EIS services; flow compositions, each flow defining a service from one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service;
third means for generating a service from said first and second means;
fourth means for describing a protocol sufficient to access the service; and fifth means for deploying the service in accordance with the fourth means.
first means for describing a service interface to a service;
second means for describing a service implementation to the service. said service implementation binding the service interface to one of a plurality service providers having one of a plurality of service provider types, the second means conforming to a standard common for differing service provider types, the differing service provider types comprising at least two types selected from:
access protocols: software assets; resource adapted EIS services; flow compositions, each flow defining a service from one or more other services;
and transformers each transformer mapping one or more input messages of a particular service to an output message of the particular service;
third means for generating a service from said first and second means;
fourth means for describing a protocol sufficient to access the service; and fifth means for deploying the service in accordance with the fourth means.
28. The IDE of claim 27 wherein the first, second and fourth means comprise XML-based documents.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002420786A CA2420786A1 (en) | 2003-03-04 | 2003-03-04 | Enterprise services development model |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002420786A CA2420786A1 (en) | 2003-03-04 | 2003-03-04 | Enterprise services development model |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2420786A1 true CA2420786A1 (en) | 2004-09-04 |
Family
ID=32913621
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002420786A Abandoned CA2420786A1 (en) | 2003-03-04 | 2003-03-04 | Enterprise services development model |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2420786A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102902543A (en) * | 2012-09-29 | 2013-01-30 | 山东浪潮齐鲁软件产业股份有限公司 | Web service application framework model |
-
2003
- 2003-03-04 CA CA002420786A patent/CA2420786A1/en not_active Abandoned
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102902543A (en) * | 2012-09-29 | 2013-01-30 | 山东浪潮齐鲁软件产业股份有限公司 | Web service application framework model |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20040177335A1 (en) | Enterprise services application program development model | |
| US20050262130A1 (en) | Input data specification method and system in business-to-business integration | |
| US7546606B2 (en) | System and method using a connector architecture for application integration | |
| US6948174B2 (en) | IMS MFS (message format service) metamodel | |
| US7747983B2 (en) | System and method for generating a web service definition and database schema from wireless application definition | |
| US7487513B1 (en) | Web service archive | |
| US7617480B2 (en) | System and method for a Web service virtual interface | |
| US7490331B2 (en) | Mapping to and from native type formats | |
| US20080141139A1 (en) | Architecture and Process for Presenting Application Content to Clients | |
| CA2685892A1 (en) | Xml push and remote execution of a wireless applications | |
| WO2004021220A1 (en) | System for web service generation and brokering | |
| WO2004021142A2 (en) | System for runtime web service to java translation | |
| US20060047709A1 (en) | Technology independent information management | |
| Ferrara et al. | Programming. NET web services | |
| WO2003034183A2 (en) | System and method using a connector architecture for application integration | |
| Binildas | Service oriented architecture with Java | |
| Curbera et al. | Toward a programming model for service-oriented computing | |
| Zhang et al. | Service-oriented architecture | |
| CA2420786A1 (en) | Enterprise services development model | |
| EP1715431B1 (en) | System and method for developing mappings between different message structures | |
| Madiajagan et al. | Interoperability in component based software development | |
| Zhu | Developing web-based mapping applications through distributed object technology | |
| Hansen et al. | Web services: an architectural overview | |
| CA2543501C (en) | System and method for generating a web service definition and database schema from wireless application definition | |
| Mykkänen et al. | Component and Service Technology Families |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued | ||
| FZDE | Discontinued |
Effective date: 20100304 |