SEMANTIC ENHANCED UDDI USING OWL-S PROFILE ONTOLOGY FOR THE AUTOMATIC DISCOVERY OF WEB SERVICES IN THE DOMAIN OF TELECOMMUNICATION

The current web services which are evolved in the telecom domain such as payment web services, Yellow pages web services, operator web services, weather web services are failed to bring down the semantic as they used to prove its syntactic description. The reason for bringing down the semantic description into already existing web services will invoke certain operations like automatic discovery of web services, automatic composition of the necessary services, automatic invocation of web services and automatic monitoring of the execution process. At present the web services in the domain of telecommunication is following the parlay X standard. The parlay X has given a set of standard web service API’s for the telecom. The each of the services will have its own interface, services and types In this study in order to bring down the semantic representation we have proposed an idea to enable the semantic through the upper ontology like OWL-S and then how to map OWL-S to UDDI registry and also we have discussed some of the issues that we have faced while mapping OWL-S into UDDI registry. So the approach which we are going to propose improves the accuracy of the telecommunication network services description, discovery and matching, unifies the semantic representation of telecommunications network and Internet services.


INTRODUCTION
Web services have become the main resources for managing the universal Connectivity and interoperability of heterogeneous applications and services. Their growing popularity and usage, however, triggers the problem of finding and composing relevant services since thousands of such services already exist within the public domain. In order to be able to discover and compose suitable services, one must search through the set of abstract descriptions that are made available, since web services provide functionality without showing any organization-specific implementation details . The lack of any machine interpretable semantics requires human intervention for the discovery, composition, invocation and monitoring of services, which prevents the use of services in complex business contexts, where the automation of these processes is necessary. Enabling Semantic web services relax this restriction by annotating services with semantic descriptions provided by ontologies (Paolucci et al., 2002). In this study we have discussed how to use the upper ontology like OWL-S into the existing web services. Next we have proposed our own approach for mapping from OWL-S to UDDI. The mapping is done with OWL-S profile Information into the UDDI registry. While mapping we have made discussions on UDDI tModels. And finally we have also discussed some of the issues of mapping OWL-S Profile Information into UDDI Registry.

OWL
This OWL-S is an upper ontology for services. OWL-S defines classes and properties that can be used to describe the main things in the service such as:

JCS
• What does the service do?
• How does the service work?
• How is the service Invoked?
In order to answer these questions the Upper ontology helps us a lot such as OWL-S upper ontology contains a sub-ontology called as.
Profile ontology (Profile.owl) to define the classes and properties. This sub ontology is mainly used to advertise the service, thereby enabling a service requester to determine whether the given service meets the needs or not OWL-S upper ontology's second sub ontology, process ontology (process.owl) defines all the terms that we need to describe how the service works. Moreover, we describe how the service works by describing the procedures necessary to interact with the service from a client's point of view.
OWL-S upper ontology's third sub ontology named as Grounding ontology (grounding.owl) is included by OWL-S to provide terms that one can use to describe how the service can be accessed technically. This includes the terms to describe the supported protocol and the exchanged message formats and other related low-level information. The sun ontologies are the main com-ponents of OWL-S. In addition to these ontologies there is high level ontology known as service ontology (ser-vice.owl) which helps to club these three components work together to describe a web service (Duke et al., 2005).

HOW DOES OWL-S MEET EXPECTATIONS?
The purpose of describing the profile of a given service is to provide enough information so that a soft agent can decide whether the given service meets the requester's need (Griffin and Pesch, 2007). The OWL-S upper ontology's profile.owl doc-ument provides terms that can be used to accomplish this goal. With the help of profile.owl we can achieve things like: • Service information and contact information(name of the service, descriptions and the organization that provides the service) • Functional description: Input/output/Precondition/effect(IOPE) of the service • Non-Functional information of the service(including information such as Quality of service) The profile document has been written for our service known as: In the above process while bringing down the Profile document IOPE terms has not been mentioned and the IOPE Terms has been defined in the Fig. 3 process.owl.
Clearly from the profile ontology it is possible for us to add semantics to our document. For our simple SmsNoti-fication service, if we were to use the WSDL document to describe this service, we would only know that this service takes an xsd: String as input and returns a xsd: Double as ouput and clearly there are no semantics at all, there might be hundred of web services out there that take exactly the same input and return exactly the same output. Therefore, there will be no way to select this par-ticular service correctly and automatically from all the candidates having a similar look and feel (Bond et al., 2009).
But now we have used the OWL-S profile sub ontology to describe this service. These are exactly the semantics we are looking for. To make matters clearer, the follow-ing discussion shows how these semantics will enable us to automatically find this service OSA, 2008. If we want to find a service that takes a SMSNotification model as an input and returns a string, we have followed these steps: Step 1: Created a service request file to express what we are looking for by using the concepts from the right on-tology Step 2: Submit the request file to some smart agent that is capable of reading the OWL-S profile document of each candidate service and using a match making engine to conduct semantics matching Step 3: The agent will compare the request document against each profile document it has located and included the matched service as a potential candidate

MAPPING OWL-S PROFILE INFORMATION INTO THE UDDI REGISTRY
The mapping form OWL-S profile document to the UD-DI registry is done on one-to-one basics, which we have given in the Table 1 mapping profile into registry.
Here the left column contains the elements from OWL-S and the right column contains the elements from UDDI data structures. Any row shows the mapping relationship. If for a given row the mapping does not exist, the corresponding cell in the lest or the right column is left blank. ALsi, if an OWL-S profile element has a corres-ponding UDDI element, the mapping is a direct connec-tion between two elements. For OWL-S profile element with no corresponding UDDI elements, tModel-based mapping is used. The basic Science Publications JCS idea is to create specialized UDDI tModels for each unmapped element in the OWL-S profile, such as OWL-S input, Output and so on. These tModels have to be first created and registered with the UDDI before the mapping can use them. These specia-lized tModels are in fact used as namespaces in the map-ping process (Srinivasan et al., 2004). Figure 4 UDDI's input_tModel Shows the description of UDDI's input_tModel, which is created and registered to represent the input element form, the OWL-S profile document.   Using our getSMSNotification service as example, its UDDI entity can be updated as shown in the Fig. 2 Profile document. We have created 15 tModels to accomplish this. However, the final result is a semantically enhanced UDDI.

ISSUES OF MAPPING OWL-S PROFILE INFORMATION INTO UDDI REGISTRY
The first issue is, how to inform a soft agent that a given service advertisement has an OWL-S profile representation. UDDI is essentially a huge database holding a vast amount of service advertisements. If a given UDDI registry is semantically enhance, some of these advertisements must have used the predefined tModels (Martin et al., 2007;Aguilera et al., 2007;Srinivasan et al., 2004;MohanRam and Balasubramanian, 2013;Colgrave and Januszewski, 2004). For each service advertisement, the agent has to first see whether it is semantically marked-up advertisement, if not, the agent will simply skip it. For that issue, we have created a single flag for the agent to read. We have created and registered another tModel called as OWL-S_tModel, which has a special meaning, it states that the service using this tModel has been semantically marked up and furthermore, its value cane be the URL of the OWL-S profile document. Therefore, not only have the elements in the OWL-S profile document been mapped into some UDDI service entity, but the service entity also has a link pointing back to its original OWL-S document.
Another issue which we have faced is related to the specialized tModels. UDDI itself provided several tModels, one such example is the getSMSNotification tModel used for the categorization. UDDI has made these tModels well known to the users, so anyone who wants to add categorization information to his service advertisement can use these predefined tModels freely. Similarly all the tModels representing the OWL-S elements should also be made well known to the users. Currently however it would be unclear how this could be accomplished. Therefore, different users may register their own input_tModel with UDDI. We have addressed this problem by the solution is to always look for specialized tModels before we create your own. For instance, when we are implementing the mapping from OWL-S to UDDI structure, you should first search for the input_tModel, the output_tModel, or any other specialized tModel.

CONCLUSION
In this study we have taken a syntactic web service called as parlayx_sms_notification_interface from the parlay X model which acts as a framework for the telecommunication domain. We have added semantics to the service using an upper ontology OWL-S. After adding the semantics we have mapped OWL-S with UDDI registry and finally we have also discussed some of the issues we have faced while mapping OWL-S into UDDI registry. In this broad research, we have given an idea that how a semantic web service can be discovered automatically. Particularly in the domain of telecommunications it provides higher efficiency and performance.