Components of the Web Services Interoperability Basic Profile [WS-I BP]
To a business person like Mr. X, the Web services approach is all about integration: functionality within an organization or integrating applications between his different business partners. Therefore, the components that would help him in integrating his setup require him to build up a web service inclusive of the UDDI, DISCO, WSDL, and SOAP components.
This application integration allows time and cost efficiencies for receiving purchase orders, answering status inquiries, processing shipment requests, and so on. The key point is that application integration is exposed to all the business partners without any obstruction. However, the fundamental aspect is that Mr. X is independent of any platform and can view the status of his business anywhere, anytime around the globe.
If another supplier has a better price, shipping terms, or quality assurance, then a Company’s reorder systems can be easily repositioned to use that supplier; doing so is as easy as pointing a Web browser at a different Web site. With a broader adoption of Web services and XML document format standards, this style of dynamic business partner integration will become more broadly used.
Interoperability
Interoperability is the felicity of a software interface working with diverse and varied software systems swiftly and at ease for providing special finesse and rhythm to web services’ network and its operations.
Here, web services signify utilising “standardised” interfaces for purposes of communication, integration and dexterity of information between applications in an autonomous environment. Interoperability of web services is, thus, streamlining the web operations through ever more refined technological software impetus. For standardising interoperability of web services, the Accenture, BEA Systems, Fujitsu, HP, IBM, Intel, Microsoft, Oracle and SAP have also formed the new Web Services Interoperability Organisation (WS-I) in 2002 (xml.coverpages.org 2002). In simple words, “Interoperability of Web Services” means developing swift and user friendly Internet system and softwares.
There is also a noted RAND study highlighting a military perspective on interoperability. They extend a much broader view of this matter. They are also suggesting multi-level interoperability (Davis and Anderson, 2003). Tolk, Diallo Turnitsa and Winters LS have discussed various levels of interoperability (2006). Turnitsa (2005) and Tolk (2006) provide the following self-explanatory diagram and explanation:
- Level 0: Stand-alone systems without any Interoperability.
- Level 1: On the level of Technical WSI, a communication protocol exists for exchanging data between participating systems. On this level, a communication infrastructure is established allowing systems to exchange bits and bytes, and the underlying networks and protocols are unambiguously defined.
- Level 2: The Syntactic WSI level introduces a common structure to exchange information; i.e., a common data format is applied. On this level, a common protocol to structure the data is used; the format of the information exchange is unambiguously defined.
- Level 3: If a common information exchange reference model is used, the level of Semantic WSI is reached. On this level, the meaning of the data is shared; the content of the information exchange requests are unambiguously defined.
- Level 4: Pragmatic WSI is reached when the interoperating systems are aware of the methods and procedures that each system is employing. In other words, the use of the data – or the context of its application – is understood by the participating systems; the context in which the information is exchanged is unambiguously defined.
- Level 5: As a system operates on data over time, the state of that system will change, and this includes the assumptions and constraints that affect its data interchange. If systems have attained Dynamic WSI, they are able to comprehend the state changes that occur in the assumptions and constraints that each is making over time, and they are able to take advantage of those changes. When interested specifically in the effects of operations, this becomes increasingly important; the effect of the information exchange within the participating systems is unambiguously defined.
- Level 6: Finally, if the conceptual model – i.e. the assumptions and constraints of the meaningful abstraction of reality – are aligned, the highest level of interoperability is reached: Conceptual WSI. This requires that conceptual models are documented based on engineering methods enabling their interpretation and evaluation by other engineers. In essence, this requires a “fully specified, but implementation independent model” as requested by Davis and Anderson.
The LCIM shows that a layered approach to support Composable services is necessary. The WSI standards are not able to manage all levels, in particular not with the M&S specific upper layers. It is worth mentioning, however, that the LCIM focuses on technical support by information systems, such as command and control information systems in the military context. As Alberts and Hayes point out in the organisational and social aspects are often even more important. Tolk proposes such a layered framework for measures of merits dealing with questions like tactical or strategic alignment of objectives or even political will of coalition partners in. Within this contribution, however, the focus will be on the information system aspects.
How web service technology (WST) is likely to compete with or complement existing EDI (electronic data interchange) initiatives in the manufacturing and logistic sectors?
WST competes EDI in the form of HTML based applications that are consumer oriented. One common example is the usage of B2B and B2C services. However WS (Web Service) competes through SOAP (Simple Object Access Protocol) that uses http and XML to encode and transmit application data.
How Mr. X might identify suitable trading partners and how he and his prospective partners might define suitable interfaces between their respective systems?
Mr. X would only select those partners to get along with who often use reliable web application services like SOAP and who knows how to get maximum advantage of those web services. In order to select reliable partners Mr. X would make use of service DISCOVERY in such a manner that discovery can be fully utilised at application design time or at runtime. During application time, a designer, through a browser or other user interface, performs a find operation on a service registry, examines the result of the find, and incorporates the service description returned by the find into application logic.
Pros and Cons of XML Messaging based on SOAP
Pros and cons include composability as the realm of the model and interoperability as the realm of the software implementation of the model. In addition, their research introduces Integretability coping with the hardware-side and configuration side of connectivity. The author supports this categorisation and recommends the following distinction when dealing with issues of simulation system interoperability, to include meaningful simulation-to-simulation system interoperation:
- Integretability contends with the physical/ technical realms of connections between systems, which include hardware and firmware, protocols, etc.
- Interoperability contends with the software and implementation details of WSI interoperations, including exchange of data elements based on a common data interpretation, etc.
- Composability contends with the alignment of issues on the modeling level of WSI. The underlying models are purposeful abstractions of reality used for the conceptualisation being implemented by the resulting simulation systems.
Slight variations between the way.NET implements SOAP and SOAP::Lite’s implementation of SOAP, for example, cause some difficulty in allowing the two to work together out of the box. To illustrate the problem, follow the steps shown here.
Interoperability Issues
First, launch the Java TcpTunnelGui tool that ships with Apache SOAP, specifying port 8080 as the local listening port, and redirecting to whatever server you have your HelloWorld.asmx file deployed to:
C:book>start java org.apache.soap.util.net.TcpTunnelGui 8080 localhost 80.
Then, modify the Perl Hello World client to point to the HelloWorld.asmx file, but replace the server part of the URL with localhost:8080.
When you run the Perl script:
C:book>perl hello_client1.pl James
The result is not what you would expect. The script ends without ever displaying the
“Hello James” result. If you take a look at the TcpTunnelGui tool, you’ll see that the
SOAP message is sent, but the.NET runtime rejects the request and issues a SOAP
fault in response. This is shown in Example 3-1.
Example 1-1: SOAP fault from.NET
soap:Client
System.Web.Services.Protocols.SoapException: Server did
not recognise the value of HTTP Header SOAPAction:
urn:Example#sayHello.
at System.Web.Services.Protocols.SoapServerProtocol.Initialise( )
at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response).NET requires that the HTTP SOAPAction header be used to exactly identify the operation on which service is being invoked..NET requires the format of the SOAPAction header to be the service namespace, followed by a forward slash, followed by the name of the operation, or urn:Example/sayHello. Notice, though, that SOAP::Lite’s default is to use a pound sign (#) to separate the service namespace from the name of the operation. This wasn’t an issue when we were invoking Java services with SOAP::Lite because Apache SOAP simply ignores the SOAPAction header altogether.
To fix this problem, we must explicitly tell SOAP::Lite how to format the SOAPAction header. To do so, make the change to the client script highlighted in Example 1-2
Example 1-2: Fragment showing change to Perl client script
print SOAP::Lite
-> uri(‘urn:Example1’)
-> on_action(sub)
-> proxy
-> sayHello($name)
-> result. “nn”;
The on_action method in SOAP::Lite allows the developer to override the default behavior and specify a new format for the SOAPAction header.
However, even with this change there’s still a problem. The script will appear to run, but rather than returning the expected Hello James string, all that will be returned is Hello. The name is missing from the response! This happens because.NET requires all parameters for a method call to be named and typed explicitly, whereas Perl does not do this by default. Again, take a look at the TcpTunnelGui tool and look at the SOAP message sent to the HelloWorld.asmx service from SOAP::Lite. This is shown in Example 1-3.
Example 1-3: The Perl-generated SOAP request sent to the.NET service
Notice the oddly named c-gensym3 element that contains the input parameter. Because Perl is a scripting language that does not support strong typing or strict function signatures, method parameters do not have names, nor do they have types. When SOAP::Lite creates the SOAP message it automatically generates an element name and sets all parameters to the string data type..NET doesn’t like this behavior. If the C# method is written to take a String parameter called name it expects to find an element in the SOAP envelope called name with a type of xsi:type=”xsd:string”. In XML, that would be as shown in Example 1-4
Example 1-4: A SOAP request encoded by.NET
<name xsi:type=”xsd:string”>
James
</name>
The.NET beta also did not properly recognise that the name element is declared as part of the same namespace as its parent sayHello element. This is a standard rule of XML namespaces. To get SOAP::Lite working with.NET, we must tell SOAP::Lite the name, type, and namespace of each of the parameters we are passing into the operation, as shown in Example 1-5
Example 1-5: Perl client modified to work with.NET
use SOAP::Lite;
my $name = shift;
print “nnCalling the SOAP Server to say hellonn”;
print “The SOAP Server says: “;
print SOAP::Lite
-> uri(‘urn:Example1’)
->on_action(sub)
->proxy
->sayHello(SOAP::Data->name(name => $name)->type->(‘string’)
->uri(‘urn:Example1’))
->result. “nn”;
Now, run the script and you will see that everything works as expected.
Web Services or Technologies used within the business
Enterprise Application Integration (EAI) and Business to Business (B2B) :
EPI is still a field where large consulting companies command multimillion dollar contracts to help their clients deal with a mess of applications that were never meant to interoperate. These systems are often extremely difficult to change, let alone integrate with other systems. These applications often define unique data formats, and sometimes (for historical, often performance-related reasons) even define their own communications protocols. Furthermore, many systems, particularly in large organisations can exist on multiple different platform technologies. Interoperability between systems is a significant challenge. In many organisations, particularly organisations that result from a merger of two previously independent companies, IT integration costs can seriously impact the financial health of the company.
The WSI offers advanced technologies by which existing systems can be implemented, thereby making available the integration of other systems within the organisation. Applications exposed are accessible by all other machines running on different hardware platforms and written in different programming languages. Using this approach, the complexity of these systems can be encapsulated behind industry-standard XML protocols. Pair-wise system integration projects can be replaced with one-to-many systems interactions based on Web services. The promise of higher-level WSI requires initiatives to be taken that will be able to develop the set of standards, technologies, and tools that will enable small and large businesses all over the world to easily integrate systems internally, and then mix and match the implementation of various activities within a business process, maintaining the option to, choose to outsource any or all of these activities if doing so makes business sense. (Graham et al, 2001, p. 13)
The rise of Web services is the continuing development of another WSI in the form of B2B applications. B2B is about integrating two or more businesses to support cross enterprise business system such as SCM (supply chain management) and logistics. Some industry managers claim that supply chain integration acts as the killer application of WSI, particularly as a result of the standardisation of common industry formats for XML and Web services related to SCM and logistics business.
References/ Bibliography
Anderson Richard, Francis Brain, Homer Alex, Howard Rob, Sussman Dave & Watson Karli, (2001) Professional ASP.NET
Davis, P.K. and Anderson, R.H. (2003). Improving the Composability of Department of Defense Models and Simulations. RAND Corporation, New York.
Graham Steve, Simeonov Simeon, Boubez Toufic, Davis Douq, Daniels Glen, Nakamura Yuichi & Neyama Ryo, (2001) Building Web Services with Java :Sams Publishing.
Harkrider, S. M. and Lunceford, W. H. (1999). “Modeling and Simulation Composability”: Proceedings Interservice/Industry Training, Simulation and Education Conference (I/ITSEC).
Soaplite, 2007. Web.
Soaplite2007a, Web.
Snell J., Tidwell D. and Kulchenko P., (2001). Programming Web Services with SOAP. First Edition, O’Reilly, New York, Entire Chapters- 4-5.
Tolk A, Diallo SY, Turnitsa CD, Winters LS (2006) “Composable M&S Web Services for Net-centric Applications”, Journal for Defense Modeling & Simulation (JDMS), Volume 3 Number 1, pp. 27-44.
Tolk A, (2006) “What Comes After the Semantic Web – PADS Implications for the Dynamic Web”, PADS, pp. 55-62, 20th Workshop on Principles of Advanced and Distributed Simulation (PADS’06).